i read something about this a few months ago, they use some kind of custom EXE compression (kinda like UPX).
the progress bar at the start is the loader decompressing all the data to run the exe. (notice how it uses around 250 mb of memory)
and im not 100% sure but i beleive they use assembly.
Last edited by X PaYnE X; 11-18-2005 at 12:35 PM.
The bar isn't just the decompression. They also generate stuff on the fly, so they have a general model, but the what you see was generated when you started the game.
SoKrA-BTS "Judge not the program I made, but the one I've yet to code"
I say what I say, I mean what I mean.
IDE: emacs + make + gcc and proud of it.
I've done something similar, although not as fully featured and it used more memory (I still do everything with the fixed rendering pipeline, I don't like using shaders)...understanding the trick to do something like this requires a complete shift in what 'data' is. Instead of storing data, you store the algorithm for reproducing the data in a program. The space required to store the algorithm as computer instructions to reproduce the data is, in this case, about 1000 times smaller than what the actual data would require.
Every polygon, texture, and light are all transformations of a single polygon, texture and light. That is the basic idea for at least one aspect of the program.
Actually making a game like this in 96K just requires a godlike understanding of how to store the data as 'algorithms,' and I have no clue what they coded it in (but I doubt pure assembly).
I'm not immature, I'm refined in the opposite direction.
I never thought of it like that before. I would love to see their source.Originally Posted by BobMcGee123
