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.

Beginners > Most effecient use of VisualBoy Advance and gcc

#17833 - Shadow - Mon Mar 15, 2004 5:34 pm

Hi,

I've been wondering about efficiency lately, and there are things I am unsure of concerning VisualBoy Advance and gcc.


(1) VisualBoy Advance
This is the emulator I use. I also have Boycott Advance, but I found VBA to be the most accurate. However, because it has so many options, I'm not quite sure which will make it run programs exactly as on the GBA. Usually, I have the VSync option set, along with the DirectDraw render method, and this seems to work perfectly for small demo programs. For instance, I had a simple program that moved around a box sprite on the screen, using a WaitForVSync() function, and it worked fine. If I unchecked the VSync option on VBA, or if I removed the call to the WaitForVSync() function, the animation wouldn't be as smooth, and there would be a "tearing" effect.
Now to see how accurate VBA really is, I downloaded the ROM of Megaman Zero, which is a game I own, and tested it on my computer (an Intel Celeron 1.2GHz with 128MB RAM, running Windows XP). Even on the GBA, the game sometimes slows down, and I would assume it pushes the hardware quite a bit, so I thought it was a good game to test. On VBA, the game runs almost like the original, except a lot slower, when the VSync option is enabled. On the other hand, with the option disabled, the game runs at a much better speed, but there are slight glitches in the animation (which isn't the case in the original); this made me wonder if the code of the game even synchronizes with VBlank in the first place... So how do you get the emulator to work fine for every piece of code you run on it? Do you have to switch settings for each program? And the question that's been on my mind for a while : could someone explain to me what the VSync option of VBA actually does?


(2) gcc
I tried to understand gcc's options but I'm not too sure about a few things. First, is it a good idea to use the optimize option (-O)? I've heard that using -O3 could cause some trouble, sometimes not translating code properly, but I've found that -O2 does optimize the speed in general... so I would like to know the truth about this. Also, is it best to compile in Thumb or ARM mode? I've found contradictory information about the subject so I thought it was best to ask. I understand the basic difference between the two, but at what point (or under what circumstances) does one become more efficient than the other? Also, I would like to know what other options are used in general for maximum efficiency.


Well I know that's a lot of questions, but I need to understand how the basic tools work before I get too involved. That way, if I ever see that a piece of code is running too slow, I will know that the problem is in the code, not in the compiler or the emulator.


Thanks for your patience.

#17836 - poslundc - Mon Mar 15, 2004 5:57 pm

Shadow wrote:
And the question that's been on my mind for a while : could someone explain to me what the VSync option of VBA actually does?


Without knowing too much about VBA, my guess would be that the VSync option synchronizes the GBA's refresh rate to your monitor's refresh rate.

Quote:
I tried to understand gcc's options but I'm not too sure about a few things. First, is it a good idea to use the optimize option (-O)? I've heard that using -O3 could cause some trouble, sometimes not translating code properly, but I've found that -O2 does optimize the speed in general... so I would like to know the truth about this.


I find that it's okay to turn optimizations on if you are aware of what their side effects are when you write your code. The most significant problem with -O3 is that it will optimize out any code that it thinks doesn't actually "do" anything. For the programmer this means understanding when to use the volatile keyword, so if you are uncertain of this then stick with -O2.

Quote:
Also, is it best to compile in Thumb or ARM mode? I've found contradictory information about the subject so I thought it was best to ask. I understand the basic difference between the two, but at what point (or under what circumstances) does one become more efficient than the other?


95% of your code should be compiled as Thumb and run from ROM (or EWRAM if it's a multiboot game).

Time-critical code should be compiled as ARM and run from IWRAM.

Thumb instruction set: less powerful, but instructions are only 16 bits, which means they load quicker from the ROM than ARM instructions do.

ARM instruction set: much more powerful, but instructions are 32 bits, which takes longer to load from ROM (but will load at the same speed as 16-bit Thumb instructions from IWRAM).

You've only got 32K of IWRAM, so you need to be frugal with it. ROM, on the other hand, can be up to 32MB so you can store as much code as you could ever possibly want in it, and then some.

Dan.

#17844 - tepples - Mon Mar 15, 2004 9:27 pm

poslundc wrote:
my guess would be that the VSync option synchronizes the GBA's refresh rate to your monitor's refresh rate.

Correct, So for smooth animation, don't use Vsync unless either a) you have an LCD running at 60 Hz, b) you have a CRT running at 120 Hz, or c) you can tolerate the flicker from dropping your CRT down to 60 Hz.

Quote:
You've only got 32K of IWRAM, so you need to be frugal with it. ROM, on the other hand, can be up to 32MB so you can store as much code as you could ever possibly want in it, and then some.

Except that the more ROM you use, the more the cartridge costs to replicate once you find a publisher. Make sure to make room in ROM for decompression code and in EWRAM for decompressed asset data; making a blind decision to store assets uncompressed in ROM doesn't cut it anymore.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#17847 - Shadow - Mon Mar 15, 2004 10:12 pm

tepples wrote:
Correct, So for smooth animation, don't use Vsync unless either a) you have an LCD running at 60 Hz, b) you have a CRT running at 120 Hz, or c) you can tolerate the flicker from dropping your CRT down to 60 Hz.


That's interesting... I have an LCD, but I don't know its refresh rate. However, since the VSync option produces flicker free animation, I would assume it is 60Hz. And, if the 'VSync' option truly synchronizes the GBA's refresh rate to the monitor's, then what is the 'synchronize' option used for?

Anyhow, thanks for your answers.

#17848 - Gopher - Mon Mar 15, 2004 10:30 pm

the Synchroize option (Options->Emulator->Synchronize) runs clamps the emulator to true GBA speed. Without it, the emulator will run as fast as the system can manage. This will likely produce >60fps in your output. VSynch causes it to refresh the computer's screen synchronously, which (unless I'm mistaken) means if the emulator is running faster than your VSynch frames are skipped.
_________________
"Only two things are infinite: the universe, and human stupidity. The first is debatable." -Albert Einstein