#58371 - Nacho - Sat Oct 22, 2005 11:31 pm
Hello there! I used to program in the Windows platform using DirectDraw before getting into GBA programming. Anyway, the path I always take for animation is to get the time elapsed since the last frame (using getTickCount) and made the game?s logic frame-independent. But, since the GBA has a fixed frame rate of 60 Hz, I?d like to know what?s the common approach used for animation: do you use timers? or do you base all your game logic on the fact that the screen is refreshed 60 times per second? Thanks for your input!
--Nacho
#58374 - tepples - Sat Oct 22, 2005 11:52 pm
| Nacho wrote: |
| But, since the GBA has a fixed frame rate of 60 Hz, I?d like to know what?s the common approach used for animation: do you use timers? or do you base all your game logic on the fact that the screen is refreshed 60 times per second? |
The latter.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#58383 - Nacho - Sun Oct 23, 2005 2:09 am
| tepples wrote: |
| The latter. |
Ok. One more question: Is it a valid approach (by valid I mean that it has been used before with a positive outcome) to set the framerate to 30 or 40 fps? I?m asking because I?m pretty sure I won?t be able to mantain 60 fps in my 3D raster whenever I start pushing a few more polys.
--Nacho
#58385 - tepples - Sun Oct 23, 2005 2:14 am
Yes, there are many 3D games that run at 30, 20, or even 15 fps. Expectations for 3D rendering on the GBA aren't very high in general.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#58389 - Nacho - Sun Oct 23, 2005 2:57 am
Thanks! Do you suggest using the snippet you posted in the VBlank thread or should I look into hardware interruptions? (In case somebody else reads this thread some day, here?s the VBlank thread I?m talking about). Thanks again for all your help tepples!
--Nacho
#58608 - Mucca - Mon Oct 24, 2005 9:45 pm
My tip is to go with timers. The frametime will become the basis of your engine - calculate it once per game loop, and pass it to your logic and graphic updates. Timers are much more professional. They avoid ugly problems like slowdown and thus give you free hand to write game as design requires without being shackled by having to stick to a constant framerate. I think I would pack things in very quickly if I was writing some ai and was told I only had x-cycles maximum per frame to adhere to 20 fps so the animation runs correctly.
The only major thing to watch out for with timers is fat frames, for instance where initialisation takes place, passing a huge frametime into the next update. Sometimes timers are a bit finnicky, and it can take a lot of tuning to get accurate results, but only in rare cases, and its always very easy to count frames for those scenarios.
#58616 - tepples - Mon Oct 24, 2005 10:07 pm
Problem with putting game logic in a timer handler is that now you have to deal with nested interrupts.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#58620 - DekuTree64 - Mon Oct 24, 2005 10:35 pm
| tepples wrote: |
| Problem with putting game logic in a timer handler is that now you have to deal with nested interrupts. |
I think he was referring to time-based rather than tick-based logic...
Personally I prefer to use tick-based if I can get away with it. It's a little more intuitive to me, and gives less trouble with numeric accuracy when you have a consistent timestep.
I also prefer it from a gameplay perspective, just slowing down if there's too much action, rather than the game getting stuck for a second and then jumping ahead suddenly.
Both of those could be solved in time-based updating though; the accuracy by always having the time be a multiple of full frames, and the jumping by capping the maximum time step at maybe 4 frames.
You also have to have a consistent timestep across all machines if you want to do multiplayer, although that could be done in time-based by having all machines report their timestep and using the largest one.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#58992 - Nacho - Thu Oct 27, 2005 10:06 pm
Sorry for taking so long to reply. Thanks for all your input! After reading your suggestions I think I?ll go for the time-based approach by using timers. As a side question, what?s the difference between the tick-based approach and the time-based one?
--Nacho
#58999 - SevenString - Thu Oct 27, 2005 11:16 pm
one is tick based and the other is time based. :D
Seriously, if you're looking for the fundemental difference, a single "tick" typically measures a single frame of your game, where that frame is usually synced with the v-blank interrupt.
So, at 60fps, a tick is 1/60 of a second unless you have a slowdown.
As stated by previous posters, this method is probably the best if you are always or almost always running at a set maximum framerate.
In contrast, a timer based system is not framerate dependent because you are able to sample the timer arbitrarily when the previous frame is "done". Did it take 1/60 second, 1/10 of a second, or something in between? For all intents and purposes, if you have implemented your physics and collision properly, it doesn't matter. The time delta (difference) between your previous sample and the current sample determines how much you should increment your game objects' states.
Is that what you were looking for?
_________________
"Artificial Intelligence is no match for natural stupidity."
#59027 - tepples - Fri Oct 28, 2005 3:50 am
| SevenString wrote: |
| In contrast, a timer based system is not framerate dependent because you are able to sample the timer arbitrarily when the previous frame is "done". Did it take 1/60 second, 1/10 of a second, or something in between? For all intents and purposes, if you have implemented your physics and collision properly, it doesn't matter. |
Game physics is usually one big second-order numerical integration problem, and at least in 2D games it's usually handled with Euler integration (acceleration = some function of game state; velocity += acceleration/Δt; displacement += velocity/Δt). Trouble is that numerical integration of a system at different values of Δt will produce different results, causing different machines running a simulation at different speeds to fall out of sync.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#59039 - Nacho - Fri Oct 28, 2005 10:42 am
| SevenString wrote: |
| Is that what you were looking for? |
Yes :) Tick-based is what I referred to as frame-based. I thought they meant different things so that?s why I asked.
| tepples wrote: |
| Trouble is that numerical integration of a system at different values of Δt will produce different results, causing different machines running a simulation at different speeds to fall out of sync. |
But in GBA this won?t be an issue since the simulation is running at the same speed in every machine, right?
--Nacho
#59046 - keldon - Fri Oct 28, 2005 11:53 am
| Quote: |
| But in GBA this won?t be an issue since the simulation is running at the same speed in every machine, right? |
so long as you can ensure that your processing will take place within the given time frame and that they will keep in sync. You have to bear in mind that although the machines are running at the same speeds - they are running in their own time so they will be encountering VBlank and other interrupts at seperate times. depending on the TT of your calculatoins one machine could do all game physics
You will have to have your two machines synchronize their timings at first whilst also ensuring that any other activity will not bring them out of sync such as VBL interrupts and anything else your audio system is doing
I would personally use the time it took to perform the last calculation to predict the next. It does not need to be correct - just the same amongst the sytems. For example:
- it took 2 time frames to calculate the world, so i predict the next one will take that long
- the next frame actually takes 1 timeframe, but i don't care because both machines had a time quotient of 1, and i will predict that the next timeframe will be 1
Your machines will then communicate that fact with each other and both use the highest of the machines.
This allows the two machines processing to come out of sync whilst still maintaining synchronisation
#59065 - SevenString - Fri Oct 28, 2005 5:01 pm
| Quote: |
| Trouble is that numerical integration of a system at different values of Δt will produce different results, causing different machines running a simulation at different speeds to fall out of sync. |
That's why I added the caveat "For all intents and purposes..."
However, it probably should have read, "For MOST intents and purposes..."
I always do my physics/collision sims using an adaptive algorithm that splits each macro time-slice into discreet events for progressive simulation. So as long as the frame time-difference between two different instances of the sim aren't too aggregious, the results will be "close enough for rock and roll".
_________________
"Artificial Intelligence is no match for natural stupidity."
#59087 - tepples - Fri Oct 28, 2005 10:25 pm
| SevenString wrote: |
| I always do my physics/collision sims using an adaptive algorithm that splits each macro time-slice into discreet events for progressive simulation. So as long as the frame time-difference between two different instances of the sim aren't too aggregious, the results will be "close enough for rock and roll". |
Even in multiplayer where one player controls Megaman and the other controls Roll? Now you need to get into numerical analysis if you want to make any guarantees. Or are you using a "universe reflection" net protocol, which needs more bandwidth?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#59091 - SevenString - Fri Oct 28, 2005 11:03 pm
Multi-player is a different bag altogether. To use a very high-level description, in multi-player, I implement a client/server architecture with the assigned server maintaining final responsibility for gameplay events, including physics and collision resolution.
Sometimes, I'll even do the same thing for single-player implementations so that message queueing and events are handled in a way that can be adapted to multi-player at a later time.
Of course it's a lot more to it than that... heh heh
_________________
"Artificial Intelligence is no match for natural stupidity."
#59372 - Nacho - Tue Nov 01, 2005 12:27 am
Thanks again for all the replies! I?m not planning to add multiplayer capabilities to my game but thanks nonetheless for the info.
--Nacho