VBA-M Forums

I just found this to be interesting:

The game uses Mode 4 (240x160, 256 colors, double buffered).
The game swaps buffers only every third frame of 60Hz, so it actually runs at 20 fps.

Why is that? Because the backbuffer is rendered in three steps, as you can see here:




I also noticed that nearby enemies are drawn on top of the protagonist, even if they are behind him. That's probably related to that three-step-rendering process. This happens on real hardware (Nintendo DS) and is exactly emulated by VBA-M. The game & sound speed seems also to be exactly the same as on hardware.

Neat information. I remember when I was looking at the performance of this game, if you let the GBA execute 1 instruction every cycle (never going to happen on a real GBA) until an idle loop or halt SWI, then what you see is one frame where it uses the CPU full stop, then one or two (can't remember exactly.. two would fit your explanation) where it does close to nothing. Even on a real GBA it'd probably still be doing at least 150,000 or so instructions during that first frame, since it's optimized ARM code that's running. This is quite a bit more than typical GBA games will run at.

Having auto-frameskip helps hide the unbalanced performance due to that first frame.. and it doesn't make the gameplay experience worse if it's synchronized right, since it's not a 60fps game to begin with. But it's also possible that the game isn't really locked at 20Hz and just runs at that since it takes that long to render - it would be interesting to see if the frame rate went up if you overclocked the emulated ARM.

I'm going to guess that nearby enemies appear on top of the protagonist due to a very crude polygon sorting. This would be vital if you expected decent performance. In general this kind of 3D rendering is very rudimentary, you can see that there is no lighting whatsoever.