Ethan

This morning, when I was testing Carl's new death animation for a certain enemy, I thought, "It's too much work to set up a level to test this easily; I'll just play through the level where the enemy appears, and kill him the normal way." But then for some reason I didn't. I wrote a level called test-bossdeath and it took me about two and a half minutes. And then I used it four or five times to test the animation. And I'll end up using it more, now that Carl asked me to implement sprite deformation. Each test would have taken a four or five minutes or longer to do the quick and dirty way, versus ten or twenty seconds with the custom level. It was tempting, but it was a false economy.

It's easy to think "I'll do things the quick and dirty way right now; I just don't have the time to do it the right way." And it's easy to say "I'll do things the right way here; it'll save time in the long run." And I guess it's easy to get wrong either way. Still, I'd like to document that at least sometimes I make the right decision.

FYI, Project Alexandria doesn't have a "test suite" as such; it's very difficult to write a test suite for an interactive program. But we do play through levels every now and again to see if they still work (sometimes they actually do).

Ethan

Ethan

I read through the FastRenderGroup stuff that DR0ID wrote and liked it, even though the dirty-updates stuff isn't really sensible for a game like Project Alexandria. There's some code in there that "simulates" layers of sprites by storing all the sprites in a list. The lower-layered sprites are earlier in the list, so the higher-layered sprites are drawn over them. I thought it would be faster than the dict-of-Layers stuff I had in the View class, so I wrote my own LayerGroup that does the same thing. It didn't get me nearly as much speed as I thought it would (it bought me like .2 of a second over a 30 second run). Sigh.

Work still needs to be done in order to get the station to run at the right speed. I have two optimizations left that I know I can do.

• Merge images in backgrounds. Images in geometry sprites are already merged, but in backgrounds, they aren't. This won't gain much speed, but it will ensure that we don't lose speed as Carl adds more art.
• Only draw parts of the background that are exposed by the level. This should speed things up a little bit, but I don't know how much.

Once those are done, I don't know what I'll do. I wonder if SDL has z-buffers? Ha ha..

In the meantime, Carl's been arting up the place, and new labmate Chiz started rewriting the dialog! I added him to the roster.

Ethan