Just FYI, timestamped events are on the TODO list for SDL 1.3
They’re absolutely essential for some kinds of event processing.
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
Sam Lantinga wrote:
Just FYI, timestamped events are on the TODO list for SDL 1.3
They’re absolutely essential for some kinds of event processing.
Great!
Does that imply that you are going to store events in a priority queue
and allow
future timestamped events to be placed in the queue?
TTFN!
Bob P.>
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
±-----------------------------------+
- Bob Pendleton is seeking contract +
- and consulting work. Find out more +
- at http://www.jump.net/~bobp +
±-----------------------------------+
Does that imply that you are going to store events in a priority queue
and allow
future timestamped events to be placed in the queue?
No, but that’s an interesting idea. The main problem is that the timestamp
used by the windowing system (if any) may not have any relationship to the
value returned by SDL_GetTicks()
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
Sam Lantinga wrote:
Does that imply that you are going to store events in a priority queue
and allow
future timestamped events to be placed in the queue?No, but that’s an interesting idea. The main problem is that the timestamp
used by the windowing system (if any) may not have any relationship to the
value returned by SDL_GetTicks()
Yah, that is a problem. If you keep track of the first timestamp on the
first event you get from the OS and the GetTicks value for the time when
you go that event and use those to compute a bias you should be able to
synch new OS generated timestamps with the SDL_GetTicks() time by
subtracting the bias from the timestamp so that your timestamps start
at zero just like SDL_GetTicks(). On the other hand, does anyone write
code that counts on the fact that SDL_GetTicks() restarts at zero every
time you start the program?
I used to do discrete event simulations and those are based on the idea
of an event queue that is ordered by time. Several years ago I applied
the same ideas used in discrete event simulation to games and found that
they worked very well and they insured that input events and game
generated events, such as “the torch burned out,” “the Ogre checked the
hall,” and so on took place in exact sequence with input actions. And it
leads to a very simple style of programming in which there are very few
timers, just events that invoke methods of objects. (Discrete event
simulation drove the development of object oriented programming while
GUIs drove its wide spread adoption.)
Bob Pendleton
P.S.
If you wanted to use SDL to write a portable game server you would need
something like SDL_GetTicks() that didn’t roll over after 49 days.>
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
±-----------------------------------+
- Bob Pendleton is seeking contract +
- and consulting work. Find out more +
- at http://www.jump.net/~bobp +
±-----------------------------------+
If you wanted to use SDL to write a portable game server you would need
something like SDL_GetTicks() that didn’t roll over after 49 days.
What about introducing a new SDL_GetTicks in SDL 1.3 which returns the number
of ticks since the last time SDL_GetTicks was called ?–
Trick
Linux User #229006 * http://counter.li.org
“There is no magic” - Nakor, magic user
Trick wrote:
If you wanted to use SDL to write a portable game server you would need
something like SDL_GetTicks() that didn’t roll over after 49 days.What about introducing a new SDL_GetTicks in SDL 1.3 which returns the number
of ticks since the last time SDL_GetTicks was called ?
That would work.
You could also add an “epoch” variable that would start at zero and have
one added to it each time the SDL_GetTicks value rolled over. The
combination of that value and the SDL_GetTicks value would let server
writers have the information they need and wouldn’t change the API for
anyone else. So to get a time > 49 days you would do something like
Uint32 lobits = SDL_GetTicks();
Uint32 hibits = SDL_GetEpoch();
Or, you could add a completely separate function that returns a pointer
to a stucture with a two (32 bit) word tick value.
Are there any C/C++ compilers left that don’t support some form of a 64
bit integer? If it didn’t raise issues with portability I’d just suggest
adding something like SDL_LLGetTicks() that returns a 64 bit time.
Bob Pendleton--
±-----------------------------------+
- Bob Pendleton is seeking contract +
- and consulting work. Find out more +
- at http://www.jump.net/~bobp +
±-----------------------------------+
Trick wrote:
What about introducing a new SDL_GetTicks in SDL 1.3 which returns the number
of ticks since the last time SDL_GetTicks was called ?
do I even have to mention why this is an incredibly bad idea?
Mattias Engdeg?rd wrote:
Trick wrote:
What about introducing a new SDL_GetTicks in SDL 1.3 which returns the number
of ticks since the last time SDL_GetTicks was called ?do I even have to mention why this is an incredibly bad idea?
I guess you do, I don’t see a problem.>
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
±-----------------------------------+
- Bob Pendleton is seeking contract +
- and consulting work. Find out more +
- at http://www.jump.net/~bobp +
±-----------------------------------+
At 06:59 PM 1/17/2002 +0100, you wrote:
If you wanted to use SDL to write a portable game server you would need
something like SDL_GetTicks() that didn’t roll over after 49 days.What about introducing a new SDL_GetTicks in SDL 1.3 which returns the number
of ticks since the last time SDL_GetTicks was called ?–
Trick
What ??? are you that lazy ??? First it would kill backward compatability
with existing code, and second it is VERY trivial to implement on your own
UInt32 ticks,lapse;
ticks = SDL_GetTicks();
… other stuff
lapse = SDL_GetTicks - ticks;
Shane
If you wanted to use SDL to write a portable game server you would need
something like SDL_GetTicks() that didn’t roll over after 49 days.
Not if you design the game logic appropriately. Unless you somehow need to
reference the time since the server booted (which I can’t really imagine),
you only need time deltas between different events.
You will have to be a bit more careful with time calculations, but unless you
need to work with timespans >25 days, everything should be fine. Normally,
you’ll only have to worry about time spans of a few minutes max
cu,
Nicolai
“Trick” wrote in message
news:mailman.1011291725.14266.sdl at libsdl.org…
If you wanted to use SDL to write a portable game server you would
needsomething like SDL_GetTicks() that didn’t roll over after 49 days.
What about introducing a new SDL_GetTicks in SDL 1.3 which returns
the number
of ticks since the last time SDL_GetTicks was called ?
Implicit state is bad. However, how about a ‘SDL_GetTicksSince’?
Uint32 first_time = SDL_GetTicks();
/* Do something here */
Unit32 time_passed = SDL_GetTicksSince(first_time);
This has the advantage that several different components can measure
delays independently.–
Rainer Deyke (root at rainerdeyke.com)
Shareware computer games - http://rainerdeyke.com
"In ihren Reihen zu stehen heisst unter Feinden zu kaempfen" - Abigor
Shane Fausett wrote:
At 06:59 PM 1/17/2002 +0100, you wrote:
If you wanted to use SDL to write a portable game server you would need
something like SDL_GetTicks() that didn’t roll over after 49 days.What about introducing a new SDL_GetTicks in SDL 1.3 which returns the number
of ticks since the last time SDL_GetTicks was called ?–
Trick
What ??? are you that lazy ??? First it would kill backward compatability
with existing code, and second it is VERY trivial to implement on your own
Hummm… I read the sentence to mean “What about introducing a new
FUNCTION LIKE SDL_GetTicks in SDL 1.3…” While it would appear that you
read the sentence to mean “What about REPLACING SDL_GetTicks in SDL
1.3…” If Mattias interpreted it the way you did I now understand his
objection.
If there are more that one way to interpret something and one of the
interpretations is reasonable, and the rest are not, I’ve found that
people usually meant the reasonable interpretation. Assuming the worst
about people is almost always a mistake.
Bob P.--
±-----------------------------------+
- Bob Pendleton is seeking contract +
- and consulting work. Find out more +
- at http://www.jump.net/~bobp +
±-----------------------------------+
At 12:04 PM 1/17/2002 -0700, you wrote:
“Trick” wrote in message
news:mailman.1011291725.14266.sdl at libsdl.org…If you wanted to use SDL to write a portable game server you would
needsomething like SDL_GetTicks() that didn’t roll over after 49 days.
What about introducing a new SDL_GetTicks in SDL 1.3 which returns
the number
of ticks since the last time SDL_GetTicks was called ?Implicit state is bad. However, how about a ‘SDL_GetTicksSince’?
Uint32 first_time = SDL_GetTicks();
/* Do something here */
Unit32 time_passed = SDL_GetTicksSince(first_time);This has the advantage that several different components can measure
delays independently.
what is the difference between that and
time_passed = SDL_GetTicks() - first_time;
???
Shane>–
Rainer Deyke (root at rainerdeyke.com)
Shareware computer games - http://rainerdeyke.com
"In ihren Reihen zu stehen heisst unter Feinden zu kaempfen" - Abigor
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
What about introducing a new SDL_GetTicks in SDL 1.3 which returns the
number of ticks since the last time SDL_GetTicks was called ?do I even have to mention why this is an incredibly bad idea?
Well, i’m kinda stupid today.
Anyway, i didn’t mean to call it ‘SDL_GetTicks’, of course give it a new
name. The idea was to remove that problem of progs crashing after 49 days
(those kind of bugs belongs in winnt)–
Trick
Linux User #229006 * http://counter.li.org
“There is no magic” - Nakor, magic user
Nicolai Haehnle wrote:
If you wanted to use SDL to write a portable game server you would need
something like SDL_GetTicks() that didn’t roll over after 49 days.Not if you design the game logic appropriately. Unless you somehow need to
reference the time since the server booted (which I can’t really imagine),
you only need time deltas between different events.
You will have to be a bit more careful with time calculations, but unless you
need to work with timespans >25 days, everything should be fine. Normally,
you’ll only have to worry about time spans of a few minutes max
Yeah, I know how to do that. The problem is that the underlying OS time
routines provide a lot longer time duration than SDL_GetTicks() does. I
hate the idea of adding complexity to a program just to recover
information that is available from the OS. What I really want is a
version of Java’s System.currentTimeMillis() that returns the date in
milliseconds since the start of the epoch as a 64 bit value. It’s just
very useful.
Bob P.>
cu,
Nicolai
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
±-----------------------------------+
- Bob Pendleton is seeking contract +
- and consulting work. Find out more +
- at http://www.jump.net/~bobp +
±-----------------------------------+
What about introducing a new SDL_GetTicks in SDL 1.3 which returns
the number of ticks since the last time SDL_GetTicks was called ?do I even have to mention why this is an incredibly bad idea?
It’s good to know the sensitivity training is going well, Mattias. 
–ryan.
Rainer Deyke wrote:
“Trick” wrote in message
news:mailman.1011291725.14266.sdl at libsdl.org…If you wanted to use SDL to write a portable game server you would
needsomething like SDL_GetTicks() that didn’t roll over after 49 days.
What about introducing a new SDL_GetTicks in SDL 1.3 which returns
the number
of ticks since the last time SDL_GetTicks was called ?Implicit state is bad. However, how about a ‘SDL_GetTicksSince’?
Uint32 first_time = SDL_GetTicks();
/* Do something here */
Unit32 time_passed = SDL_GetTicksSince(first_time);This has the advantage that several different components can measure
delays independently.
I agree, implicit state is bad. But, unless you change your time value
from being a Uint32 to something with more bits your proposal still
wraps after 49 days. If we add something like and SDL_Time structure and
a new function to return it, then your approach works well.
Bob P.>
–
Rainer Deyke (root at rainerdeyke.com)
Shareware computer games - http://rainerdeyke.com
"In ihren Reihen zu stehen heisst unter Feinden zu kaempfen" - Abigor
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–
±-----------------------------------+
- Bob Pendleton is seeking contract +
- and consulting work. Find out more +
- at http://www.jump.net/~bobp +
±-----------------------------------+
My guess is that Mattias is concerned about this function being called in
multiple places and such. Though I hadn’t thought of that until the next
email I got after this one.
The other possibility (which is the one I thought of first) is the
SDL_GetTicks() has an error of ±9 ms. (it’s accurate within 10ms… I have
suggested methods that would up the accuracy to nanoseconds for Windows, and
actually took less time to call on the computers I tested it on, but I don’t
think I could reproduce this on all the systems the SDL works on). First
off, ms. are a long time in modern computers. Secondly, you could get the
same value for 2 events that occurred 9 ms. apart… or have 2 that measured
10 ms. apart, when they only occurred 1 ms. apart. That would not be a very
accurate way to do it.
I DO like the SDL_GetTicksSince(), this could be very portable (I’d think).
Another suggestion would be SDL_GetSeconds(). This could then return a 32
bit value for the number of seconds since SDL has been started. This would
up the amount of time before a loop over from 49 days to 4900 days (over 13
years). You could then do compares on the seconds and the ms. (I know you
still have to account for the value looping, but not as much.) Perhaps an
SDL_ResetTicks() and SDL_ResetSeconds() would help as well. Every couple
days, just reset the Ticks to 0, but you’d know when it happened (if you are
reasonably sure your event queue will be empty once every 49 days, this
would fix everything)> ----- Original Message -----
From: bob@pendleton.com (Bob Pendleton)
To:
Sent: Thursday, January 17, 2002 12:56 PM
Subject: Re: time stamped events, was [SDL] Detecting Double ClicksMattias Engdeg?rd wrote:
Trick wrote:
What about introducing a new SDL_GetTicks in SDL 1.3 which returns the
numberof ticks since the last time SDL_GetTicks was called ?
do I even have to mention why this is an incredibly bad idea?
I guess you do, I don’t see a problem.
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl–
±-----------------------------------+
- Bob Pendleton is seeking contract +
- and consulting work. Find out more +
- at http://www.jump.net/~bobp +
±-----------------------------------+
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
“Shane Fausett” wrote in message
news:mailman.1011295385.16668.sdl at libsdl.org…
At 12:04 PM 1/17/2002 -0700, you wrote:
Implicit state is bad. However, how about a ‘SDL_GetTicksSince’?
Uint32 first_time = SDL_GetTicks();
/* Do something here */
Unit32 time_passed = SDL_GetTicksSince(first_time);This has the advantage that several different components can
measuredelays independently.
what is the difference between that and
time_passed = SDL_GetTicks() - first_time;
Some people appearently feel a need to have this functionality
encapsulated in a function. It would cut down the noise in this
newsgroup/mailing list. And it’s really small and trivial to
implement, so why not?
Uint32 SDL_GetTicksSince(Uint32 last_time)
{
return SDL_GetTicks() - last_time;
}–
Rainer Deyke (root at rainerdeyke.com)
Shareware computer games - http://rainerdeyke.com
"In ihren Reihen zu stehen heisst unter Feinden zu kaempfen" - Abigor
“Ryan C. Gordon” wrote:
do I even have to mention why this is an incredibly bad idea?
It’s good to know the sensitivity training is going well, Mattias.
I’m sorry if I sound a bit harsh at times, but if people can debate
endlessly about utterly trivial parts of SDL, problems which are
no problems, without ever thinking about it, how can they even
hope to understand the hard parts?
I see absolutely no reason not to use more or less exactly the
same SDL_GetTicks() in future SDL releases. It is simple, it is easy
to implement, it is easy to understand, it is easy to use, and you
don’t need 64-bit integers.
There are design mistakes in SDL (and I’m responsible for several of them),
and we know how to improve stuff if we get the chance.
SDL_GetTicks() is not a design mistake.