Today's work

Today I added proper "3D" fixture (shapes) management to our game objects. Up until now, we've had issues with 3D fixtures not being properly removed from the world. When a 3D fixture is created, it's added to a global list of renderables, so if the fixture isn't disposed properly, its 3D model will remain in the world forever and ever and ever. I did a pass over all the level objects and made sure that they're being disposed properly. This solved a couple of problems, like a breakable wall not being removed properly when broken through.

Although we're writing the game in Java which (for good or bad) has a garbage collector, we still need to be very careful with memory allocations because the Box2D binding of LibGDX is actually a native library running in C++. Hence, all the rules of C++ applies, meaning we need to allocate and deallocate things manually most of the time.

Comments

Post a Comment

Popular posts from this blog

3D graphics work

So I suck at writing blog posts, so time to pick up the slack. The last week was mostly work on adding proper graphics. So far we've been relying on the built-in debug renderer in LibGDX, meaning that we had simple but decent graphics for everything we added to the game automatically, but we also had zero control over how it all was drawn. Last week me and Conrad discussed the style we wanted for the game. We considered a number of different styles, including different kinds of both 2D and 3D graphics. Although the physics simulation is purely 2D, that doesn't mean that the rendering has to be 2D as well. At the least, it is possible to add some amount of depth to the scene using "fake 3D". However, in the end we opted to go for actual 3D rendering for the game, mostly because to get the effects that we wanted it was easier. The rest of the week was spent testing out the 3D capabilities of LibGDX and implementing what we needed for 3D rendering. I first did some
Read more

Last stretch

The last week has been really frantic. Yesterday we finally did the dreaded merge of the master branch and the 3D branch. The 3D branch contained all of the new 3D graphics and changes in almost every single class to accommodate the new 3D graphics. I had added a new camera management and rendering system to allow each 2D physics object to also have a 3D representation with certain parameters (such as depth to allow for more shapes, a z-coordinate to allow us to offset the arms and legs in 3D, etc). This meant that anything that had a physics object had been changed, so the merge was tough. Lots of conflicts everywhere and it took quite a while, but in the end it went as smoothly as you can hope for something like that. The last really big remaining issue was the crashes we were getting for seemingly no reason when creating a new physics body. As Box2D is a C-library and the crash happened in there, that meant complete JVM crashes. I got a hunch that the problem was caused by pooling
Read more