Single buffer graphics_demo.spin example
potatohead
Posts: 10,261
Run the attached program as you would graphics demo.spin. It uses the parallax TV driver in the usual way.
It will display the graphics demo, minus the large digit, on a single buffered screen with almost no flicker.
There are three different examples of how the draw technique can be implemented. One other possible example uses a small, off screen buffer to partially buffer the display. I'll come back and add that in the very near future. Uncomment the various ones to see the trade-offs between number of draw segments, and display change rates. It's also worth looking at what gr.setup can really do in terms of screen manipulation.
With this draw method, only a small portion of the screen is updated. Draw changes are spread out over time to either average the display changes over the display, resulting in some tearing and misalignment of graphical elements, or they are delayed until a entire screen is drawn, limiting display changes to a smaller number of frames per second, compared to what a double buffer screen can do.
I would normally attach a capture, but a small movie is required to see the effect. This technique is useful for moderate complexity displays where the number of changes isn't too severe. The graphics demo pushes that boundary a bit, still useful, but not optimal. It's also worth it to change the colors to a dark, or black background and run through the various examples again. The "sweeping" effect can be minimized with a black background, or by clearing to a color that is the background.
This technique does not require display sync with drawing, though it can be significantly enhanced by doing that, when the amount to be drawn fits into a blanking period. The graphics demo does not, and would require a small off screen buffer to get the same impact. I'll add that, like I mentioned earlier.
It will display the graphics demo, minus the large digit, on a single buffered screen with almost no flicker.
There are three different examples of how the draw technique can be implemented. One other possible example uses a small, off screen buffer to partially buffer the display. I'll come back and add that in the very near future. Uncomment the various ones to see the trade-offs between number of draw segments, and display change rates. It's also worth looking at what gr.setup can really do in terms of screen manipulation.
With this draw method, only a small portion of the screen is updated. Draw changes are spread out over time to either average the display changes over the display, resulting in some tearing and misalignment of graphical elements, or they are delayed until a entire screen is drawn, limiting display changes to a smaller number of frames per second, compared to what a double buffer screen can do.
I would normally attach a capture, but a small movie is required to see the effect. This technique is useful for moderate complexity displays where the number of changes isn't too severe. The graphics demo pushes that boundary a bit, still useful, but not optimal. It's also worth it to change the colors to a dark, or black background and run through the various examples again. The "sweeping" effect can be minimized with a black background, or by clearing to a color that is the background.
This technique does not require display sync with drawing, though it can be significantly enhanced by doing that, when the amount to be drawn fits into a blanking period. The graphics demo does not, and would require a small off screen buffer to get the same impact. I'll add that, like I mentioned earlier.
Comments
As I wrote above, this is really the commented_graphics_demo.spin, with the single buffer draw technique implemented. There are three draw loops, where you can just uncomment the one you are interested in seeing happen.
The default one does the screen in 8 strips, with image changes staggered across the draw cycle. It's a trade off between image coherence (tearing) and overall display speed. 4 strips could be used for a faster screen, but it's harder to hide the tearing. How well that works, depends on your display, and the image draw speed. On this demo, 4 strips was clunky, so I didn't do it.
The other two demonstrate the two extremes. One does all the strips, only changing the image once the screen is drawn. Looks nice, but can't do fast motion. (60/16) = frame rate.
The other makes changes constantly, showing how the tearing looks in the extreme case.
No off screen buffer is used for a best case memory profile.
If there is memory for a small, off screen buffer, it's possible to significantly improve the "sweeping" effect seen on these examples. Draw a strip off screen, then write it to the visible screen quickly. Ideally a small PASM loop would do this, but honestly, SPIN can do very nicely.