
I have read all of the comments on this list over the last half a year regarding the Time library, and I feel I need to comment. (That was a lot of reading!) I write games, and I use Haskell. I don't need a time library to do anything fancy at all, no timezones, no leap seconds, nothing. I only need two things from a Time library: 1. An absolute assurance that some method of determining current time will give me an actual resolution of at most 1-3 milliseconds, without regard for leap seconds or even the user changing the system clock. 2. A way to set an event (OS signal, IO () function, whatever) to happen a certain amount of time in the future, again without regard to leap seconds or gross alteration of the system clock. #1 is very critical to games, because it is desirable to coordinate the display function with the rate of the screen refresh, which can be 85 Hz or higher on high-end machines. Hopefully, you redraw once and only once for each screen refresh. Currently, #2 means writing my own alarm thread and depending on poll and the like, as others have pointed out. Why can't that be a standard function? All of the other functions such as conversion and the like are frivolous for game design, because everything is measured relatively from game start, since the system clock as-is can't be trusted. Don't take this too seriously. Just know that the current method of achieving that kind of resolution requires using GLUT, which means eating up more memory and CPU than necessary. As always, thanks for a wonderful language, libraries, and compilers. - Eric Etheridge __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

Sorry, I missed this earlier.
In article <20050510072927.16394.qmail@web31707.mail.mud.yahoo.com>,
Eric Etheridge
I only need two things from a Time library:
1. An absolute assurance that some method of determining current time will give me an actual resolution of at most 1-3 milliseconds, without regard for leap seconds or even the user changing the system clock.
You almost certainly want getCPUTime from System.CPUTime. The new time library won't be replacing System.CPUTime.
2. A way to set an event (OS signal, IO () function, whatever) to happen a certain amount of time in the future, again without regard to leap seconds or gross alteration of the system clock.
If someone were to add this to the standard libraries, System.CPUTime would probably be a good place to put it. -- Ashley Yakeley, Seattle WA

Eric Etheridge wrote:
[...] Don't take this too seriously. Just know that the current method of achieving that kind of resolution requires using GLUT, which means eating up more memory and CPU than necessary. [...]
As the GLUT package author I'm curious what exactly eats up memory and/or CPU. Could you explain that a bit? Perhaps there's some room for improvement in the package... Cheers, S.
participants (3)
-
Ashley Yakeley
-
Eric Etheridge
-
Sven Panne