With the start of the week of awesome III rapidly approaching I decided to make some changes to my personal game library snowy. Previously I could only render sprites in snowy, and while that is sufficient to make a nice game with I also wanted to be able to use 3D models. So I refactored my SpriteRenderer class to create the vertex buffers in a much more general way. Secondly I extracted a Renderer class that deals with binding the vertex buffers and making the actual draw calls. This way the classes that inherit from Render only have to deal with providing the data to fill the vertex buffers with. It's by no means perfect but simplifies specifying the layout of vertices a lot.

I also wanted to be able to use 3D models created in Blender. Specifically the Wavefront obj format, since that is exported as plain-text and it easy to parse. Writing the parser was pretty straightforward until I discovered that the .obj format uses separate indices for vertex position, texture coordinate and normal. It looks like this:f 25/36/38 26/37/37 257/250/257
Here the 'f' indicates the definition of a face, in this case a triangle, and the numbers are indices to the positions, texture coordinates and normals. Unfortunately glDrawElements expects an index array where the position, texture coordinate and normal all are in the same order, and so being able to use the same indices to render them. So I had to remap and combine the texture coordinates and normals to the same order as the list of positions. It was a bit tricky but it does have the added benefit of smoothing the normals of the mesh.

After I made a quick and dirty potion model in Blender here is the result:


It might not look like much but it does mean that I can use any kind of 3D model created in Blender which I hope will proof to be quite the benefit during the contest.

Lastly I also went over my collision code to look if I could make two dynamic bodies interact reliably. I had written my own collision code after I found out, while making a breakout clone, that Box2D doesn't handle reflective collisions reliably. The moving pellet kept getting stuck to the breakable blocks. Using my own collision code, using ray-casts pretty much exclusively, I got it working perfectly. This code didn't support collision between two or more moving bodies yet, so I went back to take a look. Turns out that making collisions like that is way harder than I though. (Stack of boxes anyone?) So if I'm going to write a game that requires complex 2D physics I'll use Box2D but if simple and precise collisions are necessary I'll use my own collision code.