Posts Tagged ‘performance’

Day 2.5 recap

Posted by (twitter: @Eliot_L)
Monday, April 23rd, 2012 4:06 am

The second day of the jam has been worse than I hoped, but better than I feared. I managed to tackle the performance issues we were having earlier by switching to the OpenGL renderer in Processing, which incidentally also fixed the huge memory leak.

So, here’s the first thing you’ll see when you load up the game:

Daniel created some really dope art today and I was happy to get it into the build along with some graphical effects like animated sprites and a scrolling background image.

Daniel’s friend Optomon also is writing us an awesome chiptune soundtrack. Here is the first part he sent over.

Here are some screenshots to show off what the game looks like now:

I ran into a ton of technical issues today but wound up working through them all. I finally finished defining all of the level geometry as arc segments, so you can run around the level and collide with the walls and ceiling too. I got basic bullets working, and they travel along an arc. The animation system was a doozie but it’s all working really nicely now. I learned more about OpenGL and it seems less daunting than before, and now I’m wishing I had more direct access to the OpenGL API from Processing!

Some things seem much easier and more efficient to implement in low-level OpenGL, such as my scrolling background. If I could have just accessed the texture directly and set GL_TEXTURE_WRAP_S to GL_REPEAT, it would have saved me a lot of trouble since I could have just animated the uv coordinates of the texture instead of having to move two images around. I spent nearly 3 hours trying to figure out how to set GL_REPEAT from within Processing before throwing my hands up.

It wasn’t a waste of time though, as I was able to apply what I learned to the animation system to flip a sprite horizontally by inverting the u coordinates and drawing them to a texture I defined manually in Processing. This saves on memory and disk footprint since I only need to load sprite assets facing one direction, and hopefully helps with performance as well.

Daniel and I both have work tomorrow, so we are going to have to submit the game as-is before the jam deadline. Right now there are no enemies and no win condition, but we plan to keep working on the game after Ludum Dare is over since the hard part (at least for me) is done. Now, on to the fun part, making it into an actual game!

We plan to submit this build before the jam deadline tomorrow evening, once we have some new music.

Day 1.5 recap

Posted by (twitter: @Eliot_L)
Sunday, April 22nd, 2012 5:04 am

We’re currently 35 hours in and have some decent progress to show. I got a full player movement and collision system working using arcs to define platforms and walls. You can now run and jump around the level, and the ‘camera’ follows you.

Here’s a screenshot of what the game looks like now, complete with debugging info on collision arcs and background tiles:

I figured out a workaround to the issue I posted about earlier thanks to the help of some twitter buddies. Thank you also to everyone in the LD community who chimed in. I am splitting arcs that cross the polar axis into two arcs, and everything works fine so far. You can see the seam of the axis, i.e. 0 degrees, and the arcs that cross it have been split in twain.

I thought you all might be interested to see how we made this level and translated it into code, so here is a screenshot of that process in action:

Daniel designed a level on paper using a compass, and scanned it in so he could paint it in Photoshop. He then sent me the image, which I measured using a handy screen protractor (which doesn’t have a setting to measure angles clockwise, WTF!) and entered into the giant blob of setup code that is our one and only level. I worked out a function that adds a ring segment based on its start and stop angles and ‘valence’, i.e. what level it’s on. It figures out the maximum and minimum radius of each arc segment based on the even spacing that Daniel set up in his design. So that has sped up the process quite a bit. You could say that without it, the process of making levels would be too protracted. Ba-dum psshhhh.

Now, for some technical rambling…

I’ve been having some pretty disheartening performance issues in Processing.  It’s a prototyping tool that excels at real-time procedural graphics – it doesn’t do so well when you expect it to be blitting bitmaps to the screen at 30 FPS. As soon as I threw in some background art, the framerate dropped significantly. I tried reducing the size of the art and scaling it up in-engine but the exact same issue persisted. In a hail-mary attempt, I rolled back from the Processing 2 beta to Processing 1.5.1 so I could try the now-deprecated P2D renderer. And what do you know, it performed way better than the Processing 2 2D renderer, Java2D!

Unfortunately, since the level is laid out in polar coordinates, it’s a pain in the ass to line up raster graphics since they are all rectangles. Also, my jam partner Daniel requested that we use raster graphics so he can paint them in Photoshop.

What this amounts to, for a 1024 x 768 game like ours, is a level that is 6144 x 6144. And we can’t build platforms out of standard square tiles since the entire level is curved. So we split the image up into 1024 x 1024 slices and tiled them in-engine in the hopes that we might save on performance somewhat, since I can cull tiles if they are out of the camera’s view. This doesn’t seem to be helping a ton.

Also, the image loading needs some tuning. I was loading everything at runtime but the load time for the game was awful that way. So I switched to asynchronous loading on an as-needed basis, but now I’ve created a thundering herd, each thread requesting a 1024×1024 image from disk at once! And there are 18 of these during launch to load the images at and around the player. I think I’ll need to throw these image load requests into some sort of prioritized queue so I can throttle them. I also need to make the game update steps independent of framerate.

So overall, perf is in pretty bad shape now, and I’m apprehensive about what things will be like once we start adding animated sprites for the player and enemies. Also, it appears as if the P2D renderer may have a really bad memory leak, my swap file grew to 8 GB when I was testing the game! Bleaahhh…

I’d like to learn openFrameworks for my next game, maybe I can optimize the rendering better. There remains the option of me trying to implement my own renderer on top of Processing’s P3D (OpenGL) renderer but god knows if that will help at all.

There’s a ton of stuff to do tomorrow. i.e. turn this movement/art prototype into a game!

Good luck, and rest well, fellow jammers!

[cache: storing page]