I was looking for game/graphics timing code to use in my gfx library and came across these articles:
http://www.mvps.org/directx/indexes/index.htm
I've already tried the "game timing" code and it works real nice, once you get used to the new method of moving gfx objects around. This is a much better approach than using vsyncing. No matter how many objects, or how fast your screen refresh rate is, everything will still go at the same basic speed you've choosen for your object(s). I'm also certain these timing routines could be used for other things besides gfx objects (sprites).

Just thought I would share the info.

I do believe this technique is called "Framerate." I've noticed that many things appear to have something like this built in. For example, on my computer, OpenGL apps go at the same speed all the time. Though, on some machines, they like to fly off on their own. My guess is that it depends on your card. I'm also guessing that it's possible that this code you're using is also card dependent (without looking at it). I'd strongly suggest beta testing games alot when using tricky stuff like this. Are you planning on making a game of your own?

Anyway, thanks for the info. It will surely assist us.

If you ran this program using systems that have a default refresh rate of 60hz then you'll notice no speed problems, but if the refresh rate is 120hz, then everything will go at least twice as fast as the 60hz systems.


It isn't, It can be used on the original 'pentium I' on up to the lastest quad core PIV's. There are a number of benefits:
1. smooth physics control of objects
2. will run at a constant speed no matter what the refresh rate is.
3. you can draw as fast as the GPU hardware can draw, no waiting in between vsync signals
4. These are the same timing routines used in 3d games

Take a look at the code and see for yourself, its very simple but very effective.


I might, there is an old dos game called "leisure suit larry" that I might remake. I don't know yet. I already have a good 2d library that I've written in assembler. Thanks to the timing routines above, All I'll have to do now is find the artist in me(could be a long search! ) and begin making the gfx for the game.

Well, time, graphics, and music are the things holding me from making a nice FPS using fasm. I have a theory that'll really simplify collision detection.

@kohlrak: if you mean BSP, then its already taken. If you mean "neighbours' caching" then its also taken.

I realized that my 'new' ideas were stolen 10 years ago

...BUT if you mean "thinking ahead in time" then the idea is still in my head in development and you can take it