Kasumi wrote:What if the screen scrolls right, then scrolls left? Scroll right, some sprites move offscreen due to carry change, scroll left, those sprites should be back on screen. Is that case covered?
tokumaru wrote:What happens when an object that has moved partially off screen and had some of its sprites removed moves back on screen? Does it still trigger the "fast mode" where the existing sprites are moved (causing parts of the object to be missing) or does it know it has to generate the missing sprites again?
I was thinking about the exact same issue, trying to come up with a way that doesn't overly complicate things, but, I think I'll solve it by never allowing the use of the fast drawing replacement routine for objects that are either being clipped by the edge of the screen or that was clipped (or outside) the screen on the previous frame. Too much special logic going on there to account for in the caching mechanism.
I might refine it later to narrow down, since in theory there is nothing wrong with "clipping away" sprites just as long as no sprites need to reappear.
Kasumi wrote:I'm not clear, is this two pages of RAM (one for cache, one for not?) or just one?
I'm just using one page of RAM, it's being shuffled "in place". If I used two pages of RAM I'd have to waste time copying over the values I wanted to reuse, and I'd be spending a lot more memory, so that solution would be subpar.
By cleverly using LDA/STA and LDX/STX in combination we can shuffle around the RAM "in place" without any performance penalties for not having a shadow copy.
Kasumi wrote:Can objects have a variable number of sprites? (Some frames take 12, some take 8)Edit: To ask a more specific question. For the frames that take 8 sprites, are 12 child slots still needed for the object?
Right now I'm just giving 8 sprites to each object, I was really curious on how much CPU time the caching would save me so I cheated a bit on sprite assignment. However, I have plans to change that in favor of just using the sprites it exactly needs that frame, by making a routine that gives out sprites whenever it's called, divided in such a way that my shuffling mechanism is still fast.
Kasumi wrote:Does the halved time include the added time for the actual shuffle? I assume half on average, is your worst case much worse? (Though I guess it wouldn't be.)
Well, my claim was perhaps a bit simplistic. The shuffling adds a static cost, but the caching makes every object cheaper. That means it's actually slower if you only have one object on the scene, but a lot faster if you have eight objects on the scene. The cost per object was more than cut in half, but I eyeballed it a bit since I was just measuring by tinting the screen with colors as the code was executing.
This is a very good kind of tradeoff though, as we don't really care about saving that much CPU when there is only one object on the scene. We want to optimize for the worst case scenario after all.
Kasumi wrote:Sorry for all the questions, but sounds brilliant. If it uses one page of sprite RAM, I'm all in. if it's two pages of sprite RAM, I'm half in.
It's definitely just one page. I have big plans and it's gonna need a lot of spare RAM.