Game prototype current status

Phew... a few days since I don't blog anything about CRP. First reason, holidays are over, I'm back to "routine", and since university takes a lot of time (after all, engineerings are engineerings), I've reduced the amount of time that I spend working on CRP. Of course, I could work on it on weekends or in my free time, but I also want to enjoy my free time, without computers, just hagnging around, having a social life, running or whatever, you know. Of course, I'm not saying that I'm stopping, I'm still working on it. Less commits a day, according to my Git repository stats, but it's still moving.

Also, I don't blog because I'm not adding new features for now, instead I'm improoving the ones that the game already has.

For instance, I'm working on a more lightweight rendering system. At the moment CRP attempts to render every single tile of the city every single frame, even if those tiles can't be seen by the player. Right now, map is hard-coded to be 16x16, that makes 256 tiles to be rendered per frame, and about 75.000 tiles per second in my old Core 2 Duo computer that I use to develop my software (laptop keyboards are lame, long life to old-and-noisy desktop keyboards!!!). I increased the map dimensions to 256x256 tiles (65.536 tiles per frame) and the results were that FPS dropped from 200 FPS to about 2 FPS.

This improvement is linked to the city logic improvement. I'm splitting my city into regions. Instead of having a big, big map full of tiles that I call "city", I'm creating some little maps called "regions", and I'm considering now a city a set of regions. Those regions work independently ones from others, so instead of rendering cities, I can render regions, based on if they will be visible or not. To the user, those regions don't exists, and he sees the map as a single big city, just like it has always been. Even road connection will continue working between adjacent tiles from separate regions.

The game is also being ported to states. Right now there are no states and my game is just overriding Slick2D's BasicGame class. This is becoming so tight as the game keeps growing and growing, that I've already started to convert the game into a state based game. The earlier I do this, the less painful it will be. I've already created three states: one for the actual play, and other two for loading and saving the city. City is a shared resource that all the states can access to. At the moment those extra states aren't visible because loading and saving takes just a few miliseconds, but it should be visible as I add new features and change the saved game format.

After I complete all these improvements, I'll tag that code as version v0.0.3. However, it's most likely that I won't share that release as there are no new features that I consider people could enjoy. Plus, I worked last monday on a launcher that would replace current game deployment system. You'll have more details about the launcher after I polish and release it and talk about it on its own blog post, but just to give a sneak peek, the launcher will replace the user: it will automatically connect to a CDN that I'm using to host the game assets, and it will download, extract and link the game. So, next release won't be a Zip file that you have to manually download from my Dropbox account and extract on your desktop, but a link to the page where you can download the launcher. Period. Easy.

Also, this is probably the last pre-alpha release. The game is already getting a plot, a name (Drive To) and even a Facebook page. Once it's ready, you'll see Drive To v0.1, first alpha release of the game. No more sandboxed prototypes, let's make this thing real, bi*ch.

And, pretty much, that's it. This has been a long post after all. My English is not as clean as I would like to, even if I have a good knowledge of it, so I'll just hope that it's understable. You know, the longer you do things, more risk you have in failing them.

Garbage Collector is garbage

Whenever you are playing around with OpenGL and LWJGL in Java, say LibGDX, Slick2D or pure LWJGL, please keep this in mind: Java Garbage Collector is NOT your friend. There are a few reasons that make it suck for games. One of them is 'the moment' it chooses to start working. If Java garbage collector is messing around during our main loop, it may cause it to take longer to complete each cycle, causing our game to lose FPS.

There's another reason to hate Java garbage collector: it doesn't work with video RAM. Whenever you load a texture on LWJGL or any LWJGL-based library, actual image data is loaded as a pixmap on video RAM. OpenGL stores graphical data on video RAM so that your graphics card can access faster to it.

However, video RAM is not the VM heap. That means that Java Garbage Collector won't free your textures -you must do that manually, by using the appropiate method depending on the platform you are using, dispose() or destroy(). If you don't release your textures, you will end with memory leaks and your will require a lot of memory: this might not be a problem at all on desktop platforms, but if you are planning to release a mobile phone game, you should be aware of this.

Remember to destroy your textures once you aren't using them. Doing some image = null is not enough: as I said, that won't remove your pixmap data on video RAM. Plus, if you remove all the references to your texture, it's over: you won't be able to destroy the pixmap and that memory bank used by your pixmap becomes lost and wasted until you close the game.

Aside note: make sure to destroy textures that you aren't using. Sometimes pixmaps get shared across multiple texture or image objects. Consider the following example in Slick2D: you load an Image, then you create a SpriteSheet, and then you use an Image array to reference three sprites. You are using five objects here, your original image, your spritesheet and three references to some subimages of your original image. However, they all will be sharing the same pixmap on video RAM. If you destroy that pixmap, you destroy the pixmap for all of them. So, if you are using a spritesheet, a tileset, a bitmap/AngelCode font, be careful on deleting pixmaps.