pouët.net

I have a question regarding 64k intro code. Though I have experience with a "usual" graphics code, I’ve never tried to code a nontrivial 3D engine in 64k. So I would be grateful for some clues concerning how much of the code should be, well.. hardcoded. Since it is size-constrained category, I imagine, that code reusability is not primary goal, and most of the routines are as customized as possible. But to what extent? Lets take for example a list of materials. I assume STL is out of the question(event at work, where we don’t do hardcore sizecoding, exe size thanks to STL was huge problem). So how do you guys do it? I considered two alternative solutions: static arrays, or malloc/realloc/free, both wrapped in templates to eliminate code duplication IF it would not affect exe size much(it is possible to write templated code which actually generates smaller binary footprint).

Use C :-)

But those problems are actual for C as well(static arrays vs heap allocated memory) :) Actually I was going to program this intro with procedural approach, but using the C++ compiler, to eliminate use of "beautiful" macros from D3D10.h

64k is huge, you should be able to fit the Universe in it.

Also I wonder about things like static pools of state objects and vertex layouts. Normal approach is to write general code for building them, and then creating them up-front. However this afternoon I wrote quick and dirty implementation of simple mesh generator and stub 3D engine, and, well, even at this stage I see that executable is going to be too big. Looks like I will be forced to remove even some of the core, performance-oriented code :/

Decipher: Well, after ditching out CRT, writing fp function replacements and compressing the exe I thought so too :)

Apart from a bucket of hints and examples people can probably give you (I myself haven't size-coded anything 64K or less since 2002 so I'm not going to be of much more help than stating the obvious) -- just try it out. Keep in mind what you compiler generates (and do not forget that it is often very well able to reduce redundancy by itself, so don't discard what might look 'big' in terms of unfolding per-se), check out disassembly and have a peek at your executable section sizes -- and more importantly: what's occupying them.

Using an STL container here and there won't kill you. Just keep an eye on what your code generates and what possible static library functionality you're importing - apart from that: procedural data.

But there are a lot of people here who can give you a better heads-up on that.

you->your

If you're already being killed by code only in a 64K project, given that you're not taking things over the top and compress your executable: there must be some kind of oversight.

niels[tpb|bps]: Thank you for advice.



I was not precise. It's not like I went over 64kb already, but adding some code to support shader functionality caused executable to grow by 2Kb to 3.9kb in total ;>. It was my mistake.

Wrapping in templates to eliminate code duplication? How does that work?

doom: instead of writing code which adds/removes elements from different kinds of lists(shaders, textures, meshes) you write one version. Sure, internally it is instantiated as different codepaths, but you don't have to repeat the same text.

Take a look at 4k demo engines:
http://in4k.untergrund.net/index.php?title=Main_Page
Then you've got 62k (compressed) of space to waste on whatever, which is immense.
Re-use EVERYTHING. Make a parameterized effects/geometry constructors/texture and feed them a bunch of different sets of data.

the again, if its all inlined anyway it doesnt matter if its templated or not sizewise.
heres some advice: keep an eye on the proliferation of constructors, destructors and copy operators. if you can memcpy (or memset) you'll save yourself a bunch.

GbND: THAT is impressive :)

Basically just what templates were. mostly, made for :)

Well depending on what your take on 'shader support' is, 1.9kb of code isn't that much of a hit (4K coders will disagree here, but that's not what we're after now). But it should be fairly easy to look at what eats up the bulk of space in your executable in regard to that code?

No telepathic skills here :) As for that templ. dupe issue, don't worry about it too much. It'll become very clear when a mistake in that area has been made (dumps!) and it's probably going to be the least of your worries.

smash: I was going to use mostly procedural approach, but I will keep that in mind.

I solved that problem already :) It was simple mistake as I stated before.

Good ones to keep in mind. And compiler settings.

I know what templates are. :) I'm more interested in how compile-time code generation reduces the size of your executable. Is the resulting code more packer-friendly somehow? You'd think minimising the use of templates would be the way to go.

That is a matter of trial and error, or at least seems to be with Microsoft compiler :).

It always boils down to heuristics, so its that way with all of 'em.

Is using D3DX allowed in official 64k compos?

What Decipher said. I've always done all hardcoding, too...that helps.

In 2007 Waffle and I coded a cute little 40k called Purple, which was really quite easy to get this small. We worked to add bytes in the end, not take them away :)

The point I'm trying to make is really you shouldn't worry that much about code size in 64k, it's data you're really gonna have to worry about.

And about D3DX, read the specific compo rules. Quite alot of compo's allow it nowadays.

doom: well function calls arent exactly free. inlining and external packing can be very nice. problem by doing it with templates is that you cant fiddle around with compiler settings as much as if you do function style, say attempt inlining some stuff by forceinline and the like.

in general id say; dont focus on code until the very last. it doesn't matter if you dont do anything extremely silly. focus on how you mangle data for sounds and graphics (including 3d).

Hatikvah is right. Code optimizing at the 64k level really isn't that much of an issue compared to the size of your compressed data.

Also, with music, 64k's used to customarily use MiniFMOD and .xm files with small samples. This compressed well but didn't sound that great as compared to the more recent synthesizer approach, which is much more common nowadays. I think at this point the MiniFMOD thing might be completely phased out (someone correct me if I'm wrong here).