Advertisement Jump to content
  • Advertisement
  • entries
  • comments
  • views

Week of Awesome III, Part 0: Preparations

Sign in to follow this  


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.
Sign in to follow this  


Recommended Comments

It's not open source yet. I'm planning to do that eventually, but right now it simply doesn't have enough features. And some of the features that it does have are partially implemented. 

Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using, you agree to our community Guidelines, Terms of Use, and Privacy Policy. is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!