Gerry JJ wrote:
Den Tue, 18 Sep 2007 11:20:59 +0700 (WIT)
skrev @benang_at_cs.its.ac:
Hi, I have a problem here. I just found out that my machine will be
operated 24/7 non stop. I know that this will make the timing and
ticks wrong. My questions are:
- Anybody know how to handle the ticks if it was run more than the
ticks value can handle (Uint32 I believe)? FYI, I used ticks for
animation and few other things so it is a crucial issue.
Actually this might not be much of a problem, since differences wrap
around too thanks to two’s complement. For example:
Uint32 before = 4294967295; // = (Uint32)-1
Uint32 after = 1;
printf("%u\n", after - before); // = 2
So as long as you don’t need tick differences bigger than 32 bits you
should be fine. If you do need bigger differences for some reason, you
could accumulate ticks:
//in stead of SDL_GetTicks() (call somewhat regularly):
Uint64 GetTicks64 (void) {
static Uint64 ticks64 = 0;
static Uint32 lasttick = 0;
Uint32 currenttick = SDL_GetTicks();
ticks64 += currenttick - lasttick; //works, as above
lasttick = currenttick;
return ticks64;
}
I see. So I guess I wouldn’t have to change my code after all.
This will still wrap around after 18446744073709551616 ticks though =).
Apart from that it might work, assuming SDL doesn’t otherwise screw up
things when the 32-bit ticks wrap around. I don’t think it does,
though.
Also, if you don’t do it already, you could consider making your
program have a fixed logic rate, separate from the video framerate.
Everything would then depend on “logic ticks” in stead of clock ticks.
I don’t quite understand. What do you mean about “logic ticks”?
- Any other issue that would appear in the 24/7 non stop operation
of an SDL application (SDL-wise or Linux-wise)? I know this is a
rather abstract question, but I need your opinions and assumptions of
what could go wrong so I could recognize the problem beforehand.
Well, Linux should be fine, as long as your program doesn’t have
memory/resource leaks and such. Don’t know about SDL.
Well, I’m not quite sure about this. When I do a valgrind, there are
memory leaks. But none of them was caused by my own code, but instead
SDL’s. They are from these methods:
- SDL_SetVideoMode() method
- SDL_Init() method
- Mix_OpenAudio() method
- etc (forgot the rest but when I traced the valgrind’s log it’s not from
any of my code)
BTW, actually there’s an issue in the machine when it was run for a week.
But I don’t know whether it was caused by SDL or not. My machine requires
inputs from the serial port. So, I made a routine to check for a serial
input asynchronously at the main loop. And then I used a custom
SDL_USEREVENT that was passed to the event queue if there is an input. The
problem is if the machine was run for a week and there’s a serial input,
the game crashed. The keyboard, mouse, etc didn’t work so I guess it’s not
an infinite loop issue. And IMHO it has got nothing to do with the
SDL_GetTicks(). I don’t know whether the cause is the serial handler
(because I used a pure C on a C++ object) or the SDL event handler or
maybe something else. I’m also confused because to test it, I need to wait
for a week until the problem comes up.
Thanks a lot.
Fare thee well,
Bawenang R. P. P.----------------
ERROR: Brain not found. Please insert a new brain!
?Do nothing which is of no use.? - Miyamoto Musashi.
“I live for my dream. And my dream is to live my life to the fullest.”