#111459 - Diirewolf - Wed Dec 06, 2006 7:30 pm
Ok I understand how to use hardware timers with the GBA but how would I make use of this in my game? I am moving from DirectX Game Programming so usually we would have something called AbsoluteTime which from that we can do all the timing calculations and decide if for example if we have to switch to the next frame of animation depending on its delay. Is the approach the same with the GBA or completely different and how would you go about doing something like that?
Thanks
#111461 - kusma - Wed Dec 06, 2006 7:45 pm
in the gba-world you can usually count the vblanks to control animation speed.
#111464 - Diirewolf - Wed Dec 06, 2006 7:59 pm
how does that work? how many vblanks every second? and how would i use it?
#111465 - kusma - Wed Dec 06, 2006 8:11 pm
| Diirewolf wrote: |
| how does that work? how many vblanks every second? and how would i use it? |
59.59, and you just increment a counter in your vblank interrupt.
#111477 - poslundc - Wed Dec 06, 2006 10:34 pm
| kusma wrote: |
| 59.59, and you just increment a counter in your vblank interrupt. |
And most games consider that to be close enough to 60 for rock and roll.
Dan.
#111482 - Ant6n - Thu Dec 07, 2006 12:33 am
in my game i keep a double precision float that counts up 1/59.727500569605832763727500569606 every frame ;)
#111484 - gmiller - Thu Dec 07, 2006 12:47 am
But counting with a float on a machine that must simulate floating point hardware is slow and the code adds to the program size (all of the floating point simulation library) when you do not need any of it normally.
#111510 - tepples - Thu Dec 07, 2006 4:45 am
If you want to be accurate without floating point, you can pretend it's 657/11 = 59.727272... fps, which is probably within tolerances for the GBA crystal. The Bresenham algorithm for the clock divider is thus: Each frame, add 11 to a counter, and whenever it reaches 657, subtract 657 and add a second.
If you want to be really accurate without floating point, you can use what is thought to be the spec (262144/4389 fps): Each frame, add 4389 to a counter, and whenever it reaches 262144, subtract 262144 and add a second.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#111522 - Ant6n - Thu Dec 07, 2006 7:19 am
actually i dont count like that, just playing the precision joke further ;).
I do have a cycle accurate 64 bit timer though.
#111530 - keldon - Thu Dec 07, 2006 10:03 am
No matter what you do the frame rate for the GBA is constant, and no amount of accuracy is going to change that. How do you suppose floating point will increase the accuracy? Reason being is that you will always be synchronized with the GBA frames, and if you are at 0.8 and ready to draw it makes no difference!
#111550 - Diirewolf - Thu Dec 07, 2006 5:07 pm
i get the point now that it does 60 vblanks a second but how would i implement that into code and do something like animation with that???
thanks
#111553 - kusma - Thu Dec 07, 2006 5:14 pm
| Diirewolf wrote: |
i get the point now that it does 60 vblanks a second but how would i implement that into code and do something like animation with that???
thanks |
something like this:
| Code: |
#include <gba_interrupt.h>
volatile int blanks = 0;
void vblank()
{
blanks++;
}
int main()
{
irqSet(IRQ_VBLANK, vblank);
irqEnable(IRQ_VBLANK);
while (1)
{
VBlankIntrWait();
animate_stuff(blanks);
}
return 0;
}
|
now you'll get a stable 60hz timer in on your function animate_stuff(), ready for doing whatever you want.
#111568 - Miked0801 - Thu Dec 07, 2006 8:02 pm
Just an aside, the volatile keyword on the blanks var is a must - it prevents the compiler from optimizing code it shouldn't.