Re: Mode 3 Scrolling Game Engine Demo (WIP)
Posted: Tue Jan 24, 2023 4:12 am
I tried adding back my ram time estimation system to see if I can blit the unicorn late in the process, just before we run out of RAM tiles, and it worked most of the time, except when other entities overlapped and didn't need any more ram tiles to render, then the z-order was wrong.
It used very little CPU, but it wasn't perfect, so I just went whole hog and copied and pasted the BlitSprite() function into my code and added a boolean variable "doblit" that only calls BlitSpritePart() if true.
Now if I want to totally max out my RAM tile usage so the sprite flickering doesn't happen until I truly run out of RAM tiles, but still be able to perfectly control the Z-order of my main character's 2x2, 3x2, or 1x3 megasprite, I can just call MyBlitSprite() with "doblit" set to false to reserve RAM tiles up front without doing any unnecessary blitting. Then I can call the normal BlitSprite() function to draw all of my entities, not stopping or limiting it in any way to take full advantage of free overlapping RAM tiles, and finally I can call MyBlitSprite() with "doblit" set to true to render the main character into the reserved RAM tiles with the highest Z-order when I want to.
That meets all of my goals:
And because I can't help myself... The only thing that might make this better is if the RAM tile allocation wasn't sequential so if sprite flickering does need to happen, it doesn't always happen on entire 8x8 sprites at once, it might only be 1/2 of a sprite if it overlapped 2 RAM tiles, or 1/4 of a sprite if it was overlapping 4 RAM tiles. From what I've seen with my frame-by-frame analysis so far I think flickering just a few pixels of a distributed number of sprites would look way better than losing an entire 8x8 sprite every 1/60th of a second. And it could be combined with the array swizzling technique that I already use to distribute the flicker across all entities. We shall see!
It used very little CPU, but it wasn't perfect, so I just went whole hog and copied and pasted the BlitSprite() function into my code and added a boolean variable "doblit" that only calls BlitSpritePart() if true.
Now if I want to totally max out my RAM tile usage so the sprite flickering doesn't happen until I truly run out of RAM tiles, but still be able to perfectly control the Z-order of my main character's 2x2, 3x2, or 1x3 megasprite, I can just call MyBlitSprite() with "doblit" set to false to reserve RAM tiles up front without doing any unnecessary blitting. Then I can call the normal BlitSprite() function to draw all of my entities, not stopping or limiting it in any way to take full advantage of free overlapping RAM tiles, and finally I can call MyBlitSprite() with "doblit" set to true to render the main character into the reserved RAM tiles with the highest Z-order when I want to.
That meets all of my goals:
- Every 8x8 sprite that the main character is composed of must be drawn every frame without flickering
- Every other visible entity should be blitted without regard for RAM tile usage, so overlapping sprites can happen "for free"
- Sprite flickering should cost close to nothing, and only happen when absolutely necessary
- I should have perfect and absolute control of the Z-order of the main character, without wasting any additional CPU
And because I can't help myself... The only thing that might make this better is if the RAM tile allocation wasn't sequential so if sprite flickering does need to happen, it doesn't always happen on entire 8x8 sprites at once, it might only be 1/2 of a sprite if it overlapped 2 RAM tiles, or 1/4 of a sprite if it was overlapping 4 RAM tiles. From what I've seen with my frame-by-frame analysis so far I think flickering just a few pixels of a distributed number of sprites would look way better than losing an entire 8x8 sprite every 1/60th of a second. And it could be combined with the array swizzling technique that I already use to distribute the flicker across all entities. We shall see!