Partial Screen Updates

I am currently using Mode15 but performance is not so great.

The game does not need to be 188 pixels high so I was thinking of creating an artistic banner top and bottom of (say) 24px thus leaving a window of 220 x 140px.

I can render the top and bottom banners once at the start of the game play and render only the ‘letterbox’ in the middle for the remainder. I may render the top and bottom occasionally (say if the score updates) but this would be every x frames, not every frame.

So how do I go about doing that? I can see in the API that the code updating the screen is (or appears to be to me) contained in the assembly language routines found here

There is some interesting code / comment at line 8:

This sort of suggests that maybe you could call this function with a start and end row. Is that what its implying? If so, how do I do that?

The function takes a palette and a screenbuffer, not a beginning and end row. It always writes out the entire buffer. Skipping a few rows isn’t going to give a significant speedup. Instead of doing a full clear, you could enable persistence in My_settings.h and only clear the game area, so as not to have to blit the banners on every frame.

OK … I am sort of thinking about the Arduboy where the pushing of the buffer out to the screen is a significant portion of each frame. Is the process on the Pokitto faster (relatively speaking)? Is the clearing of the buffer a particularly slow part?

I have thought of enabling persistence but in my model I was planning on just rendering the visible portion of the screen and it would overlap the boundary of my ‘letterbox’ in places but I was hoping the rendering would simply crop these parts out. I could attempt to crop them as I am rendering but this might be costly in itself - especially as I would be cropping graphics.

Thanks for the advice @FManga ! Never mind, I was just looking for cheap ways to improve the performance.

I don’t remember that mode specifically, but if a game were to draw nothing and simply flush the framebuffer in an otherwise empty loop, it runs at about 200 fps or about 5 ms per frame.
If your game is running slow (say 20fps or 50 ms, to make the math simple) that means flushing only half of the framebuffer would get you only 1 more fps (47.5ms is being taken up by something else).
Clearing the buffer is free if persistence is disabled, but you might gain something from not copying banner bitmaps onto the framebuffer.

I wonder if the library has a ‘clip rect’ facility?

If not, I wonder how much effort it would be to make one.
Ignoring writes to pixels inside your ‘banner’ zone seems be a reasonable way to have persistence and a banner. (If the cost of checking doesn’t burn more time than it saves.)