Trouble with Time and GLUT looping mechanisms
unknown Wrote:It's actually a better method to use a variable timestep than a fixed timestep in terms of stability and realism, although it doesn't come without a cost. It generally requires slightly more programming to get correct results, like intersecting moving objects instead of static objects. fixed time step is easier because its more predictable so you more likley will be able to get away with short cuts like I mentioned.
I know that a high quality engine like newton works like I suggest, so I am just trying to get into good habits before I move on to program somthing harder..
Sounds more complicated. You were showing a variable system, weren't you...
Ah, I think I'm beginning to see the difference...
It would require the same effort to code a good variable timestep system and a good fixed timestep system, using a fixed timestep gives you somthing you can take advantage of in your calculations and 'fudge' things to just work.
Whether you choose fixed or variable im sure everyone would agree that you would want to seperate all your graphics code (GPU) from your animation code (CPU).
Whether you choose fixed or variable im sure everyone would agree that you would want to seperate all your graphics code (GPU) from your animation code (CPU).
Sir, e^iπ + 1 = 0, hence God exists; reply!
unknown Wrote:It's actually a better method to use a variable timestep than a fixed timestep in terms of stability and realism, although it doesn't come without a cost. It generally requires slightly more programming to get correct results, like intersecting moving objects instead of static objects. fixed time step is easier because its more predictable so you more likley will be able to get away with short cuts like I mentioned.Ah, OK, I understand your viewpoint a bit better now. You can't actually get more stability from a variable interval system since a fixed interval system gives you identical results no matter what, but theoretically you could get as much stability with greater realism and speed. It just takes a lot more effort to get there, and debugging edge cases in a variable interval system is pretty difficult.
I know that a high quality engine like newton works like I suggest, so I am just trying to get into good habits before I move on to program somthing harder..
But yes, essentially, the only advantage of fixed interval is that it lets you get away with shortcuts. If you have the skillz to implement a solid variable interval system, that's definitely the way to go. I just don't like dealing with all the not-immediately-visible problems a variable interval system brings.
Jones: Can I get you on AIM or IRC or something? I'd be happy to help debug this with you, but it's pretty difficult over the forum. Alternatively, if you could send me the project over e-mail, that would work too.
I have to say, my impression is that variable-interval is *way* more trouble than it's worth. Yes, if you want super-realism, with small objects moving fast or something like that, then you'll need to do it. For most games, though, you won't need anything nearly as complex.
Even then, there's a difference between "variable rate" in terms of "run one physics step each frame, passing the elapsed time" (which doesn't work, see alex's tutorial) and "run as many physics steps as you need to to get things accurate" (which is what something like newton will do)
Even then, there's a difference between "variable rate" in terms of "run one physics step each frame, passing the elapsed time" (which doesn't work, see alex's tutorial) and "run as many physics steps as you need to to get things accurate" (which is what something like newton will do)
ThemsAllTook Wrote:Jones: Can I get you on AIM or IRC or something? I'd be happy to help debug this with you, but it's pretty difficult over the forum. Alternatively, if you could send me the project over e-mail, that would work too.
Thanks for the offer, I'd love (and need) the extra help.
I'll just add you to my contacts...
*done*

In case you're wondering who the crazy person rambling to you about programming problems is, it's me Gareth.

And in the meantime, I'll try implementing your system in a SDL context. Hopefully the less strict looping system will make it easier, and maybe even work, but knowing my code it's not good to be hopeful.
(moving to SDL is a very good idea, although SDL is absolutly awful its way way better than glut)
Sir, e^iπ + 1 = 0, hence God exists; reply!
Hey Jones.
I've got a really simple GLUT application class that I made with a update(float deltaTima) function.
If you're intererested I can e-mail it to you. (I can't say that it's brillian code, but I illustrates the concept pretty well)
I've got a really simple GLUT application class that I made with a update(float deltaTima) function.
If you're intererested I can e-mail it to you. (I can't say that it's brillian code, but I illustrates the concept pretty well)
By the way unknown, why do you think SDL is awful?
Possibly Related Threads...
| Thread: | Author | Replies: | Views: | Last Post | |
| Trouble writing a GLUT-like API | TomorrowPlusX | 2 | 2,222 |
Jun 2, 2009 03:47 AM Last Post: TomorrowPlusX |
|
| Looping Sound in Cocoa | RigelPrime | 11 | 4,722 |
Jan 7, 2003 04:02 AM Last Post: OneSadCookie |
|

