#42623 - LOst? - Fri May 13, 2005 4:56 pm
As a frame counter man as I am, I want to ask you how you program games that are not for GBA; games that run on 3D hardware mostly.
How do you do acceleration and collision detection when there are no frame counter to read from? How do you do animations?
I guess everything is relative to the time, but I can't just drop the AND and FIXED POINT and just do a game based on floating point and square root. It's so hard to choose the right thing.
I guess the GBA and DS comes in ming when I ask these questions. We all use frame counters and it works, but is it professional to keep using frame counters when you leave GBA and starts programming for the Gamecube etc?
#42628 - poslundc - Fri May 13, 2005 5:45 pm
| LOst? wrote: |
| How do you do acceleration and collision detection when there are no frame counter to read from? How do you do animations? |
Almost all computers and consoles - including the GBA - have internal timers that can be used to gauge how much time has past. Most OSes have a "tick" function of some kind that approximates to 1/60th of a second; the GBA doesn't require one since its hardware refreshes at that frequency, and you can count ticks yourself with a VBlank interrupt.
| Quote: |
| I guess everything is relative to the time, but I can't just drop the AND and FIXED POINT and just do a game based on floating point and square root. It's so hard to choose the right thing. |
<shrug> Math coprocessors exist for a reason. It'd be pointless not to take advantage of any technological advances you've been given. I can do my own 64-bit multiplication routine on the GBA, but I'd be an idiot not to use the built-in 64-bit multiply instruction on the ARM7.
No offence, but this comes across a lot like whining from someone who learned to do something the hard way and is offended that it's been made so easy on more modern platforms. Well, it's the poor programmer that allows themselves to get locked in a single paradigm. If you use fixed-point on a machine that has an FPU you'll probably be wasting cycles that could be run in parallel while the FPU is working, and you'll be needlessly obfuscating your code for other programmers.
| Quote: |
| I guess the GBA and DS comes in ming when I ask these questions. We all use frame counters and it works, but is it professional to keep using frame counters when you leave GBA and starts programming for the Gamecube etc? |
Most games on most platforms operate by keeping track of "ticks". Many have variable frame rates and operate on different paradigms than cycling over every hardware refresh, but elapsed ticks are still most often the measurement of choice.
Dan.
#42708 - LOst? - Sat May 14, 2005 3:32 am
| Quote: |
<shrug> Math coprocessors exist for a reason. It'd be pointless not to take advantage of any technological advances you've been given. I can do my own 64-bit multiplication routine on the GBA, but I'd be an idiot not to use the built-in 64-bit multiply instruction on the ARM7.
No offence, but this comes across a lot like whining from someone who learned to do something the hard way and is offended that it's been made so easy on more modern platforms. Well, it's the poor programmer that allows themselves to get locked in a single paradigm. If you use fixed-point on a machine that has an FPU you'll probably be wasting cycles that could be run in parallel while the FPU is working, and you'll be needlessly obfuscating your code for other programmers. |
I went into that trap and I decided to do something about it. I spend nearly 4 months optimizing my code and got the same result, but instead got a lot of CPU time left for other resources.
| Quote: |
| Quote: | | I guess the GBA and DS comes in ming when I ask these questions. We all use frame counters and it works, but is it professional to keep using frame counters when you leave GBA and starts programming for the Gamecube etc? |
Most games on most platforms operate by keeping track of "ticks". Many have variable frame rates and operate on different paradigms than cycling over every hardware refresh, but elapsed ticks are still most often the measurement of choice.
Dan. |
So that means you aren't a bad programmer for using frame based operations when working with OpenGL or simular interfaces? Do you still wait for Vblank when working with OpenGL in Nintendo DS?
#42711 - sajiimori - Sat May 14, 2005 4:01 am
Lost, if you are arguing that developers should use fixed point on systems with FPUs, you're fighting a losing battle. Ever since the Pentium 1, developers have recognized that fixed point is a waste of energy and that it places unnecessary restrictions on game design, particularly in regard to the scale of the world.
#42712 - LOst? - Sat May 14, 2005 4:17 am
| sajiimori wrote: |
| Lost, if you are arguing that developers should use fixed point on systems with FPUs, you're fighting a losing battle. Ever since the Pentium 1, developers have recognized that fixed point is a waste of energy and that it places unnecessary restrictions on game design, particularly in regard to the scale of the world. |
floating point is okay. I just have problems with timers, and that doesn't require floating point really. The main problem for me is to find out a collision detection where speed and time is the distance rather than frames left to impact.
#42715 - DekuTree64 - Sat May 14, 2005 4:44 am
Time based movement is pretty much required on PC games because systems vary so much. On DS (and all console systems), it's sort of optional, depending on how much variation you have in your level complexity and such. If you know your game will always run at the same speed, you can use frame based movement no problem.
That said, I think most console games do use time based, so I would say it is a bit more professional.
Personally I'll fight for frame based just for simplicity. It's also a bit faster not having to multiply by time all over the place.
Time based isn't too much different though. Like for collision detection, just give it the vector you're trying to move along and see how far you can go before you hit something. If you're time based, multiply the vector by the time before checking it. No difference in the actual check.
Since 3D animations usually interpolate between keyframes anyway, it's natural to have a fixed/floating point frame number. 2D animations would just have to round to the nearest frame I guess.
_________________
___________
The best optimization is to do nothing at all.
Therefore a fully optimized program doesn't exist.
-Deku
#42717 - LOst? - Sat May 14, 2005 5:23 am
| DekuTree64 wrote: |
Time based movement is pretty much required on PC games because systems vary so much. On DS (and all console systems), it's sort of optional, depending on how much variation you have in your level complexity and such. If you know your game will always run at the same speed, you can use frame based movement no problem.
That said, I think most console games do use time based, so I would say it is a bit more professional.
Personally I'll fight for frame based just for simplicity. It's also a bit faster not having to multiply by time all over the place.
Time based isn't too much different though. Like for collision detection, just give it the vector you're trying to move along and see how far you can go before you hit something. If you're time based, multiply the vector by the time before checking it. No difference in the actual check.
Since 3D animations usually interpolate between keyframes anyway, it's natural to have a fixed/floating point frame number. 2D animations would just have to round to the nearest frame I guess. |
Thank you for your explainations! ^_^
#42720 - Suboptimal - Sat May 14, 2005 6:21 am
| DekuTree64 wrote: |
| Personally I'll fight for frame based just for simplicity. It's also a bit faster not having to multiply by time all over the place. |
Funny, I would fight for time based gameplay because I find it much more intuitive. I have a much easier time tuning things based on "seconds" rather than "frames". I'm probably biased, since those were the sorts of systems I started learning with. =)
Another thing to keep in mind is that if you're doing an OpenGL app or whater on a PC, the framerate will not be constant, even on the same system. As a consequence, sequences that take place based off of X ticks will happen in varying amounts of time. Hell, if you're working on a console game, you have to bear in mind that TVs in the US update at 60Hz, but in Europe they update at 50Hz.
Put simply, people are used to experiencing changes as a function of time, not as a function of vertical refresh rate. The two are only equivalient when vertical refresh rate is constant, which is only true for certain platforms / applications.
#43129 - Touchstone - Thu May 19, 2005 11:30 am
A friend of mine who's a real fighting game buff claim that the PAL version of .. uhm .. some fighting game for the PS2 runs slower than it's NTSC counterpart which would suggest that they use a frame based timer method. In any other kind of game it would probably be quite difficult to notice a difference in speed between NTSC and PAL if it use a frame timer.
If an animation, most noticable for pre-rendered movies, is made to play back at 60 Hz and it's just resampled to 50 Hz without any sort of interpolation it will look choppy so if it's not remastered to 50 Hz it's probably preferred to be propelled one tick per frame regardless of 50/60 Hz. Although sound have to be played back slower to match the slower animation.
_________________
You can't beat our meat
#43131 - keldon - Thu May 19, 2005 11:54 am
| Touchstone wrote: |
A friend of mine who's a real fighting game buff claim that the PAL version of .. uhm .. some fighting game for the PS2 runs slower than it's NTSC counterpart which would suggest that they use a frame based timer method. In any other kind of game it would probably be quite difficult to notice a difference in speed between NTSC and PAL if it use a frame timer.
If an animation, most noticable for pre-rendered movies, is made to play back at 60 Hz and it's just resampled to 50 Hz without any sort of interpolation it will look choppy so if it's not remastered to 50 Hz it's probably preferred to be propelled one tick per frame regardless of 50/60 Hz. Although sound have to be played back slower to match the slower animation. |
This is true for practically all PAL games. But the PS2, Gamecube, XBox and (some) DC games run in 60hz - although it's not manditory on the PS2 I think
#43161 - Suboptimal - Thu May 19, 2005 5:59 pm
I don't know how the various consoles handle matchmaking services between the US and European markets, but they would need to run their game updates at the same frequency for both PAL and NTSC, even if their rendering frequency was different. Seeing as how more and more console games need to offer online play to get published, I suspect that thinking of time in terms of ticks is a concept that will become increasingly obsolete.
Not that this matters much for a system like the gba. ;)
#43206 - FluBBa - Fri May 20, 2005 7:54 am
At least some of the online (xbox) games doesn't match if the games doesn't run on the same refresh rate.
_________________
I probably suck, my not is a programmer.
#43226 - tepples - Fri May 20, 2005 5:01 pm
A common technique used in multiplayer comms on the GBA and in LAN-based console emulators is to exchange which buttons are being pressed and released at what time. This is called "input device reflection", and it depends on running the games' physics at the same refresh rate. However, you can run, say, the physics at 100 Hz and the video at 50 Hz or 60 Hz or whatever. I remember that a lot of the PC games that I made (before the GBA came out) used to run the physics at 70 Hz or 100 Hz no matter what kind of frame rate the actual display got.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.