Quote:Original post by Kylotan Your original suggestion is good enough, with a small modification. If you need to do something every 10ms, but 16ms has elapsed, then you do whatever needs to be done, and you cut 6ms off the schedule for the next one.
Unfortunately this doesn't work. This post explains why. Unless I misunderstood you?
It looks like using MJP's fixed time-step will solve this issue, but I still haven't gotten an answer as to how to choose the time-step.
You misunderstood me. I'm not suggesting a sampling approach to see which events are due right now, I'm suggesting watching to see which events have become due since last time, and at that point, you can handle it and see if yet another event will become due as a result. Each time you check whether an event is due, and if it is, you handle it, which for repeated actions typically involves scheduling the next event. That new event may be due already, so you handle that as well, until you're out of events to handle. This way you could end up firing 10 bullets per update, or whatever. You also know exactly how overdue each one is, so you can factor that into your physics or graphics.
As for choosing the time step, it's arbitrary. Pick one that is fine-grained enough to work for you, but not so fine-grained that you waste too much CPU time on trivial updates. As typical examples, I've heard of some people using 10Hz, others using 25Hz or 30Hz.
Quote:Original post by Kylotan I'm suggesting watching to see which events have become due since last time, and at that point, you can handle it and see if yet another event will become due as a result. Each time you check whether an event is due, and if it is, you handle it, which for repeated actions typically involves scheduling the next event. That new event may be due already, so you handle that as well, until you're out of events to handle. This way you could end up firing 10 bullets per update, or whatever.
I think I'm starting to get it. I also think that that's what MJP suggested with his code for the fixed time-step loop, though it looks like I'll have to do that for each event (because different events can have different execution frequencies). I'm not sure how I should set all this up...
Quote:This way you could end up firing 10 bullets per update, or whatever. You also know exactly how overdue each one is, so you can factor that into your physics or graphics.
I assume you are referring to interpolation. I haven't even thought about how that will work, but that's a topic for another thread...
Thank you for your help. I'll think about this some more and maybe try to implement a simple demo and see if it works out.
