gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

Coding > Why is this game so slow?

#37653 - philip - Mon Mar 14, 2005 8:29 pm

Hi,

I've written this simple little driving game where you go around picking up items and delivering them to somewhere else. Trouble is, it's much slower than I think it should be on real hardware. I've removed all the trig and floating point maths, but it still won't run at 60 frames a second.

You can find the code at: http://www.vertex.ukfsn.org/pickup/v12/main.c

The support files can be found here: http://www.vertex.ukfsn.org/pickup/pickup_src.zip (The "main.c" above should be used instead of the one in this archive)

I think that maybe I'm not handing off between the mainloop and vertical blank interrupt correctly, or it could be I'm just too slow. Does HAM have a large overhead?

I've posted this previously on the HAM forum, and somebody suggested it seemed to be using a lot of divides. In fact, most of the divides involve only constant terms. I have confirmed these are being calculated at compile time and are present in the intermediate assembly code as pre-calculated literal terms. There is only one actual divide per frame, plus a lot of bit shifts.

If anybody could tell me what was wrong here, I'd be eternally grateful!

#37660 - tepples - Mon Mar 14, 2005 9:33 pm

You seem to be running your program in an emulator. Have you made sure to turn off frameskip? If you are running your program in VisualBoyAdvance, does VBA indicate that it is running at 100 percent speed? How fast is your computer?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#37671 - sajiimori - Mon Mar 14, 2005 11:57 pm

In your collision function, you're using && where you probably meant &. The result is that the conditions succeed on any nonzero tile values.

If it's still slow after fixing those bugs, the text drawing might take a long time (if it's variable width), and I don't know how much work ham_InitMapFragment and ham_InsertMapFragment are doing, but if it's a lot then that's something to consider because they're apparently done every frame if you're not driving fast.

#37754 - philip - Tue Mar 15, 2005 9:21 pm

sajiimori wrote:
In your collision function, you're using && where you probably meant &. The result is that the conditions succeed on any nonzero tile values.


Well spotted! The reason this bug got through is because I actually only use two types of tile, making the results identical. Unfortunately, this isn't the reason it's so slow, and nor are the text and map functions, which are only called infrequently (those map functions aren't called every frame; only when we reach a pickup/dropoff point)

So, using the first rule of stubborn trouble shooting, I've stripped the program down to it's simplest form. I've just left in the main loop which receives our control presses and drives us around, and wouldn't you know it, that's slow as well, but not all the time!

Turns out it is slow when: we drive straight up, we turn, or we are moving slowly, but just watch the frame rate pickup when you turn slightly off centre and reach a certain speed! (and then slow down again when you turn, or point straight up) I wondered if this could be a problem with the accuracy of my fixed point maths, rather than dropped frames, but if that were the case, it'd be broken on an emulator as well, which it isn't.

You can find it here: http://www.vertex.ukfsn.org/pickup/pickup_stripped/main.c

and get the ROM here (you must run this on hardware, otherwise you can't see the problem): http://www.vertex.ukfsn.org/pickup/pickup_stripped/PICKUP.gba

So, if anybody likes a good trouble shooting mystery, please take a look and put me out of my misery!

#37759 - jma - Tue Mar 15, 2005 11:17 pm

I'd put serious money down on this line right here:

Code:
frameready = 1;


Seriously, unless your vblank occurs after that and before the beginning of your (very large) if, it is going to be skipped. Your game isn't slow, you just aren't entering your if very often. Put that line inside the if and see what happens then. I think you'll be pleasantly surprised. :)

Jeff M.
_________________
massung@gmail.com
http://www.retrobyte.org

Last edited by jma on Thu Mar 17, 2005 1:17 am; edited 1 time in total

#37812 - philip - Thu Mar 17, 2005 1:15 am

That's it! Thanks Jeff! As I thought in the original post, I thought I'd probably done something stupid, because there's no way it should be so staggeringly slow with virtually no calculations.

It's now running like a dream. Check it and my other game out at:
http://www.vertex.ukfsn.org

Any feedback would be greatly appreciated