Stop a Method taking to long.

Question

I'm sure I've seen this somewhere but can't remember where and it might have been in C# anyway.

I have a bunch of game-objects that get looped through each being updated. Is it possible to break an update method if its taking to long?

For instance if a programmer adds a bunch of code that takes to longer to do during 1 update cycle can I terminate its update (while updating) so that the frame-rate of the game remains constant?

I'd guess this might have todo with threading but I'm not sure.

Thanks,

Phil.

Answer 1

Yes you need threads.

Rather than raw pthreads (or platform specific equivalent) you might want to look if your game library supports it's own thread model

edit: if it's your own code - this is probably one of the harder bits to get right. Threading is tricky, controlling thread access, priorities and quotas is even harder.

Generally killing threads is a bad idea, the cleanup code is always tricky. The easiest is to have a flag in the loop of the worker thread which is checked on each iteration. Then the controller thread can set this to 'die' if it has overrun and the thread will quit. Closing deadlocked threads is harder.

Answer 2

If you control the interface of the update, you could pass it the permitted time, and have the game object terminate itself. Kind of like cooperative multithreading.

This could be your best bet if you have very many objects, since you cut the overhead of real threads.

Answer 3

Threading is the usual way to break up work into independent work units.

Another way is to spread the work across frames based on time. Hopefully you have some kind of program timer that is advancing each frame.

Break the algorithm up into pieces, with no single piece taking longer to run than say 20ms. Trigger an "event," start recording the time from the beginning of that event and if enough time has passed, say 20 ms, then run the next part of your algorithm. It's a poor man’s time-slice. :-)

Here is a site about getting your game/simulation to use time instead of machine cycles.

Fix Your Timestep

Answer 4

The real question is why updating some state would kill the frame-rate ?

It's a matter of design, but you will need threads, for several reasons:

• you want a constant frame-rate, this means a thread dedicated to display, most of the work should be done by the graphic card nowadays, but still
• you want to be reactive to input/output, that's another thread, indeed most IO require a dedicated thread: you can pair keyboard + mouse in one, but you'll need two for networking (one to send, one to receive)
• you'll want a number of threads (at least one) to do the heavy crunching: updating status, etc...
• finally, you'll probably have some thread to rule them all (not a ring, a thread), which will be in charge of queuing and dispatching events

It's not much different from the Model-View-Controller model when you think about it, you just add some other components to for input/output

Typically, this runs like this:

• User clicks on mouse, the mouse-listener thread generates an event (MouseClicked at such position)
• The Controller thread receives the event and send it to a "Model" thread, which will update the state of the game (start an action, etc...) if it's a long action, it would be better if it were sent to a dedicated thread (that's where the idea of pool of threads kicks in)
• The View thread is in charge of displays, and periodically changes the buffer to be displayed, it acts independently from the computations being run in the background, though you'll need some synchronization (locks) if you wish it to see a consistent state and not a partially updated state

I would add that's it's extremely complicated to get right (and there are several ways). If you add too many threads you'll just have the machine crumble under your feet, there are possibilites of deadlock, livelock, starvation etc...

If you wish to accomplish something soon, get a framework: Ogre is a good open source graphics library for example. There are resources on game programming on SO otherwise.