>If you are still running out of CPU time, you should try to
>schedule the jobs. E.g. you could call some subroutines only in
>odd and other only in even frames. This is what I'm doing
>(though a bit more complicated) in Thrust too. ;-)
Often a good option, depending upon particulars. For example, you often don't really need to do all collision detections every frame (unless things are moving REALLY quickly and/or objects are REALLY small). If you're flickering any sprites you certainly don't need to be moving them every frame...
In Tsunami, only half the shots (players and enemies - there can be a lot of them) are drawn/moved/collision detected every frame (odd numbered shots are handled on odd numbered frames, even numbered shots on even frames...)
In BIG DIG the sequence of events when you remove a set of blocks goes something like:
Frame: Find all same coloured blocks joined to that one & eliminate those joined blocks
Frame: Check for a set of blocks which need to start falling and mark them as such, if there are no blocks to fall skip ahead to make player fall
Frame: Check for a set of blocks which need to start falling and mark them as such (Repeat this frame until no more sets left to mark - Couple frames usually)
Frame: Make blocks fall (Repeat until nothing left to fall)
Frame: Make player fall (if needed) & scroll screen (if needed)
Frame: Continue normally
Which is why "gameplay" is so "start and stop" (This will improve now that I know to put code in the Overscan and results from the CPU intensive colour-matching routines which are essentially "travelling salesman" problems except no stack=no subroutines=no recursion (though even with recursion, I don't think those routines would really be all that much faster))
Chris..
----------------------------------------------------------------------------------------------
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
