Re: [stella] Object handler organisation

Subject: Re: [stella] Object handler organisation
From: Christopher Tumber <christophertumber@xxxxxxxxxx>
Date: Thu, 07 Nov 2002 12:42:26 -0500
>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))


Archives (includes files) at
Unsub & more at

Current Thread