Live data from Hacker News

Memories – 256 bytes demo winner of Revision 2020

sizecoding.org

21–30 of 123 posts

Re: Memories – 256 bytes demo winner of Revision 2020

#21

Can anyone describe at a high level for a complete noob how this kind of thing works? Someone who is not going to be able to read a bunch of ASM and interpret it? I'm guessing that it is something along the lines of: - the graphics "driver" reads values out of certain registers (AL and AH?) at a set interrupt (maybe every X clock cycles?) and writes one pixel to the screen of whatever color those registers had in the…

> - the graphics "driver" reads values out of certain registers (AL and AH?) at a set interrupt (maybe every X clock cycles?) and writes one pixel to the screen of whatever color those registers had in them

It's actually much simpler than that. After you set the right graphics mode (which for most simple dos demos is usually mode 13h, 256 color on 320x200) then there's an area of the memory that you can write to and it will show up as a pixel.

The "flow control" is usually just that you run your effect n times in these simple demos. Which means it will run faster on a faster CPU, but you usually wouldn't bother implement any form of timing in 256 byte.

Re: Memories – 256 bytes demo winner of Revision 2020

#22
post #4

How do you handle time with such small code size? I see a timer interrupt for the music, but what about the animation? Is it dependent on the speed of the underlying CPU?

> How do you handle time with such small code size? I see a timer interrupt for the music, but what about the animation? Is it dependent on the speed of the underlying CPU?

Usually you don't "handle" it in very small demos of the 256b/64b kind, you just run your effect. And yes this means speed will depend on the CPU speed.

Re: Memories – 256 bytes demo winner of Revision 2020

#25

Normally these demos are filled with all kinds of 'tricks' to make things smaller. Things like self modifying code, using bits of the bios or video ROM in ways they weren't intended by jumping into the middle of them, saving space by using code as data or vice versa, tiny packers which compress or uncompress the code, massive pregenerated buffers to do runtime lookups to generate data in one order but use it in anoth…

Note your comment about how unimpressed you are is 214 bytes longer than the demo.

Re: Memories – 256 bytes demo winner of Revision 2020

#26
This is so cool

MS-DOS programming was overall a pain in the... byte but what I miss most about it was the simplicity of graphics.

Wanna draw? Just write to memory. Setting a mode was one instruction

(Wanna play sound? Fumble with 2 levels of IRQ controllers one DMA controller then sob uncontrollably. Or use Allegro. Wanna do multithreading? What's that? )

Re: Memories – 256 bytes demo winner of Revision 2020

#29
post #19

I've always thought the demo scene looked cool. Problem is, I don't really care about graphics and sound and am not an especially creative person. Are there are competitions that are purely objective? As in, the objective criteria is quantitative?

The International Obfuscated C Code Contest

https://www.ioccc.org/

Re: Memories – 256 bytes demo winner of Revision 2020

#30

The source code really looks like black magic. It's incredible they were able to cram the tunnel effect into 64 bytes [1]. The entire video is here [2], if you just want to watch the final product. EDIT: link fixed. [1] https://www.pouet.net/prod.php?which=85227 [2] https://www.youtube.com/watch?v=Imquk_3oFf4

There's something beautiful about the fact that the video is FAR larger in size than the program that initially generated the output. Almost worth watching for that fact alone.
Post reply on HN