pouët.net

At Function demoparty we had a great fun together with řrřola, Kuemmel and Harekiet
As a selfelected jury we judged the 256b intros from the 1990s.
We like or not... similar to The X factor TV show :-)

The selected intros have been videocaptured and I will publish them on my youtube channel.
In every morning only one piece. Day by day until the demoparty Deadline.

Don't forget this German demoparty will have a 256 byte intro competition!

Just to start here are 3 kick-ass 256byte intros from the 1990s:
Fireworks
Bump is Possible
Wormy

The next one is comming on my youtube channel tomorrow morning!

I think it would be great if you could comment here as well about the newly uploaded intro, and tell us a few words about why that had been selected!

Cannot find link - i like small intro Snow from Hugi compo or something else.

Youtube: https://www.youtube.com/channel/UC4qlzVwPqf8OqEt6BDX9noA

g0blinish: Here you can find all the entries from the 64b Hugi Xmas Compo 2006.

90s 256b are nostalgic, they were more variations of 2d and 3d effects that would run on not monster DOS pc. Modern stuff, because the bar is raised, are raymarched or other methods for 3D that are very very slow.

Let me shamlessly promote my groupmates work here - AFAIK the only 256b intro from the 90's with music - http://www.pouet.net/prod.php?which=5035

I have some questions regarding 256b intros (as I am planning to write an article for a magazine about this topic):

1. What is special about making 256b intros compared to 4k intros? What do coders especially have to care about?

2. How much do the FPU, MMX and other advanced codesets help in creating 256b intros (to achieve the size limit)?

3. What are the greatest technical and aesthetic achievements in 256b intros so far?

4. What resources would you recommend for learning to create 256b intros?

I would be happy about serious answers to (some of) these questions.

1) Watch the source of many 256b intros so far
2) Watch the source of many 256b intros so far
3) Watch the source of many 256b intros so far
4) Watch the source of many 256b intros so far
5) Disassemble a 256b if the source is not provided

Adok:
1)
- No room for the windows header, so DOS (or oldskool platforms) only
- Hence no 3D acceleration or shaders, and even high-res modes are very rare. 320*200 res with 256 colors palette is the norm.
- No room for a decompressor, so uncompressed executables. But this gives you the freedom to use any obscure assembly instruction to save bytes. In a 4K, you have to feed your compressor (typically Crinkler) predictable data. Many coding tricks that save uncompressed bytes will result in a bigger compressed size, so aren't worth it in a 4K.
- No room for a softsynth, use midi or (typically) no sound.
2) I know x87 FPU call are not uncommon, no idea about MMX etc
3) See https://www.pouet.net/toplist.php?type=256b&platform=&limit=50&days=0&dateFrom=0&dateTo=0 , but personal taste varies of course.
4) http://www.sizecoding.org is a good starting point.

@Adok:

1) Black wizardry! The general opinion at first was that 256 bytes was barely the room for only one "good" effect.
2) Not sure, but probably MMX is not very important for 256b (in most prods).
3) After all these years, tube is still awesome.
4) An assembler, good knowledge of your platform, and a lot of patience.

@Adok

in short

1) you write everything yourself (exception : MIDI sounds and FONT data)
2) FPU is important (2D/3D rotation) MMX and further not
3) "tube" and "puls" had it all, progress nowadays is doing 3D and music in <= 64 bytes
4) Sizecoding.org

Oh well, and Protected Modes, HiRes (up to 1280x1024), TrueColor, ARE a thing. People slowly adapt it. As well as real music. Snippets on sizecoding.org suggest that there is MUCH more possible in 256 bytes than expected. We have fractals in 16 bytes, bass line in 8 bytes, interactivity (paint) in 16 bytes, Fake 3D in 32 bytes, Raycasting in <64 bytes. Custom colors in <16 bytes. The -documented- toolkit is there, it's up to the people to creatively assemble it. Literally.

Thanks for all of your answers so far!

@Adok:

Here are my points:

1.
You can not use genaral code packers like APACK or UPX. For data compression you my write your own special routine if the decopression code is simple and small enough (see my intro Lif&Life). For saving lots of bytes from the code you need hardcore asm skills and tricks.

2.
Code with integers is always smaller but some effects need floating point calculations and then the FPU is a must. I don't know about 256b intro with MMX, but Kuemmel has shown with the TrueColor version of Codegrinder that the SSE could be an option despite of the size of instructions. The PentiumPro advanced instructions (FCOMI, FCMOVB, CMOVB etc.) really could help to achieve the size limit and hopefully more and more DOSBox variants will support them soon.

3.
What I really call achievement... look at Rrrola's intro pyrit at Demobit and now at Function. This RayTracing quality is a great achievement. I was also happy with my Seashell intro (HiRes TrueColor with Z buffer). And also don't forget Digimind's ducks. Other new thing is the real music (not just sound) synced with visual (see TCTRONIC intro).

4.
sizecoding.org / references
source codes of asm gurus like Rrrola, frag and others
youtube seminars

Thank you for your comments, TomCat! Much appreciated!

thank you! Nice intro anyway

Hi there,

I've written up the article and published it in Genycs Magazine #5, which you can freely download from the Internet. For more info let me quote what I posted to the pouet page of Genycs Magazine #4:


Thank you very much again for answering my questions. I hope you will enjoy my article and the whole magazine.

In advance we did't think we will be quoted, but for me... I don't mind. I really like the first screenshot and thank you for making the thing more popular :-)

Oh, sorry. I was assuming that since pouet.net is an openly accessible website, it is okay to quote you. Of course, if you had sent me your answers privately, e.g. via email, I would have asked you for permission.

I am happy that it is okay with you that I have quoted you.

Exactly what TomCat said ;) Would have replied more detailed had i known it's gonna be quoted word by word. Thanks anyway for including my concluding statement =)

@TomCat thanks to you as well for promoting our beloved sizecoding =)

I was happy that you corrected my typo error: my->may :-)))

Some favorites of mine:

Self Disassembler: https://www.pouet.net/prod.php?which=16930
Boosty (as referencing Boost/Doomsday): https://www.pouet.net/prod.php?which=3398
Ultra2: https://www.pouet.net/prod.php?which=51875

TomCat: Don't worry, I've proofread *all* articles submitted to Hugi, ever since the first issue. I am accustomed to correcting such petty typos. :)

*every article :P