What's the best way in Carbon to

-run an event loop (mouse,keyboard) at a constant rate

-run a game loop at a constant but changable state [would handle AI and have an influence on movement

-run a draw loop which does fps relative movement and can skip or limit fps

Is this possible? Is this what I really want (read my mind please).


Right now I have AI tied in with the event loop which uses WaitNextEvent with drawing done with a timer. I think. It's how Apple's SetupGL is set up.

Thanks,

Nickolei

Because you are using Carbon you may want to use the Carbon Event Manager for this.
You can use InstallEventLoopTimer() for timed tasks like drawing, game loop and so on. Just read through the headers or check the documentation at developer.apple.com


-Tobi

Your best bet is carbon timers, but you will need to be aware of how they differ between 9 and X - if you are using 9, the best resolution you will get is ticks (1/60 second) I believe, whereas on X you will get closer to the accuracy you require. Also, carbon timers are not constant. If the time to fire passes for whatever reason (the last frame took too much time) you will skip, and it will fire at the next available time.

If you want to keep accurate and constant times, you should use a carbon timer that fires fairly frequently (say 1ms or more often) and each time through your timer loop call a function to calculate the delta time (time since last call) - use Uptime in most cases for this.

There is a tutorial/source somewhere on this site about using the built in PPC timers.

Cheers,
Johan

I set everything up using carbon timers...and have movement relative to fps...but...

it seems that whenever it skips a draw timer for one reason or another I get a jump on the next one (since twice as much time has passed). Then end result is that movement is hiccupy at best. This happens on both os 9 and X.

I'm using UpTime() and AbsoluteDeltaToDuration so I don't think accuracy is the problem.

Any advice before I redo without timers?



Thanks for all the help.

-Nickolei

Quote:and have movement relative to fps...

Just to clarify, does that mean that for each frame you draw, you calculate how long has elapsed since the previous frame and use that to influence movement speed, &c?

You should be doing that, and you should have your timers set up to fire every 1 or 2 milliseconds, so you don't restrict your framerate.

Yeah that's what I'm doing...I read a bunch about that on gamedev and various other places. I calculate how much time has passed since the last draw, move all objects toward their destination * time passed since last draw.

I'll play around with my WaitNextEvent and Timer values some more I guess. All part of the fun I suppose.

Looks like I'm way off base...I get choppy animation without timers. Maybe I'm using UpTime wrong.

Try GetCurrentEventTime(). It's easy to use, and I've had good success with it in the past.

I have been unsuccessfull with WNE and carbon timers and got the same animation "jumps" Nickolei was talking about... ( using UpTime() )
I handle UI events with WNE and have set a carbon timer every 1ms to draw my 3D world.

I will try with GetCurrentEventTime() but i do not see why it should work better ? I thought that UpTime() was accurate enough to compute a delta time...

I recommend not using WNE at all. I can't remember if I used it in the beginning of my project, but I have a vague memory that I got pretty bad animation. Try using Carbon Events for user input as well.

I'm sorry. That was me posting the last message. I guess it has been some time since I participated in the discussions here. Created a new account now, so everybody should be happy