Moved to ltgamejam.org/2002
Of year 2002
Main LTGameJam page here
LTGameJam at SourceForge
2002 08 17
I've gone through the not-so-easy task of documenting the engine! Doxygen gave me a pile of html's; also I've drawn some UML (the rest is still todo).
The engine seems to be nearly completed. There are some missing things, but we could keep adding them for ages - there's always something missing :) So, I'm marking it as "Release Candidate 1".
2002 08 13
Time to merge my (NeARAZ) and ReJ's code... We couldn't easily agree on some things, so we tried all the combinations :) It's clear that his entity renderer is better; but we're still in doubt about his vs. mine entity system...
2002 08 12
Almost accidentaly I've written a game! It's an extended version of the "Rail game", this time with peaceful and angry gods also :) See it in development files.
The system of entities and user interaction is now the "indirect one" (see somewhere below). It has proved to be faster and fairly comfortable to use.
Shuffled the source files layout, the game classes, etc. Started writing source comments, tried Doxygen - it works :)
2002 08 10
Game idea: Babel tower game (by Aiste). There are different colored people running round on the map. Colors represent the language they speak. You select rectangles (or circles, etc.) of them to combine them into one. If among the selected ones are 70% (or 80%, 90%, etc.) of the same color, then you succeed and they turn into a big "unit" (or man) of the major color. If you fail, something bad happens. The task is to combine some not-so-small amount of single colored people to finally build the tower.
Two cases for interaction with entities:
2002 08 08
ReJ was trying various ways (and hacks also :)) to speed up the rendering. At first I did the rendering as such:
Also we noted a couple of interesting things: filling the VB, but leaving some parts untouched (like texture coordinates in NOOVERWRITE portion) does not speed up things at all. Knowing we're RAM limited, it's kind of strange. Maybe it's some of AGP specifics?
CPUs and FPUs nowadays are too hard to understand. We have 5 vector3-scalar multiplications in one sprite. Commenting out the first one speeds up calculations by 50%. Commenting out the just the last 4 (leaving the first one) speeds also by 50%. Commenting out one of the last 4 does not speed up things, and occasionally slows them down. Also: inserting redundant code (that isn't executed at all) sometimes speeds up things. "The pipelines and superscalar things are roots of all evil" - the conclusion :)
I (NeARAZ) have coded up a "Rail Game". See it in development files. For that game there's a division of playing space into sectors, each entity knows the sector it belongs to, and sectors manage pointers to entities they contain. With this structure, I'm able to find intersection of some ray and entities (and also do collision, proximity queries, etc. etc. - not done yet).
2002 08 05
Dilemma: should we try to hide the engine from the programmer, or should we expose it? Exposure is good for such a project, but we fear that the programmers would dig into the engine instead of writing games :)
Just to check: physics for each entity can now hold it on the terrain all the time, let it fly or let it fall with gravity. I've spotted no difference in speed. So: we're pretty ok with branches in the code. We're not ok with RAM :)
So, what I would do:
Game setup scenario:
A dilemma to resolve: should we have (stochastic) collision detection? Or will the "underlying grid" system be enough? In the latter case: should the sectors know which entities they contain now (and so for the entities)? The knowledge introduces some overhead, on the other hand, it has it's own advantages...
2002 08 04
Checked out IndieGameJam sourcecode. It was similar to what we would do - pool of entities, single big texture, space subdivided into sectors, etc. What we haven't thought of is the idea of game updates affecting only a subset of entities (thus bypassing the main bottleneck - RAM throughput). It seems to be a good solution.
On the other hand, I was a bit suprised. They use plain C nearly everywhere,
The vision I see now is:
Specially for ProNinja: maybe we'll have a collision detection! (as it was said, stochastic only).
Code, code, code... The codind is not as fast as it used to be 2-3 years ago. I think a lot more (what's the better way? how it will integrate into the whole thing? etc.). Is it good or bad?
2002 08 03
With 100k entities you very quickly reach system RAM throughput limit. CPU limit comes the next, and GPU the last. 100k sprites == 400k vertices, that's "a breeze for GeForce" (needs to be read in female voice), as said in one old nVidia demo movie.
But even the CPU limit is not so high: if we process every entity at 10Hz rate, and let us "burn" something like 500MHz (leaving other for rendering, driver, Windows, etc.) - that's 500 cloks per entity. Kind of low...
Something has to be done. Process entities in groups? Cache something (like colidees, paths, etc.) by location? Or have 10k entities... or 5k...
Some game ideas: