PROBLEM:
I rewrote the I_GetTime_RealTime function (in l_system.c) to use
SDL_GetTicks instead of gettimeofday and it works except it is slightly
faster (not to much of a problem) and jumpy (why i need to fix it).
This is what I used in the original DOOM port:
//
// I_GetTime
// returns time in 1/35 second tics
//
int I_GetTime (void)
{
return (SDL_GetTicks()*TICRATE)/1000;
}
You can download the new version from: http://lbjhs.net/lsdldoom/
(Sam: will you please add this to the games page)
Changes:
- Merged lxdoom 1.4.3 changes
- Various portability fixes (cross compilers now work with no
trouble, im working on getting it to
compile for win32 + hopefully will be doing the same for beos
soon)
- Misc. other changes
PROBLEM:
I rewrote the I_GetTime_RealTime function (in l_system.c) to use
SDL_GetTicks instead of gettimeofday and it works except it is slightly
faster (not to much of a problem) and jumpy (why i need to fix it).
I changed the folowing code:
struct timeval tv;
struct timezone tz;
unsigned long thistimereply;
gettimeofday(&tv, &tz);
//tv_sec is seconds tv_usec is microseconds
thistimereply = (tv.tv_sec * TICRATE + (tv.tv_usec * TICRATE) /
1000000);
to:
// reply is in miliseconds
int reply = SDL_GetTicks();
thistimereply = ((reply/1000) * TICRATE + (reply * TICRATE) / 1000);
any sugestions or explenations would greatly be apreciated, and if
anyone is willing to look into the code and fix it please feel free to
do so (the SDL_GetTicks version is in an ifdef in the version on the
page specified above)
Changes:
- Merged lxdoom 1.4.3 changes
- Various portability fixes (cross compilers now work with no
trouble, im working on getting it to
compile for win32 + hopefully will be doing the same for beos
soon)
- Misc. other changes
PROBLEM:
I rewrote the I_GetTime_RealTime function (in l_system.c) to use
SDL_GetTicks instead of gettimeofday and it works except it is slightly
faster (not to much of a problem) and jumpy (why i need to fix it).
I changed the folowing code:
struct timeval tv;
struct timezone tz;
unsigned long thistimereply;
gettimeofday(&tv, &tz);
//tv_sec is seconds tv_usec is microseconds
thistimereply = (tv.tv_sec * TICRATE + (tv.tv_usec * TICRATE) /
1000000);
to:
// reply is in miliseconds
int reply = SDL_GetTicks();
thistimereply = ((reply/1000) * TICRATE + (reply * TICRATE) / 1000);
any sugestions or explenations would greatly be apreciated, and if
anyone is willing to look into the code and fix it please feel free to
do so (the SDL_GetTicks version is in an ifdef in the version on the
page specified above)
You can download the new version from: http://lbjhs.net/lsdldoom/
(Sam: will you please add this to the games page)
Changes:
- Merged lxdoom 1.4.3 changes
- Various portability fixes (cross compilers now work with no
trouble, im working on getting it to
compile for win32 + hopefully will be doing the same for beos
soon)
- Misc. other changes
PROBLEM:
I rewrote the I_GetTime_RealTime function (in l_system.c) to use
SDL_GetTicks instead of gettimeofday and it works except it is slightly
faster (not to much of a problem) and jumpy (why i need to fix it).
I changed the folowing code:
struct timeval tv;
struct timezone tz;
unsigned long thistimereply;
gettimeofday(&tv, &tz);
//tv_sec is seconds tv_usec is microseconds
thistimereply = (tv.tv_sec * TICRATE + (tv.tv_usec * TICRATE) /
1000000);
to:
// reply is in miliseconds
int reply = SDL_GetTicks();
thistimereply = ((reply/1000) * TICRATE + (reply * TICRATE) / 1000);
any sugestions or explenations would greatly be apreciated, and if
anyone is willing to look into the code and fix it please feel free to
do so (the SDL_GetTicks version is in an ifdef in the version on the
page specified above)
hmm… I guess the problem is that the second formula when reordered
results in:
((replyTICRATE)/1000 + (replyTICRATE)/1000)
but I guess you only want : (reply*TICRATE)/1000 … thus the higher
speed
Your second version is jumpy because you are doing integer divisions:
(reply/1000) and then multiply with TICRATE … the other way round is
much more exactly: (reply*TICRATE)/1000 and will avoid the jumps… if
there are no other sideeffects… ;)–
Karsten-O. Laux
klaux at rhrk.uni-kl.de
the problem is fixed, Sam’s one worked(Thanks Sam), although i could have
sworn that was the first thing i tried.
hmm… I guess the problem is that the second formula when reordered
results in:
((replyTICRATE)/1000 + (replyTICRATE)/1000)
i noticed that and tried changing it to that but then it was to slow
but I guess you only want : (reply*TICRATE)/1000 … thus the higher
speed
Your second version is jumpy because you are doing integer divisions:
(reply/1000) and then multiply with TICRATE … the other way round is
much more exactly: (reply*TICRATE)/1000 and will avoid the jumps… if
there are no other sideeffects…