Skip to main content

More screen size and premature optimization

Donald Knuth was right. Optimizations I had done for the gba are killing me. And it all has to do with screen size.

See, my engine wasn't designed to properly handle rooms that were smaller than the screen. The camera's position in the room is stored by a number that I assumed was always positive, because, being equal to or smaller than the room itself, I never had to go negative, or outside the bounds of the room. But now with the bigger screen, the camera is often outside of the bounds of the room. So I need to handle all these special cases where the rooms are smaller than the screen. Two things need to happen: first, it needs to just work right. Second, smaller rooms should be centered horizontally on the screen, (unlike the picture in my last post, which looks goofy being shoved up to the left), and bottom-aligned with the screen, so there is less overlap between the HUD and the game. So I've got that to do, which I've started on, but is messy.

A big chunk of the problem was because of stupid optimizations that I (needlessly) did. See, the gba and ds don't have floating point units. And can't do divides with any reasonable speed. But in unsigned binary, bit shifting right by 3 is the same as dividing by 8. And because the tiles are all 8 pixels, I'm dividing by 8 all over the place. So instead of telling it to divide, I bit shifted, to make sure it was fast. Now this was stupid, because a good compiler (which gcc most certainly is) will do this optimization for me. But I figured it wouldn't hurt to make it obvious that it was happening, and thus prevent the compiler from randomly deciding NOT to bit shift and do a slow division. BUT that doesn't work if your number is signed, which mine now is. This is because negative numbers are represented in two's complement. You can still do fast divides with clever bit-shifting, but not as simply as just shifting right 3 bits. So now I need to go change all those places where I was trying to be clever back to actually using a normal divide, and let the compiler do the optimization.

Lesson of the day: my compiler is smarter than me. Let it do the clever stuff.


cearn said…
"BUT that doesn't work if your number is signed, which mine now is. This is because negative numbers are represented in two's complement. You can still do fast divides with clever bit-shifting, but not as simply as just shifting right 3 bits."

Actually division-by-shift works just as well for signed numbers, if you actually declare the variable as signed. 'int' is sign-extended, 'unsigned int' is zero-extended.

The only issue with normal division and shifts is the rounding for negative numbers. (-1)/8 gives 0, whereas (-1)>>3 gives -1. But since you might actually want the latter result (because otherwise there's be no difference between -1/8 and +1/8), using shifts might actually be the right thing to do here.

And for the record, GCC will indeed change a division by a shift, but for signed ints will also add addition instructions to keep the rounding in accordance to regular division.

Popular posts from this blog

Retrospex 32 Review

RetrospexInternational recently sent me a couple units of their new handheld device, the Retrospex 32, a new dedicated GameboyAdvance emulator handheld.  To make the unit playable out of the box, they pre-loaded a handful of homebrew games, including Anguna, which is why they were kind enough to send me 2 of the units to play with.  I was pretty excited to get my hands on the device and try it (I loved my old GBA micro with a good flash cart!), and see Anguna running on it. So here's my thoughts after playing with it.

Their website lists the Retrospex 32 for £59.99, which is around $100 USD. It seems like it's marketed toward people into retro-gaming (which makes sense for a dedicated GBA emulator device). At that price, with that target market, and such a limited set of functionality (why not make it a multi-machine emulator, and emulate all the old consoles?), it would hopefully do a really good job of it.

The short version of my review: it doesn't. It has one job (emula…

Making the game fun

The real trick for Spacey McRacey (as I'm calling it now) is going to be making it fun.  And that's what I'm rather unsure about at this point.

I have a game design that basically works. The technical issues are mostly sorted out, I just need to get a few more implemented before I can seriously play test it.

But fun? It's hard to know if it's actually going to be any fun to play.  With a 4-player party-style game, it's seems like it might be hard to hit that fine line where everyone is close and competing, where everything feels exciting and tense, as opposed to tedious and boring.  And despite envisioning my game as fun, it might just be boring to play.

Some of that comes down to tweaking it. Tweaking the speeds, difficulties, etc, will make a difference. (If it's too easy to shoot people from behind, then it will be nearly impossible to hold a lead for very long, which could ruin it and make it no fun. If it's too hard to kill the guy in front, it wil…

Killer Queen

So at PRGE, I played an arcade game that just left me amazed.  Killer Queen.

It's a 10-player game. You have 2 cabinets linked together, and 5 players huddled on each one. Each one is a team of 5 people, working together to play a simple one-screen 2d platformer.  But what made it work was the high quality game design.

First, the game is relatively simple, yet there is a lot going on at once.  One player plays the queen, the most important and powerful character on the team. The others start as workers, but can become warriors who can fly around and attack in a very joust-like flappy contest of height.  The real trick is that there are three completely different ways to win: either collect a bunch of berries and bring them back to your base, or ride a REALLY SLOW snail across the screen (while other people try to kill you, and you hope your team protects you), or kill the enemy queen 3 times.  There's some other things going on as well (using berries to upgrade, capturing upgr…