• Ever wanted an RSS feed of all your favorite gaming news sites? Go check out our new Gaming Headlines feed! Read more about it here.
  • We have made minor adjustments to how the search bar works on ResetEra. You can read about the changes here.

Deleted member 12790

User requested account closure
Banned
Oct 27, 2017
24,537


What the everloving hell. Holy fucking shit, I cannot express enough how insanely impressive this. 256 bytes. Not even a damn kilobyte.

Check this out:



EVXDu32XkAEBNDa


EVXD_nfXQAE0Zau


This program, that simply calls main and exits and does nothing else, is 36 times bigger than this demo.

I legitimately think it's a miracle that 4K demos get made. It's hard as hell to get a demo down to 4k. 256 bytes is another level. A couple of years ago, I wrote a PC Booter application from scratch, a micro kernel to teach myself how to boot my own code from the boot strap. My loader alone was like 10 KB.

Unbelievable.
 

NotLiquid

One Winged Slayer
Member
Oct 25, 2017
34,769
Gonna have to delete this to make room on my hard drive, I hope the devs understand
 
OP
OP

Deleted member 12790

User requested account closure
Banned
Oct 27, 2017
24,537
File Explorer in windows 10 can't even list the program size correctly. It lists it as 1kb, as that's the smallest it can claim a program is. File explorer outright lists the program as four times bigger than it is, because it can't conceive a program this small.
 
OP
OP

Deleted member 12790

User requested account closure
Banned
Oct 27, 2017
24,537
The resultant executable is 14 times smaller than it's own source code, which is written in pure x86_64 microprocessor assembly.
 

notBald

Member
Oct 27, 2017
392
I've yet to see a demo that impressed me as much as Second Reality, but getting that much music and graphics into a tweet is mind boggling.
 
OP
OP

Deleted member 12790

User requested account closure
Banned
Oct 27, 2017
24,537
the assembly in this source code is extremely elegant, each section of the demo is it's own routine. This is extremely impressive to me:

Code:
fx4: ; sierpinski rotozoomer    
    lea cx,[bp-2048]
    sal cx,3
    movzx ax,dh
    movsx dx,dl
    mov bx,ax
    imul bx,cx
    add bh,dl
    imul dx,cx
    sub al,dh
    and al,bh
    and al,0b11111100
    salc                ; VERY slow on dosbox, but ok
    jnz fx4q
    mov al,sierp_color
    fx4q:
ret

This is the code for a rotozoomer, it handles rotations and scaling. Rotozoomers are a piece of extremely oldschool part of demoscene. This particular type of rotozoomer is a sierpinski rotozoomer, I've seen these written on the Atari ST in 68000 assembler. The sierpinski rotozoomer whose source code I have seen was 128 bytes big. As in, the rotozoomer alone was half the size of this entire demo, without sound. It was also somewhere around 150 lines of code. The above rotozoomer, when compiled, is less than a dozen bytes, and is only 15 lines of code.
 

poptire

The Fallen
Oct 25, 2017
9,980
I'll never understand the internet. That video rules and is super impressive, and has two dislikes for no reason at all.
 
OP
OP

Deleted member 12790

User requested account closure
Banned
Oct 27, 2017
24,537
Just to drive this point home, the text in this message I am typing right now, just the text alone, not the entire forum post code, but just the text, even if encoded with ASCII instead of unicode, is bigger than the entire program.
 

DSP

Member
Oct 25, 2017
5,120
there was like a FPS game demo around that was very small too. It was decades ago, I don't remember what was the name. That was actually impressive.
 
OP
OP

Deleted member 12790

User requested account closure
Banned
Oct 27, 2017
24,537
there was like a FPS game demo around that was very small too. It was decades ago, I don't remember what was the name. That was actually impressive.

.kkrieger is 384,000 times bigger than this. .kkrieger is 96kb big, and that's just the executable. The reason .kkreiger was so small is because all the assets it uses are procedurally generated, hence they're not stored as, like, bit mapped data in the executable. In RAM, .krieger takes up several megabytes of memory. This never breaches 256 bytes.
 

gabdeg

Member
Oct 26, 2017
5,966
🐝
This is simply too big. I can only fit 32 byte demos on my HDD.


Edit: I see that this became part of "Memories". So now you know that this particular effect could be done in 32k.

If people are interested they can find all sorts of demos here: http://www.pouet.net/prodlist.php

there was like a FPS game demo around that was very small too. It was decades ago, I don't remember what was the name. That was actually impressive.
It's .kkrieger. http://www.pouet.net/prod.php?which=12036
 
Last edited:

EloKa

GSP
Verified
Oct 25, 2017
1,906
Some other amazing stuff but this time its from the 64kb demo scene.
All visuals, sounds, SFX and so on are pressed into a single 64kb file for each demo. Technically it is 256 larger than what Krejlooc posted:







 
OP
OP

Deleted member 12790

User requested account closure
Banned
Oct 27, 2017
24,537
Krejlooc Do you know any good resources for learning 386 assembly? This stuff fascinates me.

I don't usually touch x86 like this. I'll peak at it to look at how my code has compiled to help debug or do other maintainence, but I don't ever sit down and actually write x86 code from scratch. So all I ever need is just an opcode reference manual just in case I need to look something up. I use this: http://ref.x86asm.net/

I think the x86 platform is very, very ugly to write assembler code for, actually. I would recommend picking up something more like the 68000 or 6502, and then using what you apply to help debug x86.
 

Shwing

Member
Oct 25, 2017
858
I don't usually touch x86 like this. I'll peak at it to look at how my code has compiled to help debug or do other maintainence, but I don't ever sit down and actually write x86 code from scratch. So all I ever need is just an opcode reference manual just in case I need to look something up. I use this: http://ref.x86asm.net/

I think the x86 platform is very, very ugly to write assembler code for, actually. I would recommend picking up something more like the 68000 or 6502, and then using what you apply to help debug x86.

I was looking at some 6502 guides the other day. I'll be sure to focus there. Been thinking about trying to make something that will run on an NES.
 
OP
OP

Deleted member 12790

User requested account closure
Banned
Oct 27, 2017
24,537
Just to point out but you probably already knew this. It's 9kb because the project has other libraries included. So it's not just an empty main.

I know, most of that is stdlib. And there are other compiler overhead there as well. And, 100%, this demo wasn't written in C to begin with. But even stripping out debug symbols, not linking any standard libraries, -Os -S, etc, I still can't get an executable down this small. A huge portion of an x86 MSDOS/Win32 executable is the Portable Executable Format header.

Like check this out:

Portable_Executable_32_bit_Structure_in_SVG_fixed.svg


over 110 bytes of the executable is just the PE format header!
 

TooFriendly

Member
Oct 30, 2017
2,028
I was watching this video recently about boot sector games. There are some good visualisations showing how much space 512 bytes takes up on a floppy disk.

 
OP
OP

Deleted member 12790

User requested account closure
Banned
Oct 27, 2017
24,537
I was looking at some 6502 guides the other day. I'll be sure to focus there. Been thinking about trying to make something that will run on an NES.

Some would say I'm biased, as it's the first microprocessor language I learned and most people tend to be extremely in love with their first language, but I legitimately think the 68000 is the greatest microprocessor created for people learning microprocessor assembly. Its instruction set is very, very easy to pick up, it's super relaxed about conversion rules (depending on assembler), there are mountains of resources for learning it, and most importantly: It's got fat registers, lots of them. Eight 32-bit data registers and seven 32-bit address registers. The more work you do with microprocessors, the more you realize having a lot of really thick registers is a godsend, as those are essentially your "hardware variables" as I like to call them.

The 6502 is basically the opposite concept. It's extremely basic, giving you only a couple of registers essentially. The idea is after each operation, you'll want to move your data out of the register back into memory. The 6502 is built on every operation being extremely simple, at the expense of performance. The 68000 is the opposite, you have so many registers that you can just leave data in them and do all the work you need. So like, if you need to update multiple variables, instead of having to put them into registers on the 6502, do your operation, then take them out, then load the next data, put it into the register, do your operation, then take it back out, etc, on the 68000 you can just load up all the data you want at once and do all your calculations. You have so many registers, each of which can be thought of as one 32-bit register, or two 16-bit registers, or four 8-bit registers... just so useful.

I think 68000 assembler is probably one of the most vital things someone serious about software engineering can pick up. It'll teach you things about other microprocessors in the process. When I work with modern GPUs, I use lots of things I learned way back when I was picking up 68000 assembly.
 

Bomi-Chan

Member
Nov 8, 2017
665
This is what I really hate these days. Devs simply throw around with gigabxtes instead of compressing them in a orderly manner.
Ask the n64 devs how they got their games on the cartridges. And the biggest mystery of all time= how the flying fuck was capcom able to pull resident evil 2 on a n64-cart?
2discs each 650mb...
 

horkrux

Member
Oct 27, 2017
4,733
It has always fascinated me how they can cram so much graphical goodness into these tiny ass demos
 

Max|Payne

Member
Oct 27, 2017
8,974
Portugal
This is what I really hate these days. Devs simply throw around with gigabxtes instead of compressing them in a orderly manner.
Ask the n64 devs how they got their games on the cartridges. And the biggest mystery of all time= how the flying fuck was capcom able to pull resident evil 2 on a n64-cart?
2discs each 650mb...
I'm sure if Rockstar had made just a little bit more effort, RDR2 could've easily fit a single 4GB DVD.

Real answer, it's not worth the time and money spending compressing and super optimizing the game code. These tiny file demos are made as a challenge and they're super small in scope and content. RE2 N64 was achieved by compressing and reworking assets to rather lower quality compared to the PS1 version, so it's not a magical solution that provides a similar level of quality to the original.
 
OP
OP

Deleted member 12790

User requested account closure
Banned
Oct 27, 2017
24,537
This is what I really hate these days. Devs simply throw around with gigabxtes instead of compressing them in a orderly manner.

I can guarantee you that isn't the case. Most stuff is compressed, and the things that usually are not compressed, are not compressed precisely because decompressing them on the fly for various reasons isn't feasible.

As for how Capcom was able to fit RE2 on a cartridge: For one, not each disc of the PSX version are 650 mb of unique data. Both scenarios share a ton of resources. Secondly, they drastically reduced texture complexity, like sometimes with textures being 1/16th their normal size, resulting in them looking super blurry. The voice clips in the game got taken down to something like 22 KHZ instead of the 48 KHZ of the PSX version, along with the audio samples. Finally, the videos in the game were compressed, losing 1/2 their resolution, a massive reduction in bitrate, with a much more complex decompression scheme that could run on the N64's DSP. The PSX only has very basic video codec available for decompression, owing to the weaker processor.
 
OP
OP

Deleted member 12790

User requested account closure
Banned
Oct 27, 2017
24,537
I was watching this video recently about boot sector games. There are some good visualisations showing how much space 512 bytes takes up on a floppy disk.



This is a good video for visualizing the size of the data. It doesn't quite get into enough of how much of a program is "standard" data format, however. Depending on your architecture and operating system, executable programs will take a number of different formats. The two most popular, historically, are COFF (common object file format) and ELF (executable and linked format). Microsoft's EXE is built on top of COFF. These formats require a certain header to be in place to, for example, arrange the memory layout of a program as it's loaded by the operating system (like a section for non-initialized variables in memory). These header formats eat up an enormous chunk of a program in a way that you can't get around. In actuality, owing to this being of COFF format, this has even less than 256 bytes to work with, the header eats up a large chunk of it.
 

Max|Payne

Member
Oct 27, 2017
8,974
Portugal
I can guarantee you that isn't the case. Most stuff is compressed, and the things that usually are not compressed, are not compressed precisely because decompressing them on the fly for various reasons isn't feasible.

As for how Capcom was able to fit RE2 on a cartridge: For one, not each disc of the PSX version are 650 mb of unique data. Both scenarios share a ton of resources. Secondly, they drastically reduced texture complexity, like sometimes with textures being 1/16th their normal size, resulting in them looking super blurry. The voice clips in the game got taken down to something like 22 KHZ instead of the 48 KHZ of the PSX version, along with the audio samples. Finally, the videos in the game were compressed, losing 1/2 their resolution, a massive reduction in bitrate, with a much more complex decompression scheme that could run on the N64's DSP. The PSX only has very basic video codec available for decompression, owing to the weaker processor.
BTW, Angel Studios aka Rockstar San Diego, did the N64 port.
 

Deleted member 23046

Account closed at user request
Banned
Oct 28, 2017
6,876
Some other amazing stuff but this time its from the 64kb demo scene.
All visuals, sounds, SFX and so on are pressed into a single 64kb file for each demo. Technically it is 256 larger than what Krejlooc posted:









During the same party were Femi Paradox was shown :




It fits in the size of a Facebook avatar -_-

To run it on your PC :

www.pouet.net

Darkness Lay Your Eyes Upon Me by Conspiracy

64k for Windows, 2nd at Revision 2016
 

jett

Community Resettler
Member
Oct 25, 2017
44,658
Nice!

The olden days where you got demos on PC magazine discs are precious to me.

Some other amazing stuff but this time its from the 64kb demo scene.
All visuals, sounds, SFX and so on are pressed into a single 64kb file for each demo. Technically it is 256 larger than what Krejlooc posted:








These are super cool. I really love demoscene stuff. I bet they will do some crazy stuff with raytracing, if they aren't already.
 
OP
OP

Deleted member 12790

User requested account closure
Banned
Oct 27, 2017
24,537
These are super cool. I really love demoscene stuff. I bet they will do some crazy stuff with raytracing, if they aren't already.
raytracing in and of itself originates from demoscene. Every graphical trick ever has originated from demoscene. Demoscene is where advancement in graphics come from. Computer graphics as a whole goes back to display hacks for osciliscopes:

iphKD6n.jpg


 

Lebon30

Member
Oct 27, 2017
2,287
Canada
File Explorer in windows 10 can't even list the program size correctly. It lists it as 1kb, as that's the smallest it can claim a program is. File explorer outright lists the program as four times bigger than it is, because it can't conceive a program this small.
It's not Windows 10. That's how partitionning works on hard drives which work in sectors. A sector is 4 KB. Like SSDs, even a 1 byte file will take 4KB of HDD space. However, there can be 4096 1 byte file in that sector (that's not trye for an SSD though). To see the real size, right click on the file then click properties. Then, you should be able to see the actual size. Windows 7 exemple:

83bc74cda27c19fffca98c5efa1733c4.png

Taille = size
Sur disque = on the disk.
 
OP
OP

Deleted member 12790

User requested account closure
Banned
Oct 27, 2017
24,537
This is a project I've been interested in. What kinds of resources did you use to figure out how to do this (other than your processor's manual I guess).

I pulled from various experience I had over the years, like I can't tell you where I learned about the sections of a COFF executable (.bss, .data, .text), I just kinda picked it up over the years. But I do remember there was a blog I was reading where the person was trying to write a micro kernel themselves that had some resource links I used. I was actually trying to find that blog earlier tonight to show someone else, but I dunno where it went.

EDIT: This isn't the blog, but it's something pretty similar I just found while looking for the old blog: https://createyourownos.blogspot.com/

This is for building a 16-bit bootloader, though.
 

SigSig

Member
Oct 26, 2017
4,777
People out there implementing rotozoomers in 17 lines of assembly and I'm too much of an idiot to even do it in a comfy high level language.
Guess my demoscene ambitions will never amount to more than shitty sine-wave text scrollers :'(
 

m0dus

Truant Pixel
Verified
Oct 27, 2017
1,034
Really impressive, if it was on ps4 you'd probably still need 100gb of space to update it!

demoscene was a fundamental inspiration for a lot of our wildest PS4 themes actually. A lot of effects that are not supported by the software were generated procedurally via nested pseudo code :p
 
OP
OP

Deleted member 12790

User requested account closure
Banned
Oct 27, 2017
24,537
It's not Windows 10. That's how partitionning works on hard drives which work in sectors. A sector is 4 KB. Like SSDs, even a 1 byte file will take 4KB of HDD space. However, there can be 4096 1 byte file in that sector (that's not trye for an SSD though). To see the real size, right click on the file then click properties. Then, you should be able to see the actual size. Windows 7 exemple:

83bc74cda27c19fffca98c5efa1733c4.png

Taille = size
Sur disque = on the disk.

Yeah, I know why it's limited to just a single sector display. That's kind of the point, though. This is a unit of disk space that is unfathomably small these days. When I think of things that are like 512 bytes big, I think of floppy drive technology. This is pretty much an ancient-style demo.
 

Shwing

Member
Oct 25, 2017
858
Some would say I'm biased, as it's the first microprocessor language I learned and most people tend to be extremely in love with their first language, but I legitimately think the 68000 is the greatest microprocessor created for people learning microprocessor assembly. Its instruction set is very, very easy to pick up, it's super relaxed about conversion rules (depending on assembler), there are mountains of resources for learning it, and most importantly: It's got fat registers, lots of them. Eight 32-bit data registers and seven 32-bit address registers. The more work you do with microprocessors, the more you realize having a lot of really thick registers is a godsend, as those are essentially your "hardware variables" as I like to call them.

The 6502 is basically the opposite concept. It's extremely basic, giving you only a couple of registers essentially. The idea is after each operation, you'll want to move your data out of the register back into memory. The 6502 is built on every operation being extremely simple, at the expense of performance. The 68000 is the opposite, you have so many registers that you can just leave data in them and do all the work you need. So like, if you need to update multiple variables, instead of having to put them into registers on the 6502, do your operation, then take them out, then load the next data, put it into the register, do your operation, then take it back out, etc, on the 68000 you can just load up all the data you want at once and do all your calculations. You have so many registers, each of which can be thought of as one 32-bit register, or two 16-bit registers, or four 8-bit registers... just so useful.

I think 68000 assembler is probably one of the most vital things someone serious about software engineering can pick up. It'll teach you things about other microprocessors in the process. When I work with modern GPUs, I use lots of things I learned way back when I was picking up 68000 assembly.

I've seen some tutorials for the 68000 on Youtube. I suppose I'll try my hand at making a Commodore game or something. Thanks for the advice!
 
OP
OP

Deleted member 12790

User requested account closure
Banned
Oct 27, 2017
24,537
I've seen some tutorials for the 68000 on Youtube. I suppose I'll try my hand at making a Commodore game or something. Thanks for the advice!

Like I said, I'm biased for sure, though. There are things I described about the 68000 that could be seen as "faults" to a 6502 programmer. Like, because you only ever have the data you are working on in registers on a 6502, nothing more, you run no risk of clobbering your registers within a function. With 68000 programming, or x86 programming for that matter, there's always concern that your function might clobber an existing register -- i.e. use a register that you're storing some data in, to store a completely different operation result, essentially deleting your old data in the process. So there are always trade offs, that's how working with hardware directly is.

Just a heads up, it's the Amiga that is the 68000, and the C64 which is the 6502. So "commodore" could be either CPU I recommended lol. I actually do Amiga demoscene programming, the more you work with commodore machines, the more you realize you are devoting half of your time to learning their custom chipsets. As in, the most fun parts of commodore programming, is specifically writing COPPER lists or stuff like that. Attacking the amiga hardware directly.

Now, the Amiga is an amazing system to learn if you want a deep understanding of how everything works in a computer. A lot of modern graphics technologies have analogs on the amiga. Modern GPUs, for example, run a program per-vertex and per-pixel called a shader. On the Amiga, it actually does something similar, except it runs a program per-scanline. This program is run independently of the main CPU, and you can write a list of programs for each scanline, called a COPPER LIST. In this sense, a COPPER LIST is like the precursor to modern shader programming.

Now, if you want to learn just microprocessor assembly for the 68000, nothing else, an Atari ST would be a better machine to learn. It has no real video chip inside, all the graphics on screen are generated entirely in software on the 68000 CPU by changing some memory locations.
 

lemmykoopah

Banned
Oct 29, 2017
740
I only understand like 5% of what is written by the people in this thread, however I'm finding the subject quite fascinating.
 

Deleted member 20297

User requested account closure
Banned
Oct 28, 2017
6,943