precise timing

im trying to use the following to have precise timing in a graphical program:

Code:

---


word *my_clock=(word *)0x0000046C;

---

this points to an internal clock which runs at 18.2hz.

this is how i want to use it:

Code:

---


long start=*my_clock;

***action***

while ( (*my_clock-start) < .5 );

---

the idea is to stop the program until 0.5 cycles or rather 0.027 seconds have elapsed, then continue (useful for frame limiting in graphical programs).

the problem is, because the pointer the clock is an int pointer, .5 means 1. i have tried typecasting in many ways, to make it a double or float, but i just cant get any precision. that means i can only support delays of 0.055 seconds or more (believe me, its not enough)

please post a reply if you have an idea or know another way of creating fine precision delays.

if the clock runs at 18.2hz, how do you expect to get timing more precise than (1/18.2) seconds? (which is .055).

there are other ways to time of course, but using that one, that's the most precision you're getting.

For _precise_ timing you need to use an interrupt and a callback with a flag. That's how it's done for most games. Also, game timing isn't that precise-- it's just about speed.

You only need a clock in a game to regulate heartbeat for network activity, or to make sure the code doesn't execute too fast on a faster machine. Other than that, timing doesn't have to be much more than about 1/6th of a second (a 'tick') in most cases.

the thing is, at the moment im working with really basic and fast operations, so that i can tell whats going on easier (im not all that great with theoretical programming :). i just have a small routine which draws a line across the screen, pixel by pixel, and i want to be able to precisely regulate the speed at which it is drawn. using the 18.2hz system clock means that, for example, either i specify no delay, and it is drawn instantly, or I specify the smallest possible delay, and it is drawn too slowly for my liking.

sayeh, if you could direct me to some info about your interrupt method of timing, that would be good.

salem, i am using borland turbo c 2.01 under Windows 98.

cheers for any advice

Is your maximum resolution 18.2hz? (18.2 times per second)... That means you can only draw 18 pixels per second... at best.

Too Slow. You need to chop a second up into 1000 slices or more. Instead, use the OS Task Scheduler. That's how you make a real clock. It has millisecond accuracy. Which is way more than you need, but it is accurate enough for all your intents and purposes.

Based on the needs you've described, interrupt-priority issues which might cause a delay in the system calling your routine, won't be discussed here. It is unlikely you will experience that problem.

Here's a good link:

http://www.wideman-one.com/gw/tech/d.../wintiming.htm

Use the timeSetEvent method, don't put threads to sleep.

Quote:

---

Originally posted by Sayeh
For _precise_ timing you need to use an interrupt and a callback with a flag. That's how it's done for most games. Also, game timing isn't that precise-- it's just about speed.

You only need a clock in a game to regulate heartbeat for network activity, or to make sure the code doesn't execute too fast on a faster machine. Other than that, timing doesn't have to be much more than about 1/6th of a second (a 'tick') in most cases.

---

Actually, that's incorrect. When a game is going 100 fps (which happens even for games that are a year old on today's fastest machines), each frame is a time frame of 1/100th of a second. The precision of the timing to ensure that the objects in the game only move forward as much as they should in 1/100th of a second must need to be at least accurate to 1/1000th of a second. For instance, let's say it was only accurate to 1/100th of a second - some frames would record a time-frame of 0.00 seconds, some 0.01 seconds, and some 0.02 seconds (if the game slows down a bit). This effect would create the same frames being redrawn, and some frames moving objects twice as fast as other frames. The choppiness of movement would be unbearable. There are functions to handle high-resolution timing: High resoluton timing