What would we name a combined displayclearbuffer?

[joshgoebel]

We need to add this for performant games... we lose a lot of time with SPI and one way to get it back is to do the clear for the next frame while we paint the current frame to the hardware. That gives us almost 1% CPU performance back, or more time to sleep and save power.

I'm just not sure what to call it.

displayClearBuffer() displayAndClear() paintAndClear()

Thoughts?

[joshgoebel]

We have about 10-15,000 process cycles we're wasting doing nothing while the slow SPI does it's thing... if we can think of any other housekeeping that can be done incrementally during screen painting we could maybe shove it in here. It just has to be doable in tiny chunks of time.

[joshgoebel]

That's for EACH and every screen refresh... At 60 FPS we lose like almost 1Mhz of our 16Mhz just WAITING on the screen, not even doing anything. :-) I think I just figured out where to hide the greyscale code if we ever got 2 bit color working. :-)

[shogerr]

displayFast()? I know we talked about paint as a way to express drawing to the screen, to avoid some issues. So if we move to that, then paintFast() seems appropriate as well.

[MLXXXp]

displayThenClear()

Assuming it will produce the same result as:

arduboy.display();
arduboy.clear();

[ghost]

I would like to test it on Shadow Runner using arduboy.cpuLoad() to see the difference.

[joshgoebel]

displayThenClear()

I like it. Not 100% clear regarding what is happening, but effectively true as far as the results.

Actually in order to understand it it really needs to be displayAndClear()... the other way isn't clear and makes you wonder why we're creating one big function that just runs one after the other.

[joshgoebel]

I would like to test it on Shadow Runner using arduboy.cpuLoad() to see the difference.

You might not be able to. cpuLoad math is all done in ms... the precision isn't necessarily high enough to detect a 1% improvement. You'd have to measure microseconds before and after. That's what I've used for accurate measurement in the past. cpuLoad would be better done in microseconds too but that would take up extra RAM and flash for something not helpful to most users.

[joshgoebel]

cpuLoad was always intended as more of a high level estimation tool, not to be used for precision measurements of differences between algorithms. It will tell you if you're in the right ballpark, but not if one thing is 2% faster than another.

[MLXXXp]

Actually in order to understand it it really needs to be displayAndClear()

This is an API function. The user doesn't have to know what's going on under the covers. They want to know the result. displayAndClear() is just a little (yes, very little) less clear as to whether the clear may happen before the display.

the other way isn't clear and makes you wonder why we're creating one big function that just runs one after the other.

This is easily solved by documentation: "displayThenClear() does the equivalent of calling display() followed immediately by clear() but is faster and creates slightly less code. If you want to clear the buffer immediately after displaying it, then you can use this function instead of the other two."

When I see a function that does the work of two or more other functions, (like rectangle() instead of 4 _line()_s), I assume the combined function makes things easier or more efficient. I'm more likely to wonder why there are also two separate functions instead of only the combined one. As in the case of displayThenClear(), it's usually because there are times when the functions that have been combined need to be executed individually at different places in the code.

I could ask "If we have displayThenClear() is there a need for clear()?". You could answer "It's so you can clear the buffer before building the intro or first frame, etc., when the sketch first starts". I might then think "Then why not have a clearThenDisplay() or just clearDisplay()?, and eliminate clear()". The answer might be "Because in your game loop you may want to display(); then make a decision on what to do next; then start with clear() if you're building a new level; else just erase, move and redraw a sprite if you're remaining on the same level; then loop back to display() to show the result".