(proposal) SDL_GetCurrentTime()

Hello,

I just got an idea that it may be useful to have some kind of
SDL_GetCurrentTime() function in SDL. Or in some of the additional
libraries, maybe, but I think it is quite basical so it may belong
to the core libraries.

It might return, for example, a number of milliseconds passed since
midnight 1.1.1970, as an Uint64, so that it could be used both for
profiling and for getting a real time.

Have a nice day,

Jiri "BlueBear" Dluhos-- 

====================================================================
It is really quite easy to imagine a square yard of multidimensional
space, provided that you have seven brains.

                                      Prof. Abdullah Nightingale
                (Walter Moers: 13 1/2 lives of Captain Bluebear)

Jiri “BlueBear” Dluhos
Software Developer, HUMUSOFT s.r.o. (http://www.humusoft.com)
dluhos at humusoft dot com (office)
dluhosj at centrum dot cz (home)

I just add that, of course, if someone wants it, I’ll write it. :o)

Have a nice day,

Jiri “BlueBear” Dluhos–

It is really quite easy to imagine a square yard of multidimensional
space, provided that you have seven brains.

                                      Prof. Abdullah Nightingale
                (Walter Moers: 13 1/2 lives of Captain Bluebear)

Jiri “BlueBear” Dluhos
Software Developer, HUMUSOFT s.r.o. (http://www.humusoft.com)
dluhos at humusoft dot com (office)
dluhosj at centrum dot cz (home)

I just got an idea that it may be useful to have some kind of
SDL_GetCurrentTime() function in SDL. Or in some of the additional
libraries, maybe, but I think it is quite basical so it may belong
to the core libraries.

It might return, for example, a number of milliseconds passed since
midnight 1.1.1970, as an Uint64, so that it could be used both for
profiling and for getting a real time.

For game timing purposes, use SDL_GetTicks().
For calendar time, use time()

Mattias Engdeg?rd wrote:

I just got an idea that it may be useful to have some kind of
SDL_GetCurrentTime() function in SDL. Or in some of the additional
libraries, maybe, but I think it is quite basical so it may belong
to the core libraries.

It might return, for example, a number of milliseconds passed since
midnight 1.1.1970, as an Uint64, so that it could be used both for
profiling and for getting a real time.

For game timing purposes, use SDL_GetTicks().
For calendar time, use time()

It sounds strange mattias as we can wonder why it is logical to create a
SDL_GetTicks() as it can easily mannually calculated and why it wouldn’t
be useful to create a function which gives current time. Why first one
is more interesting than the second ?

Bye
Lawouach

Mattias Engdeg?rd wrote:

For calendar time, use time()

Yes, but is it portable enough?
To be quite honest, I thought it may possibly be useful to have
all these basical functions covered in SDL so that they always
behave the same way.
Even such basic functions as malloc() have side effects on Win32,
and I believe others have other quirks on various platforms.

I would be happiest if my application would use only the SDL_…
functions for accessing the system. The code would look much
better if nothing else. :o)

I understand it is easy to propose something and the hard part is
to implement it, but I’m of course ready to write the appropriate
code myself. :o)

Have a nice day,

Jiri “BlueBear” Dluhos–

It is really quite easy to imagine a square yard of multidimensional
space, provided that you have seven brains.

                                      Prof. Abdullah Nightingale
                (Walter Moers: 13 1/2 lives of Captain Bluebear)

Jiri “BlueBear” Dluhos
Software Developer, HUMUSOFT s.r.o. (http://www.humusoft.com)
dluhos at humusoft dot com (office)
dluhosj at centrum dot cz (home)

Jiri Dluhos wrote:

Mattias Engdeg?rd wrote:

For calendar time, use time()

Yes, but is it portable enough?

Ummm… it’s part of the ansi c library isn’t it?
Are there any SDL target platforms which don’t support time()?

SDL_GetTicks() is justified because there isn’t a standard
cross-platform way to easily get millisecond-resolution timestamps.

To be quite honest, I thought it may possibly be useful to have
all these basical functions covered in SDL so that they always
behave the same way.
Even such basic functions as malloc() have side effects on Win32,
and I believe others have other quirks on various platforms.

How about compiling us a list of all the quirks you know of?

eg:
What are the problems with time()? How would you implement SDL_time()?
You mention win32 malloc() - what problems do you know about? How would
you propose that an SDL_malloc() should work?

Ben.–
Ben Campbell
Programmer, Creature Labs
ben.campbell at creaturelabs.com
http://www.creaturelabs.com

For calendar time, use time()

Yes, but is it portable enough?

it’s part of the C standard

Even such basic functions as malloc() have side effects on Win32,

what “side effects”? If they don’t comply with the ISO C specs then too bad

It sounds strange mattias as we can wonder why it is logical to create a
SDL_GetTicks() as it can easily mannually calculated and why it wouldn’t
be useful to create a function which gives current time. Why first one
is more interesting than the second ?
false !
i try the litle exercise to writ my own “time” function. not very
difficult, i admit but, different OS (for instance windows and BSD)
don’t hacve the same structure and function for getting time !

and, las, i found a good idea to have a
Uint64 SDL_GetTicks();…

Lloyd Dupont wrote:

It sounds strange mattias as we can wonder why it is logical to create a
SDL_GetTicks() as it can easily mannually calculated and why it wouldn’t
be useful to create a function which gives current time. Why first one
is more interesting than the second ?
false !
i try the litle exercise to writ my own “time” function. not very
difficult, i admit but, different OS (for instance windows and BSD)
don’t hacve the same structure and function for getting time !

and, las, i found a good idea to have a
Uint64 SDL_GetTicks();…

What! Is 49.71027 days not long enough for any SDL based programs?
(is my math off? i dunno…)–
-==-
Jon Atkins
http://jonatkins.org/

[…]

Uint64 SDL_GetTicks();…

What! Is 49.71027 days not long enough for any SDL based programs?
(is my math off? i dunno…)

“Is 68 years (*) not long enough for any OS, application or file?”

() The maximum time span 32 bit Unx style time stamps can handle. We’re
about halfway to break the limit… Applications in banks and other
organizations already have to bypass the OS to deal with future dates
properly. Also applies to birth dates of old persons and other dates,
when used together with the current date/time.

Ok, this isn’t a totally accurate parallel, but if you would run an SDL
application on a turnkey system (public info terminal, arcade game, …), it
could well stay alive for more than 49 days without needing a reboot. (You
know, there are operating systems that don’t have to be rebooted every now
and then for no obvious reason. :wink:

//David

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Friday 18 May 2001 05:51, Jonathan Atkins wrote:

On Thu May 17, 2001 at 10:51:50PM -0500, the boisterous
Jonathan Atkins
wrote to me:

What! Is 49.71027 days not long enough for any SDL based programs?
(is my math off? i dunno…)

I think of SDL based arcade and casino games.

so long
Thomas–
___ Obviously we do not want to leave zombies around.
/\ - W. Richard Stevens
( ^ >
/ \ Thomas Krennwallner
(
/) Fingerprint: 9484 D99D 2E1E 4E02 5446 DAD9 FF58 4E59 67A1 DA7B

Ben Campbell wrote:

SDL_GetTicks() is justified because there isn’t a standard
cross-platform way to easily get millisecond-resolution timestamps.

But the same applies to time(). It has only second-resolution,
and higher precision functions are nonportable.

To be quite honest, I thought it may possibly be useful to have
all these basical functions covered in SDL so that they always
behave the same way.
Even such basic functions as malloc() have side effects on Win32,
and I believe others have other quirks on various platforms.

How about compiling us a list of all the quirks you know of?

Ok, I’ll try. Generally I feel the main problem is that MS libc is much
less needed for native applications and thus much less supported.
MS libc supports only very small and old set of ANSI functions.
I think it would be much safer to use the Win32 API, because it is used
by all applications, and so the bugs get found and fixed.
Moreover, I think there are some speed/memory penalties when using
the libc (e.g. with threads – when using libc and Win32 Thread
functions, memory leaks occur).

Just for a quick example, when talking about time related functions:
MS libc supports only the old ANSI functions, of which many, namely
gmtime(), localtime(), asctime(), ctime(), are thread unsafe.
There is no portable function for setting the time zone.

eg:
What are the problems with time()? How would you implement SDL_time()?

For Win32, something like

Uint64 SDL_GetCurrentTime()
{
FILETIME ft;

GetSystemTimeAsFileTime(&ft);
return (Uint64) ft.dwHighDateTime << 32 + (Uint64) ft.dwLowDateTime;
}

You mention win32 malloc() - what problems do you know about? How would
you propose that an SDL_malloc() should work?

The MS libc malloc(0) returns a valid pointer to an empty region,
I think glibc returns NULL in this case.
Also, I’m almost sure malloc() call is less effective than native
Win32 call, which allows heap management etc. Maybe it is not
too serious in this case, but e.g. with file access, it would
be much worse.
The most basic SDL_malloc() would be (for Win32):

void *SDL_malloc(Uint32 size)
{
return HeapAlloc(GetProcessHeap(), 0, size);
}

However, we could use a different heap, or have some debugging
facilities similar to glibc (optional checks for pointer validity,
autodetecting memory leaks etc.).
E.g. a very basic free() with pointer validity test:

int SDL_free(void *mem)
{
if (mem == NULL) return 1;
if (IsBadWritePtr(mem, 1) || !HeapFree(GetProcessHeap(), 0, mem))
{
SDL_SetError(“Attempt to free an invalid memory block”);
return 0;
}
return 1;
}

Have a nice day, and lotsa sunshine!

Yours sincerely,

Jiri "BlueBear" Dluhos-- 

====================================================================
It is really quite easy to imagine a square yard of multidimensional
space, provided that you have seven brains.

                                      Prof. Abdullah Nightingale
                (Walter Moers: 13 1/2 lives of Captain Bluebear)

Jiri “BlueBear” Dluhos
Software Developer, HUMUSOFT s.r.o. (http://www.humusoft.com)
dluhos at humusoft dot com (office)
dluhosj at centrum dot cz (home)

On Thu May 17, 2001 at 10:51:50PM -0500, the boisterous
Jonathan Atkins
wrote to me:

What! Is 49.71027 days not long enough for any SDL based programs?
(is my math off? i dunno…)

I think of SDL based arcade and casino games.

Good programmers write code that survives wraps in the values returned by
SDL_GetTicks(). This function exists only for calculating short intervals
not program uptimes IMHO and you are safe as long as you are doing
something like this:

current_getticks = SDL_GetTicks();
Sint32 tdiff = current_getticks - previous_getticks;
previous_getticks = current_getticks;
/* Do something (sleep, etc.) based on tdiff value. */On Fri, 18 May 2001, Thomas Krennwallner wrote:

Ville Hallik

The MS libc malloc(0) returns a valid pointer to an empty region,
I think glibc returns NULL in this case.

It’s implementation-defined. Either NULL or a unique pointer to an
empty region (which must not be accessed) may be returned, so both are
valid. No sane programmer would depend on the outcome in any case.

It is definitely nothing that needs to be added to the SDL API

Mattias Engdeg?rd wrote:

The MS libc malloc(0) returns a valid pointer to an empty region,
I think glibc returns NULL in this case.

It’s implementation-defined. Either NULL or a unique pointer to an
empty region (which must not be accessed) may be returned, so both are
valid. No sane programmer would depend on the outcome in any case.

Of course, that’s true. I thought the hypothetic SDL_malloc()
would be rather about an easier debugging and better memory
access optimization (like heaps etc.) than about security.
The malloc() itself is really so basic that it should work
even on a strangest libc so this probably is not so much an issue.
However, the time functions are different beasts - see my article.

Have a nice day,

Jiri “BlueBear” Dluhos–

It is really quite easy to imagine a square yard of multidimensional
space, provided that you have seven brains.

                                      Prof. Abdullah Nightingale
                (Walter Moers: 13 1/2 lives of Captain Bluebear)

Jiri “BlueBear” Dluhos
Software Developer, HUMUSOFT s.r.o. (http://www.humusoft.com)
dluhos at humusoft dot com (office)
dluhosj at centrum dot cz (home)

And if you really need to track times longer than SDL_GetTicks() can handle,
you could write a wrapper around it to track 64 bit values instead. From
time to time (any time less than 49 days between, one a frame for example,
though doesn’t necessarily need to be) call a function that checks if
SDL_GetTicks() is less than it was the last time you checked. If so, it
wrapped, so you increase your high order 32 bit int (SDL_GetTicks() would be
the low order 32 bit int). Now you can track intervals over a million years
if you really needed to.

I think tracking time intervals over 49 days in an SDL application probably
going to be quite rare. Can anyone on this list honestly say they’ve needed
to do this in any of their apps yet? I doubt it. And as I’ve shown, you can
derive this functionality based on what is available in SDL. So there’s no
good reason to bloat SDL with something like this. Remember that the S in
SDL stands for simple, and that’s what SDL should be. If you need something
more complicated, write that yourself on top of SDL, or use a supporting
library that does that instead, such as SDL_Image.On Friday 18 May 2001 03:03, you wrote:

On Fri, 18 May 2001, Thomas Krennwallner wrote:

On Thu May 17, 2001 at 10:51:50PM -0500, the boisterous
Jonathan Atkins

wrote to me:

What! Is 49.71027 days not long enough for any SDL based programs?
(is my math off? i dunno…)

I think of SDL based arcade and casino games.

Good programmers write code that survives wraps in the values returned by
SDL_GetTicks(). This function exists only for calculating short intervals
not program uptimes IMHO and you are safe as long as you are doing
something like this:

current_getticks = SDL_GetTicks();
Sint32 tdiff = current_getticks - previous_getticks;
previous_getticks = current_getticks;
/* Do something (sleep, etc.) based on tdiff value. */