If I have a (complex) operation that takes a long time for it to finish, for instance, a couple of seconds, my frame rate drops far below the acceptable. How could I still implement it while it is not messing up my frame rate?
|
Without using threads, here are two ways.
Call cLogic::Update(), check if its member updating is TRUE, if so return or else turn it on. Do the logic. Before exiting the function, turn off updating. In the state machine you do one thing at each frame. Leaving the state as it is afterwards. So it catch on there where you left off. A possibility can be, make a variable that catches the time, do some iterations until 0.1 seconds has passed and leave, the states stay as they are. Not familiar with cocos2-iphone myself I produced a pseudo-code-like example based on c++. As you are asking the principle, I think that would be okay. It surely can use optimizations.
|
||||
|
|
|
Create separate threads for drawing and logic, if you want improved performance. But, you can have If you were a bit more specific and told us what problems are you having exactly, it would be easier to answer the question. |
|||||||
|
|
Hrm... My first guess would be multithreading. For example, if you had your logic and render in the main loop, if logic takes a long time, you don't get anything rendered till it is done. With multiple threads, the render can be independant of the logic, and so evedn if the logic is bogged down, stuff still gets rendered, etc. As per how to calculate it every 1/2 seconds, I am sure whatever libraries you are using contain the simple contraption of some sort of timing devices/timers, etc. Or, in the case the logic is threaded by itself, a sleep might also suffice. The problem of ensuring the logic is completed by the time it must next be calculated might be tricky, depending on specifically what you are doing. You could: optimize the logic calculations, thread individual part of the logic (though I haven't actually used threads in a real application, so how to seperate but coordinate the logic, I don't know much on). Alternatively, perhaps you can either set a minimum calculation time (say 0.5 seconds) and give it as much time as it needs, or somehow otherwise coordinate the application to the time it takes. |
|||
|
|
|
It is possible to separate the render thread from the update thread, but it is quiet difficult to make. You'll need a triple-buffer of the render state. For an explanation of the problem and solution check out: http://blog.slapware.eu/game-engine/programming/multithreaded-renderloop-part1/ http://blog.slapware.eu/game-engine/programming/multithreaded-renderloop-part2/ http://blog.slapware.eu/game-engine/programming/multithreaded-renderloop-part3/ http://blog.slapware.eu/game-engine/programming/multithreaded-renderloop-part4/ The site contains both source + binary distribution if you're interested. |
|||||
|