[SDL] SDL for a 24/7 machine

Gerry JJ trick at icculus.org
Tue Sep 18 06:40:17 PDT 2007


Den Tue, 18 Sep 2007 11:20:59 +0700 (WIT)
skrev benang at cs.its.ac.id:
> 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:
> 
> 1. 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;
	}

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.

> 2. 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.

- Gerry


More information about the SDL mailing list