[Gardon]

Ok, I've actually started coding! I started up the project and everything, and I'm all amped to go.

However, I do have one problem. I need to know how to manage the time within the game.

Is there a way to handle stuff without relying on previous frame times?

Jason

[Ninkazu]

If you're using SDL, you can use SDL_GetTickCount() which gives you milliseconds that you can compare to later times to get time passed. If you're using anything else, just check the API for anything about ticks.

[Gardon]

No problem

[Gardon]

Maybe I have to use the system's counter, like the atomic clock of the computer itself to check time.

[LeoDraco]

Hey Gardon: I realize you want answers to your questions, and see them as imperative, but could you please edit your previous posts rather than multi-post? Those whom have not seen your last message will still have something new (regardless), and it tends to keep your threads cleaner.

As it is, with the wonderfully large amount of posts per minute around this place, you hardly have to worry about keeping a topic bumped.

General exception to the above etiquette rule: if your topic has been unresponsive for a period of time greater than, say, a day or so, the multi-post thing might be excusable. However, posting again within a minute of your last post is a bit, ah, flamboyant.
_________________
"...LeoDraco is a pompus git..." -- Mandrake

[RuneLancer]

[Gardon]

That directly answered my question. Incredible

No seriously, I never would have thought of something like that (well, maybe sooner or later when I finally sat down to really think about what needed to get done).

And that's what I meant, having the guy move the same amount of space, regardless of his framerate.

And it works too because I can have a set speed to move him, unlike previous projects where I move him according to other things.

I went with the 2nd one because it seems more smooth. I've never liked the sleep method, and this is a good alternative.

Thank you so much,

Jason

[Gardon]

I do have another question though.

What would be a good unit for 2D games?


What I was thinking of doing was having the timer function set a variable to however long the last frame was (giving the milliseconds of the frame).

I then divide that millisecond value from 1000 to get the fps.

AFterwards, I take the given speed I want to move at, and divide it by the fps to get the units to move.


So what should the units be? I know this sounds pretty basic, but if you think about it, it gets harder.


Can you approximate pixels and such, so that I can move it based on pixel movement? It would always be constant movement, but the decimal places might throw some things off.

Here's an example:


Time from last frame: 16.667 milliseconds

1000 / 16.667 = 60fps

Desired speed = 100 pixels/second

100 / 60 = 1.667units



Now, if you look at another one:


Time from last frame: 1 millisecond

1000 / 1 = 1000fps

Desired speed = 100 pixels/second

100 / 1000 = .1 units



So for both examples we have 16.667 and .1

Would those round, so 16 would always be 17 pixels and .1 would always be 0?

Jason

[Ninkazu]

They don't round unless you're using auto-truncating data types such as an int. I'd use floats for those calculations. Also for choosing your unit size, just think of the idea fps (60) and how fast you want a character to move in that condition (pixels/sec) then convert to your unit size for global use.

[RuneLancer]

Just backing up LD's earlier post.

Have you experimented before posting? For all you know, sub-pixel precision in your game may average out to something fully acceptable when you display your sprite.

Experiment man, some of the answers you need to find for yourself. ;)

By the way, what you're calculating with...