How to make TINY programs.?

I don''t know about much, I''m a noob myself(despite the fact, that I''ve been lingering around these forum''s for like 2 years), but I read on one of the demo sites, that they had like 2 sounds, and they synthed them, so that they made different beats and stuff.

A lot of useless code probably comes from linking to static libraries that aren''t needed and such. I would think that much of that could be ignored when making the final executable, if it wasn''t used, but there might be some things that simply have to be included just in case, and maybe certain compilers aren''t as good as doing this anyway (or you have to specifically make sure to tell them to ignore unreferenced stuff). And make sure you''re compiling a release version, not a debug version. Also, I think most compilers let you optimize for either smallest size, or fastest code. Fastest code is usually default, so you might consider changing that option.

I am pretty sure that the really really compact graphical demos are written in assembly code and use procedural textures. I''m not positive, but that is what I heard, and I suppose it would be possible. They know what they are doing, thats for sure...

the Ultimate Packer for eXecutables

quote:

---

Original post by TheSimplerOne
I am pretty sure that the really really compact graphical demos are written in assembly code and use procedural textures. I''m not positive, but that is what I heard, and I suppose it would be possible. They know what they are doing, thats for sure...

---

You are correct.

You can get mode 13h up and running with just two instructions: a MOV and an INT. Granted, interrupts may be "legacy" code, but you get the idea.

Most media is generated procedurally. Perlin noise, when used creatively, can generate stunningly good results. Most media that can''t be generated procedurally such as text is aligned in the executable to be as compressible as possible (as was done in .theprodukt, the all-too-popular 64k demo). Of course, the executable is packed and often ends up bigger than 64k when unpacked.

I like to classify demos in two groups: effects and multimedia presentations. The former would be, for instance, this spiffy little waterfall done via a particle engine in 128 bytes I have sitting around here. The latter would be the big, impressive demos such as .theprodukt and Heaven Seven. Effects can easily be written to hold in less than 1k if done in DOS. Multimedia presentations, on the other hand, require careful packing and selective organisation along with more complex technologies such as procedural texture generation.

Assuming that you are targetting a "real" OS like Windows or Linux, not DOS, you can still make VERY small exes using C:

1. Do not use the C library (its static-linked startup code tends to be 10-15k or something)
2. Do not use any other library which has any significant static component (I don''t believe openGL or D3D do)

The main problem, is that being without the C library is a bit of a pain in the arse, not having stuff like malloc() and strcmp() is not very helpful to general development. Win32 provides a *FEW* C library-like functions in kernel32, if I remember right (not very many of them).

I did some experiments a few years ago, and showed that the smallest practical win32 .exe I could make was about 2.5k.

Changing the segment alignment for something makes the exe smaller, but breaks if you go too low.

"Hello, World" on my Linux system, linked *with* the C library, gives me a 2944 byte executable.

Mark

Is there a single reason for this?

Summary: Don't use the runtime. Generate everything procedurally. Compress the result.

The first thing you do is avoid using any statically linked libaries. Windows provides ALL the functionality you need via the API (the CRT doesn't just magically do things on its own - it uses the windows API and C 'primatives' to get things done). Sometimes you might need to make a basic wrapper, but it takes about 10 lines of code to get an entry point and new/delete working with just the windows api, and things like 'sprintf' are provided directly by windows if you need string formatting, etc.

The next thing you need to do is create a filter system. In practically all demos, textures are created procedurally in a manner much like invoking filters in photoshop. Instead of storing a 1024*1024 image, the program stores a 'macro' of which filters are required to make the image and then runs it like a scripting langauge at startup to create needed textures in memory. Or, if you just want to be lazy, you could store them as midi files =-P

I'm not sure if the same method is applied to sounds/models/levels/etc, but it is possible. The sound('music') in demos often sounds fairly repetitive, so perhaps it is created from a few 'base' samples(main beats) with a few others mixed in every once in a while(for the different parts).

Models could be stored procedurally and built from primatives, so only things like 'column [height, radius, rotation, location, texture info]' need to be stored instead of each vertex, etc.

Then, as stated before, everything(including the exe itself) is compressed to be as small as possible.

[edited by - extrarius on May 13, 2004 5:29:22 AM]

[edited by - Extrarius on May 13, 2004 6:12:19 PM]

http://www.catch22.org.uk/tuts/minexe.asp

Creating tiny demos is impossible

quote:

---

Original post by Michalson
Creating tiny demos is impossible

---

Holy crap.

I''m impressed. At first, all''s I saw was the dude and I hit a key. I was pretty impressed; nice job, drawing all that in 999 bytes. Then I figured I''d run it again, for the heck of it, and saw the rest of the effects.

You, sir, are l33t.

Check out The Product. Their 64kb demo uses Direct X 8. On their site they talk about how they did the music and textures in more detail than you could probably get on the forums.

Dudes... why not give the guy a link to Farb-Rausch's site, and call it a day? Many 64 kB demos, and even a cool 128 B demo (yes, 128 Bytes).

Farb-Rausch

Lots of 64kB demos, and fr017 is their best 128B demo.

Great demos: fr-minus-3.2, fr-08, fr-013, fr-014, fr-018 (need a GBA emulator), fr-019, fr-020, fr-025, fr-030, fr-036.

Also, kkrieger, a game in 96kB (mind, you need a pretty powerful machine to run it, and the framerate lags something nasty every once in a while due to a bug in the physics engine). To the people who get stuck on the 4th door, in the room of pillars; you have to jump through, even though there is no apparent obstacle.

.kkrieger

[edit: how powerful a machine] My Radeon 9600XT, 128MB VRAM, 768MB RAM, 1.6GHz P4 can manage 20 to 35 frames per when the physics bug isn't dragging it down to about 5-10 frames per.

[edited by - Wyrframe on May 13, 2004 2:32:08 PM]

I seem to remember seeing posts from some of the Farbrausch guys and they say they don''t actually use much assembly. Most of their coding is done in C++.

Here''s a good article on reducing .exe size.

[removed by Michalson]

Editing someone elses work (especially just overwriting names with a hex editor) to make it appear to be your own is not kosher. In fact its typically called copyright infringement.

I used to do this sort of stuff back in the day.. One thing to remember about the music is that various mod formats are pretty efficient for certain styles of music (just say no to vocals). Especially for the 64k intro stuff it was never hard to fit in just about everything you wanted (Usually about half that space was music, the other half code...). No assembly required, but an exe compressor is a must.

Using Linux?

i made a full fledged DirectX demo in 2k. First k is initialiation. What you do is make sure no static libraries are linked, then you use

int MainCRTStartup() instead of int main(). Or, I think its maincrtstartup...

and then all the malloc, free stuff i had to code myself. it was fun, to say the least. www.cfxweb.net should give you all the information yo need.

quote:

---

Original post by aftermath
[removed by Michalson]

Editing someone elses work (especially just overwriting names with a hex editor) to make it appear to be your own is not kosher. In fact its typically called copyright infringement.

---

I didn''t know it''s Michalson-cant-see-blindingly-obvious-joke day today. no one told me, now i''m just t confused.