Day Three has begun! - tech review, quadtrees, opengl3.0/ES1.1 compliance

gordallott on 2009/04/28 11:53 of Cine-Science Logic 2

Well its day three and i'm fairly confident that the game will be finishable by Saturday night, Its actually not been too hard for me this time, our game idea mostly requires zb to produce mountains of artwork, might i say what a fine job he does at that though! If i can keep him focused until Friday then we'll be fine ;)

I thought I Would take some time out to talk about a few of the technologies that I have been using in the backend.

• The most interesting thing I have been playing with this time is QuadTree's, No one else seems to go for them for some reason, favouring one giant list of objects to render. I used this method last time and ran into problems, ended up having to create large display lists of large area's of geometry just to reduce the size of the python list. Lesson learnt - python does not do well with giant lists.

  Quadtree's however a nice idea, you partition the world space into buckets, once the bucket gets full you split it into four more smaller buckets, in doing this you create a tree of spacialy organised data. Retrieving the items that are in a certain spacial area is trivial then. Quadtree's basically let you create worlds as big as you like without having to worry about speed problems :)

• The second technology I am playing with in this setup is trying to stay true to the backwards incompatible ideals of opengl 3.1, the codebase does not require opengl3.1 in any way (at the moment it should work on anything that has vertex buffer object support) but its a rather interesting way of coding.

  Basically the major change is the removal of

  glBegin() ... ... glEnd()

  Instead you are now encouraged to create vertex buffer objects for everything in your scene, Its a system that works quite well and is especially speedy if your not switching buffers too much. I'm not going 100% gl3.1 though, namely in that 3.1 glTranslate() and such are depreciated in favour of you modifying the matrices yourself, I have done that in the past and its not the most fun, especially not in python, that would be rather slow :)

• Oh and as usual inkscape is being used as our level editor, not much to say about that though apart from this time i designed the game to be using inkscape from the ground up rather than hastily adding it half way though, the code is much cleaner :)