Can someone please point me to a good explaintation\tutorial on delta timing.
Thanks,
Jason.
Thanks,
Jason.
Delta Timing
Miscellaneous Forums/General Discussion/Delta Timing I have a great function the calculates the Delta time between forum posts regarding "Delta Time".
http://www.google.co.uk/search?q=deltatime+site%3Ablitzbasic.com&start=0&ie=utf-8&oe=utf-8
http://blitzbasic.com/Community/posts.php?topic=49306
http://www.google.co.uk/search?q=deltatime+site%3Ablitzbasic.com&start=0&ie=utf-8&oe=utf-8
http://blitzbasic.com/Community/posts.php?topic=49306
Hey, I did a google search (different keywords though I must admit) and it didn`t bring much up. Thanks for the link though :)
Just out of interest is the example in Krylars book about locking on in realtime the same general delta time technique?
Jason.
Just out of interest is the example in Krylars book about locking on in realtime the same general delta time technique?
Jason.
I think there isn't much to say about delta timing, because it's pretty simple. Of course, you can modify the concept however you like.
It's the burden of us PC games programmers, we have to deal with individual machines. If we would develop for consoles, there wouldn't be a need for delta etc. making things simpler.
I think there are two things you should consider: make sure to use the calculated Delta-T for the current frame, not for the next frame.
If your game is using vsync and the speed on a machine is near 60, 30 or 20 Hz then you're in trouble because Delta-T will continously jump eg. between 30 and 60 Hz, resulting in jittery delta-T correction. In this case it may be clever to reduce the rate to the next dividable rate, eg. to 30 Hz for some time, until the rate would be fast enough for stabile 60 Hz again.
It's the burden of us PC games programmers, we have to deal with individual machines. If we would develop for consoles, there wouldn't be a need for delta etc. making things simpler.
I think there are two things you should consider: make sure to use the calculated Delta-T for the current frame, not for the next frame.
If your game is using vsync and the speed on a machine is near 60, 30 or 20 Hz then you're in trouble because Delta-T will continously jump eg. between 30 and 60 Hz, resulting in jittery delta-T correction. In this case it may be clever to reduce the rate to the next dividable rate, eg. to 30 Hz for some time, until the rate would be fast enough for stabile 60 Hz again.
Some minor technical innacuracies (based upon DBPisms) but overall explains the concept quite well: http://www.bansheestudios.com/stuff/timerBasedMovement.html
To take this tutorial further you could try capping the delta to match the refresh rate of the current screen resolution with a while delay wend loop.
This is a false ideal, people often hark back to the "golden era of programming" on the 16 bits and site a standardised platform as the key issue which made it great, I hate 8 Amigas - and not one of them ran at the same speed as another. Even on todays consoles you can get upgrades - perhaps not of speed particularly - but certainly of optional hardware to support.
To take this tutorial further you could try capping the delta to match the refresh rate of the current screen resolution with a while delay wend loop.
If we would develop for consoles, there wouldn't be a need for delta etc. making things simpler.
This is a false ideal, people often hark back to the "golden era of programming" on the 16 bits and site a standardised platform as the key issue which made it great, I hate 8 Amigas - and not one of them ran at the same speed as another. Even on todays consoles you can get upgrades - perhaps not of speed particularly - but certainly of optional hardware to support.
I take care of jitter by averaging the calculated delta time with the last several frames.
"I hate 8 Amigas"
Surely not possible, I personally would still rather use a miggy than a peecee anyday.
My pc crashed today for absolutely no reason at all, again. Never had this trouble with my Amiga.
Jason.
Surely not possible, I personally would still rather use a miggy than a peecee anyday.
My pc crashed today for absolutely no reason at all, again. Never had this trouble with my Amiga.
Jason.
Banshee meant "had" not hate. I queried that they didn't run at the same speed (or at least most of them) because lets face it 90% of Amiga users had a 500 or 600 and then later a 1200 (which was twice the speed). It jsut happens she had some weird Amiga upgrades. Although some of them had slightly different versions of chipsets, those alone didn't make a significant difference to speed, only plain CPU power did. Yes if you used different types of RAM expansions and your game made use of ectra RAM you might get different speeds, but most games were for "standard" Amigas. If your game was for a 500, it would have been fine on all other 500s if timed to vertical refresh. I think Banshee was a rare case (having 8 amigas pretty much proves this statement also ;-))
Oh, I thought it was hate, as in mobile texting, sorry misread it completely ;)
Jason.
Jason.
I meant have, sorry :)
Not strictly true, infact a long way from it. The presence of a memory upgrade made a huge difference to an Amiga's performance, it added nearly 50% again to the raw speed. In modern PC terms this was because the computer, as standard, used the graphics cards memory as RAM until you put extra RAM in which was on a seperate bus, thus enabling concurrent read/write activity to each bus and dramatically increasing system performance. Memory upgrades where extremely common but not universal.
With 3 base Amiga chipsets on the home user machines A500 / A500+ or A600 / A1200 all yielding different performance and graphics capabilities the addition of RAM expansions, or as they where then called FastRAM, made for 6 basic configs.
Add to this that most RAM expansion cards in later years also included an FPU (floating point unit for faster float calculations) of varying clock speeds and specification (68881 and 688882 chips if memory serves) and what you've got is a completely non-standard base.
The Amiga is perhaps an extreme example as it was around for a very long time, but the same diversification of hardware effects modern console platforms - the only differences being they are not around long enough to achieve wider diversification and to some extent "upgraded" consoles are sold as new systems: PS; PS2; PS2 Slim; PSP; PS3 etc etc etc.
Taking Playstation as an example, whilst there are no expansions which directly effect speed at this time for that particular platform (other than getting an "upgraded edition", there is still a wide diversity of hardware to support such as varied controller configurations, different memory card sizes, buzz controllers, wheels, rumble packs, 4 way adapters (A favored oversight of AAA games) and nowadays broadband speeds added to the mix too.
I just do not believe there has ever been such a thing as standardised hardware since the 8bit era washed away the Binatones and Atari's.
If your game was for a 500, it would have been fine on all other 500s if timed to vertical refresh.
Not strictly true, infact a long way from it. The presence of a memory upgrade made a huge difference to an Amiga's performance, it added nearly 50% again to the raw speed. In modern PC terms this was because the computer, as standard, used the graphics cards memory as RAM until you put extra RAM in which was on a seperate bus, thus enabling concurrent read/write activity to each bus and dramatically increasing system performance. Memory upgrades where extremely common but not universal.
With 3 base Amiga chipsets on the home user machines A500 / A500+ or A600 / A1200 all yielding different performance and graphics capabilities the addition of RAM expansions, or as they where then called FastRAM, made for 6 basic configs.
Add to this that most RAM expansion cards in later years also included an FPU (floating point unit for faster float calculations) of varying clock speeds and specification (68881 and 688882 chips if memory serves) and what you've got is a completely non-standard base.
The Amiga is perhaps an extreme example as it was around for a very long time, but the same diversification of hardware effects modern console platforms - the only differences being they are not around long enough to achieve wider diversification and to some extent "upgraded" consoles are sold as new systems: PS; PS2; PS2 Slim; PSP; PS3 etc etc etc.
Taking Playstation as an example, whilst there are no expansions which directly effect speed at this time for that particular platform (other than getting an "upgraded edition", there is still a wide diversity of hardware to support such as varied controller configurations, different memory card sizes, buzz controllers, wheels, rumble packs, 4 way adapters (A favored oversight of AAA games) and nowadays broadband speeds added to the mix too.
I just do not believe there has ever been such a thing as standardised hardware since the 8bit era washed away the Binatones and Atari's.
OK I gotta disagree here, If you make your game run in 0.5Mb on an A500, it will work the same speed on all A500 because it won't make use of the Fast RAM and it won't make use of any FPU unless you code it to, that's what I was talking about. Also the chipsets on the A500/A500+/A600 really didn't speed any games up that were written for the lowest common denominator, i.e. the A500. Besides if timed to vertical refresh, it was EXACTLY the same on all 3. Perhaps if you made a game for an A600 that used 99.9% of the time available between v-refresh, and then ran it on an original A500 it might take 100.1% and thus drop the odd frame but I doubt it. It was totally possible to make a game run the same speed on all Amigas. Of course it was possible to make some games that ran faster depending on the chipsets/RAM/FPUs etc like those crappy 3D Doom clones that came out at the end. I only say crappy as you never had a hope in hell of getting them to play smootly on anything less than a beefed up A4000 or similar.
The presence of a memory upgrade made a huge difference to an Amiga's performance, it added nearly 50% again to the raw speed
I had a memory upgrade and guess what, all my games ran at the same speed i.e. 50Hz. Also when I got an A1200 and got the A500 games working through various ROM Disks, they ran at the same speed too. Internally the hardware may have competed it's operations quicker but as it was timed to vwait, this was irrelevant. That's the whole point I was making. Programming a "slow-down" timing code is the cheap mans alternative to delta timing, it does not meen the hardware was performing the same.
Simply because a lot of programmers failed to write programs to make use of extra hardware (and all too frequently non top-rated commercial games failed to run at 25fps lets not forget) doesnt meen that hardware was unified, it meens only that programmers where lazy or shortsighted.
Your games ran at the same speed because the programmer put in a speed limit. Not because the hardware was equal.
In terms of the 99.9% / 100.1% remember that NTSC market Amigas ran faster than PAL Amiga's which rendered an extra 56? scanlines at lo-res... I forgot this earlier, so that's 12 base spec Amigas.
Simply because a lot of programmers failed to write programs to make use of extra hardware (and all too frequently non top-rated commercial games failed to run at 25fps lets not forget) doesnt meen that hardware was unified, it meens only that programmers where lazy or shortsighted.
Your games ran at the same speed because the programmer put in a speed limit. Not because the hardware was equal.
In terms of the 99.9% / 100.1% remember that NTSC market Amigas ran faster than PAL Amiga's which rendered an extra 56? scanlines at lo-res... I forgot this earlier, so that's 12 base spec Amigas.
Simply because a lot of programmers failed to write programs to make use of extra hardware (and all too frequently non top-rated commercial games failed to run at 25fps lets not forget) doesnt meen that hardware was unified, it meens only that programmers where lazy or shortsighted.
It means nothing of the sort - in fact it means the opposite, as we've gone over before. Programmers put effort into making the most popular model (A500 with 1/2 meg expansion) fly, spending their time getting the snazziest effects by hitting the metal, because that's the way you survive in a competitive market. It's not lazy to expend the majority of your energy where it will reap the greatest rewards. (Unlike Commodore who, knowing that games programmers had been hitting the metal on their games oriented computer, went right ahead and released incompatible revisions anyway.)
The 1/2 Meg expansion sure made a difference to speed though - I remember Lemmings didn't slow down when things got busy once I'd upgraded my machine (technically I suppose that's a case of the machine slowing down less rather than speeding up, but as far as the user is concerned the computer is "faster" as a result).
Global delta#
Global render_time
Global FPS#=30
Global TimePerFrame#= (1000.0 / FPS#)
;multiply all time based variables by delta#
;such as speed .... speed = distance * time
Function CalcTimer()
ms_passed#=MilliSecs()-render_time
render_time=MilliSecs()
delta#=(delta#*4.0 + Float(ms_passed#/ TimePerFrame#))/5.0
If delta# >2 Then delta#=2
End Function
Global render_time
Global FPS#=30
Global TimePerFrame#= (1000.0 / FPS#)
;multiply all time based variables by delta#
;such as speed .... speed = distance * time
Function CalcTimer()
ms_passed#=MilliSecs()-render_time
render_time=MilliSecs()
delta#=(delta#*4.0 + Float(ms_passed#/ TimePerFrame#))/5.0
If delta# >2 Then delta#=2
End Function