Freshly Squeezed Progress Report: Crash Addressed, Better Placeholder Art

In my previous sprint report, I created an introduction script for The Dungeon Under My House, my second Freshly Squeezed Entertainment project, but I decided I wasn’t happy with it.

I also discovered a mysterious crash issue when I ported it to Android to test it, and I was definitely going to need to fix that issue.

Sprints 28: Pre-production and initialization

Planned and complete:

• Defect: Android crash when drawing ceilings in dungeon

Unplanned and incomplete:

• Revise character customization

After I finished working on the dungeon doors and basically having a working dungeon mode, I switched to focusing on the house and the intro script. At the time, I was able to create an Android build and verify that while the dungeon view needs optimization, it was functional.

So imagine my surprise after getting the intro script done and wanting to share it with others that the Android build crashes when entering the dungeon while my desktop build does not. Something was going wrong, and there were no changes to the dungeon rendering code between my previous Android build and my current Android build.

I found it frustrating to debug on Android, but after a few days of poking at code and adding logs, and yak-shaving to try and fail to get debug symbols so that LLDB could tell me what I was looking at, I could narrow the apparent issue to a crash when rendering the ceilings or the floors.

If I removed the ceiling and floor rendering code, the game seemed to work just fine. So what gives? Well, when I render the ceiling and the floor, I create a buffer of pixel data, then update a sprite’s contents with that data.

In other words, I did something like the following:

void drawCeilings()
{
    const int pixelSize = targetDimensions.width() * targetDimensions.height()/2;
    Uint32 pixels[pixelSize];
    // Figure out what to put into pixels.
    updateSprite("DungeonCeilingSprite", pixels);
    ...

The drawFloors() code is almost the same.

This code works. Or at least, I thought it did.

Maybe I had some memory getting trampling due to new code? I tried removing all that new scripting and triggers code, and I still saw the same problem.

Ultimately, and I wish I had a better way to confirm it is true, I think my game is getting a bit big memory-wise.

I came across something about being able to set the maximum stack size of a thread, and it made me wonder: what if instead of setting up the pixels on a stack, I create them on the heap?

So I made the following change:

void drawCeilings()
{
    const int pixelSize = targetDimensions.width() * targetDimensions.height()/2;
    Uint32 * pixels = new Uint32[pixelSize];
    // Figure out what to put into pixels.
    updateSprite("DungeonCeilingSprite", pixels);
    delete[] pixels;
    ...

And the crashes disappeared.

This experience did get me to fix a few minor memory issues that valgrind identified that had nothing to do with this issue, but it also made me wonder if I needed to shrink the PNGs I was loading into memory at the start of the game. I worry I’ll be running into a similar issue soon.

But let this be a reminder of what Brian Hook said in Write Portable Code: you can’t say your project is cross-platform unless you actually build and run it cross-platform.

Anyway, after I did a bit more testing to try to make sure the crashes were actually resolved, I moved on to do something I’ve been looking forward to for some time: making the characters look better.

All of the graphics in the game have been placeholders until I figure out the look and feel I am going for, but until then, it makes for some ugly screenshots.

Weeks ago I got tired of seeing nothing but floating heads, and I decided to give the characters bodies, but throwing a skin-colored rectangle under the face sprite was probably not my best idea.

This is supposed to be a family-friendly game, but quite frankly, this was a little too phallic-looking.

Sorry. B-(

So now that I’m addressing the characters, I decided to give them better placeholder bodies.

My old attempt at a placeholder body was simple but problematic (in a different way). I was drawing the head, and then attaching the body to it, but then I needed to guess or do extra math to figure out where to place the character vertically so that the feet end up where I want. Some characters are taller or shorter than others, after all.

Now I start from the feet and go up. When I say where I want the character to be, their feet will be in that location. No guesswork.

Humorously, I did see what happens when I don’t correct the character location values.

But how does this new placeholder rendering, which is only slightly better than before, help with player customization?

Well, I have new menus in mind for character customization. One menu will be allowing the player to customize the body in terms of skin color, height, and size. Another will allow customization of facial features. Another will customize clothing.

So for now, my rendering code takes into account skin color, face type, height, and size, properties that are available in the character code. When I add the menus to modify those properties, I can see when they take effect immediately.

Unfortunately, chasing down that crash bug meant less time to dedicate to creating those menus, but I hope to make significant progress, including updating the face art so that it is a lot less placeholder-y.

Thanks for reading!

—

Want to learn when I release The Dungeon Under My House, or about future Freshly Squeezed games I am creating? Sign up for the GBGames Curiosities newsletter, and download the full color Player’s Guides to my existing and future games for free!