Timer relates you the system clock, it's not OS/system specific. I.e. 1000 millisecnods ='s 1 second on any platform.
Sync will only hold your frame rate bellow, or to a particular level. So it's only useful for holding the rate down on faster systems. The moment a frame runs long, the player will feel the frame rate drop. Your movement/animation etc will suffer
In DB/DBpro there's two solutions that come to mind. Both have pro's and cons
1) Scale movements/rotations based upon the frame rate/ length of frame (tie to render/update the frame..)
* Pros
- Fairly simple to implement.
- Will keep the appearance of a solid fps on machines capable of it.
- Allows you to run at Sync 0
* Cons
- All animation/movements/patterns etc must be time based to remind true. A good example of a common issue is when you need to an object to flow a path/pattern. You'd have to step through your path, updating any turns/junction points relevant, to the passed time period..
- Collision - You CAN'T USE REGION BASED COLLISION.. Making it virtually useless in DB/DBPRO. If you've noticed while playing some demo that you fall through floor, or walk through walls etc etc, it prolly attempts to approximate FPS in this fashion. So then You've seen this classic issue first hand. The problem occurs when either the machine can't hold the FPS at the games required clock, or simply drops when a frame runs too long. So what happens is when the game calculates the objects next position, it never takes into account that this movement may have stepped the object passed/through another object(s). Normally this happens with Small fast moving objects or, Thin ones like walls.. So the key point is, if you want it to be solid on slower machine, check for intersects... Normally if the game updates based on the timer, all collisions are ray based..
2) Manage the updates in passes. Pass 1 updates game logic (only) and then pass 2 renders the scene. When a frame runs long, you calc how many potentials frames have passed, then update the game logic accordingly (ie. if 2 frames have passed, you update the logic twice then render)
* Pro's
- Allows for regional collisions
- Gives a solid frame rate. So you actually get X frames (give you take) per second.
- Allows you to run at a Sync rate of 0
* Cons
- requires a specific design towards it's implementation
- May requires you manual calculate collision/ or values that only returnable after a render..
There's a third hybrid idea. Where you can update certain objects/effects using the timer (#1) (stuff without collision) and then manage your 'hard' objects through concept #2
Kevin Picone
Play Basic - Visible Worlds - Kyruss II
[url]www.underwaredesign.com[/url]
