Sorry. Based on endo''s post, I assumed he was using Euler integration.

I should also mention the projects we''ve used the 60hz logic method on were PS2 games. But there isn''t any reason why this wouldn''t be a good base for a PC game''s main loop.

AP: But wait ... doesn''t your method only do slow-downs, not speed-ups, of gamelogic? I''m confused .. isn''t that a problem?

quote:

---

Original post by Zaphos

Endo:
As long as you can put this:

while(GetTime()>logicalTime){   DoLogic();   logicalTime+=intervalSize;}   

around your game logic, and logicalTime gets initialized to GetTime() at the beginning of your program, you should be fine.

I can''t find your game logic in the code you posted, but then I didn''t look very hard. You should be able to put that loop in by yourself, though

---

Maybe thats where I am confused, I was gonna put all the code to run the game in the idle function. Does that sound like a bad idea? I tried putting the code you suggested inside the idle function and produced some strange effects so I think the problem may actually be a combination of things. But I''m not sure what they might be exactly....

ok a quick update and a question. I am now using the class found in the reference section for this site. Has anyone else tried it? What did they think about it seeing as everyone has a differing opinion on the best way to accomplish this effect?

Where? Post a URL to it?

Sorry took me ages to find it again, but found some other interesting articles em route

http://www.gamedev.net/reference/list.asp?categoryid=25

You could have posted a link to the actual tutorial, you know

Anyway, that's a method which is very common, though not very good. It becomes progressively more inaccurate ... I'm pretty sure that's just straight out Euler Approximation. For a bunch of comments on that article, go to its thread ... and listen to "Sly" (scroll down) .... The thread is here

[edited by - Zaphos on May 20, 2002 10:21:07 AM]

Look at this too!

A good quote:

quote:

---

Steve: Fixed-timestep has many advantages over variable-timestep, the main ones being: completely deterministic results, improved efficiency (we tick the logic at 30Hz but usually render at 60Hz+, meaning we only do AI/physics/etc. every second frame or less) and much simpler game code (no "*deltaTime" in any of the game code). There are issues to resolve (input being a major one) but we have always found easy solutions and, in practice, there are no downsides to fixed-timesteps. I can list many downsides to variable-timestep systems.

Malkia: I think you might have missed the point. "Fixed-timestep" may be a bit of a misleading name, because we are not running the whole system at a fixed rate, just the game logic. The rendering is run at whatever rate the machine can render at, so we still get nice 120Hz rendering (on a nice fast card, of course). The game logic may be running at 30Hz, but interpolation makes it appear as if everything is running at 120Hz. This kind of system actually decouples you from the machine's speed, making it a really good choice for PC/console simultaneous development, which is what we are doing.

---

[edited by - Zaphos on May 20, 2002 10:27:28 AM]