Heres some hard worn experience:
1. Use C and drop to asm when you need. Far too many people in the scene worship asm without ever trying to optimise their C algorithms first. That said, asm is useful for some key things. First time though, C will suffice.
2. Exclude stdlib fom your build (there is an option in VC++ for it). Optimise for size (-Os) but also try -O2 because it might compress better.
3. Use crinkler. Its the best at 4k. Dont be fooled...if you use crinkler at around 1k it will be worse in performance than dropper and apack but by 4k its kicking arse.
4. Dont use libraries like math.lib - write your own functions. Many source code 4ks include some cool substitutes for math functions. Most memory fiunctions and file functions (should you need them) have win32 equivalents, meaning you dont need to import any libraries except OGL or DX. Importing a lib could be 40 bytes. Each function is 12-16 bytes. Just dont do it.
(exception, dont write vector and matrix libs yourself, read the d3dx documents with the microsoft directx sdk)
5. Extract *everything* to a function and think fourty times how to reuse. For example...a random point in a sphere routine. Could be used for camera path around an object, for drawing lines, for creating a starfield, for the location to draw your next cube, for an explosion of points...etc.
6. Aim for 3k of code and leave 1k for your synth and music *at least*.
7. At 4k dont import by ordinal.
8. Use iteration and recursion to the max to achieve your goals.
9. The great 4ks of last year had just one technique (eg raytracing, ambient occlusion) and so had one core routine and exploited it to the max. Dont try to write a demo in 4k...just adding black borders, a fade and some design will see you at 400 bytes less. Forget it, focus, do one thing wll and you are more likely to succeed (well at least to get thumbs on Pouet- depends what you call succeeding I guess).
10. For your synth, steal samples from inside gm.dls : its the same under Vista so its future proof too. The code to read them and do simple playback is about 300 bytes. Then add a tracker (300 again). Then consider effects.
11. Watch for converting floats to ints - its huge code because of IEEE. lrintf can be used in GCC but better is to use something like fist in asm.
12. Remember one x86 asm instruction can get both sin and cos of a number - that can be a huge byte saving.
13. Rbrazs VC++ opengl framework (based on my old GCC one) is the best around. In C, I doubt it can be beaten (famous last words).
14. Ignore any crap you hear from people who have never written a 4k once you finish. People who dont size code have no clue what is easy and what is hard (extra bytes). Try to laugh at the ridiculously ignorant saying things like "absolutely no design" - they have no clue. Do what you believe in.
15. Textures. 90% of the time they are hand coded. A good general texture technique in 4k is hard. Dont forget rand() can look great when stretched, layered etc. Checks are too easy, Xor similarly. Avoid them. Chladni is great. Cellular is ok. You'll be looking at around 250-300 bytes for decent textures.
16. Shaders are the way to go. They are smaller than equivalent normal code and doing bump mapping, noise, phong, displacement mapping is all possible in 450 bytes or less.
17. Lastly the best advice I can give dont download and use code from the internet. Write your own, then write it again, then write it again. It will get smaller, and smaller.
Writing a 4k is easy but ten times more _work_ to produce a good one than writing an intro. The synth alone could take you months. My prediction: breakpoint last year was an easy target for 4ks, they were well below what was expected in terms of quality. This year I know some of the participants and they are *good*. Its going to be a good competition.
No, I wont be there- I'm retired. I shall be in Disney with my family considering how small a space I can get Mickey Mouse into ;-)
Chris
