Check the KazRace page, where I gathered a few infos as well as the link to the source code, which is now freely accessible.
I gave the Java source code to a few people before, but before being of any use, it clearly needed some refactoring. I don't envy those few that tried to make sense of the code as it was 8)
The code was written for speed under Java.. making me resort to using fixed point values here and there and also to use 1D arrays as 2D arrays, where in fact I wanted just arrays of structures.. but in Java a structure has to be an object that is dynamically allocated and I didn't want that !
The code clearly needed some major cleanup. Both logically and more general refactoring. Last time I looked into it I also didn't have any refactoring tools.
I think that nowadays refactoring is fairly well supported for Java. Nonetheless, I just decided to clean the code while moving to C++ and where I'm a lot more comfortable. Again Visual Assist X proved invaluable for the process of renaming tons of variables and methods.
It's not all being cleaned up (some members still use the "_member" notation versus the new "mMember" which I've been using recently), but the game mostly runs. There are some artifacts, mostly due to some memory not being cleared to 0 8)
Java clears all memory to 0 by default.. in C++ one has to do it manually..
Practically all dynamically allocated objects are kept with some sort of smart pointer facility that does delete the object when the smart pointer gets destructed.
Arrays use stl-like vectors and arrays of objects that own objects are overloads of the stl-like vector that deletes those objects when the vector gets destructed.
Memory management is a complex topic !
I don't like systems that do the garbage collection for me. It's very useful, but I think that it doesn't scale well for larger programs, where a lot of objects are allocated but they are also allocated with a certain hierarchy.
So, to create a texture object, I prefer:
Texture *pTex = pDevice->NewTexture()
Texture *pTex = new Texture();
This can also be achieved with C++ when using placement new.. which means running a constructor using your own memory area, but also means overloading the new to accept some sort of allocator parameter. So, in the case of the Texture object, the placement new should take a pDevice pointer.
It's not so much about having a custom allocator, but more having a concept of hierarchy. This is also important for multi-threading, where global resources are a pain by definition.
Anyhow.. zzzzz !