Public Group

# An SDL_GetTicks() problem? (solved)

This topic is 4812 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I'm using the latest SDL on VS .NET 03. After looking up the documentation on SDL_GetTicks(), I don't think it's doing what it's supposed to be doing. From the documentation: SDL_GetTicks -- Gets the number of milliseconds since SDL library initialization I have an "idle()" function that is that main game loop and calls SDL_GetTicks() in order to keep the delta time between frames. This seems to work correctly, as reasonable values are being sent to my update functions (called from idle) for all my objects. However, I have a "particle" that is only supposed to be on screen for a max of 3000 milliseconds (or however long I want it to be), and has a "bornOn" variable that is set to SDL_GetTicks() upon creation. Again, the bornOn value seems reasonable. The particle's update function checks the bornOn value to an SDL_GetTicks() call, and sees if the difference is greater than 3000. This is where I get a problem. The value returned by SDL_GetTicks() in my update function is the same as the delta time I pass to it. It seems the GetTicks function isn't working properly within the update function. The particle and its update function:
Particle::Particle()
{
isAlive = true;
bornOn = SDL_GetTicks();
....
}

bool Particle::Update(double deltaTime)
{
if((SDL_GetTicks() - bornOn) > LIFE_OF_PARTICLE)
{
isAlive = false;
}
else
{
Object::update(deltaTime, DEFAULT_FRICTION);
}

return isAlive;
}

Thanks for any help anyone can offer. [Edited by - fortenbt on June 17, 2005 2:13:24 PM]

##### Share on other sites
Are you sure it's not your deltatime that's wrong? You say it's the same as SDL_GetTicks but that's very unlikely given that the former is a double and the latter is a 32-bit integer.

There's not much code there to go on. There's no reason SDL_GetTicks would stop working just because it's been put into a function so the problem presumably lies with one of the other variables. Could you give a few sample values that you're seeing, or maybe show how you calculate the deltatime, bornon, and LIFE_OF_PARTICLE values?

##### Share on other sites

Okay, well I looked through it and debugged some more, and realized that the SDL_GetTicks value I'm getting in within the particle's update is only the same as deltatime the first time it's passed in...which is correct. (The values, by the way, are always around 230, which I found to be reasonable for the program to take 230 milliseconds to initialize and get to the first particle update). However, I did find that the bornOn value for the particle is 9,248,546.000000 (ms, which comes out to about 2 and a half hours, just about the amount of time my computer was on), and it gets larger every time I run it.

Weird note: I restarted my computer, and the particle's bornOn value was 46,723 (about 46 seconds...I would even say the exact amount of time since I restarted my computer to when I recompiled).
Other note: I was reading about the weird time going backwards bug in GetTicks here: http://www.libsdl.org/pipermail/sdl/2002-December/051245.html It turned out that the bug wasn't in SDL, but someone mentioned in a reply that there's something weird with the laptop counter that counts clock cycles. I'm using a laptop right now, even though I really doubt that's the problem, considering the function works everywhere else.

For some clarification, here's how I calculate some of the variables:

//within idle{static double newTime(0);static double oldTime(0);static double diffTime(0); //what I've been calling deltatimenewTime = SDL_GetTicks();diffTime = newTime - oldTime;...particle.update(diffTime);...oldTime = newTime;}

And I already posted my particle's update function. Just to give more information, my particle class is a child of my object class, which doesn't do anything but physics calculations for movement.

Ben

##### Share on other sites
Are you passing the SDL_INIT_TIMER flag to SDL_Init()? Or calling SDL_InitSubSystem(SDL_INIT_TIMER) at any point? I'm not 100% sure you need to for SDL_GetTicks() - but I think it is part of the timer subsystem.

##### Share on other sites
Oh, geez! No, but that would make total sense. If I don't initialize a starting point for the timer, it's probably just taking the system time? And then that would also explain why the diffTimes are all correct.

I'm not completely sure where to add them, but I added both and I'm still getting massively large numbers for bornOn.

In my main, the first thing I do is call init(), which calls setScreen shown below.
void setScreen(in w, int h, bool fullScreen){   if(SDL_Init(SDL_INIT_VIDEO | SDL_INIT_TIMER) < 0) //I added the | SDL_INIT_TIMER here    {        //failed initialization, quit    }    //didn't know where to put this, if at all, so I put it here    SDL_InitSubSystem(SDL_INIT_TIMER);    ...}

Should I put these anywhere else/am I doing it correctly?

--Ben

##### Share on other sites
You don't need to call SDL_InitSubSystem(SDL_INIT_TIMER); if you set it up in SDL_Init() and it returns a sucessful value.

get rid of SDL_InitSubSystem(SDL_INIT_TIMER); in your code and see if it works

##### Share on other sites
If you haven't done already, you also might want to subscribe to the SDL developers mailing list.

I've learned much just from reading through it.

##### Share on other sites
I had tried each solution separately before trying both. None worked. Thanks a lot for the suggestion though; I really think that's where the problem is.

I'll read more on SDL's site to see if I can't get this.

##### Share on other sites
Asking on the mailing list might not hurt either, there are many knowledgeable people on it.

##### Share on other sites
Quote:
 Original post by fortenbtstatic double newTime(0);static double oldTime(0);static double diffTime(0);...newTime = SDL_GetTicks();diffTime = newTime - oldTime;

SDL_GetTicks() returns a Uint32, not a double.

-ßrice

1. 1
2. 2
JoeJ
16
3. 3
4. 4
5. 5
frob
11

• 13
• 16
• 13
• 20
• 12
• ### Forum Statistics

• Total Topics
632178
• Total Posts
3004606

×