Partial Buffer Graphics Demo
potatohead
Posts: 10,261
Like the commented version found in my signature, and the single buffered version posted earlier, this is a version of graphics_demo.spin, that is intended to demonstrate the use of a partial off screen buffer to save RAM while producing a display with many graphical elements.
You run this like you would graphics_demo.spin, using the Parallax TV driver and graphics.spin library COG.
The single buffer draw methods do have some limitations, most notably a "sweeping" motion where there is a lot of screen changes, and some potential for flicker on objects that take longer than a blanking period to draw. In that version, some minor flicker could be seen on the "parallax" text at lower right, and the incrementing digit took too long to draw at a reasonable rate.
This version increases the changes possible on the display considerably, eliminating all flicker, leaving only some tearing artifacts where objects change shape across screen strips. The less the motion, the less this effect is seen. Objects contained within a strip will not display these at all, rendering flicker free otherwise. Some display planning can really make good use of this technique.
My last post didn't explain this all that well. I call this "ripple draw", because the image to be rendered to the screen is drawn repeatedly to either the screen, with clipping used to contain it to a small area, or a small off screen buffer used with clipping to render it all before displaying it.
Compute is more intensive. In the original graphics_demo.spin, the demo objects were drawn once per frame, with each frame double_buffered, so that they could be displayed as quickly as possible to the user.
In this code, the demo is drawn once PER STRIP, then the strip is copied to the screen quickly. It turns out the gr.copy is plenty quick enough to be used without display synchronization. Had it not been quick enough, it would have been necessary to read the display raster state, then copy while the TV beam is either blank, or not scanning the copy area.
In the screen captures I've attached, you can see in the lines where one is drawn to the next position, while part of it is at the last screen position. This is tearing, and it will occur based on how much a object moved, and whether or not that movement crosses the strips. That is the trade-off for screen flicker, and is necessary in a small RAM scenario.
There are a lot of displays, and even games possible with this display method, which only requires enough HUB RAM for the bitmap, and $600 of RAM for the off screen buffer. Smaller buffer sizes can be used with various trade-offs in terms of overall frame rate possible, and display tearing seen. Some sample loops are included that utilize a smaller buffer $300, to show the extreme of 16 strips, compared to the optimal 8 strips shown by default, and frame rate changes that insure tearing will be seen.
A tearing example is highlighted in the capture below.
The minimum, artifact free display rate is 60hz, or 50hz PAL, divided by the number of strips in the display. In the case of 8, this is 7.5 frames per second. I have the graphics digits running at that speed in the default draw loop, and the moving objects moving at double speed, relative to that.
Try incrementing frame mid loop to see the impact exceeding that rate has. The overall perception of going faster will be there, but the screen image will suffer losses because not all the display strips will see all the changes. YMMV.
If you have a tight memory situation, this may be helpful.
You run this like you would graphics_demo.spin, using the Parallax TV driver and graphics.spin library COG.
The single buffer draw methods do have some limitations, most notably a "sweeping" motion where there is a lot of screen changes, and some potential for flicker on objects that take longer than a blanking period to draw. In that version, some minor flicker could be seen on the "parallax" text at lower right, and the incrementing digit took too long to draw at a reasonable rate.
This version increases the changes possible on the display considerably, eliminating all flicker, leaving only some tearing artifacts where objects change shape across screen strips. The less the motion, the less this effect is seen. Objects contained within a strip will not display these at all, rendering flicker free otherwise. Some display planning can really make good use of this technique.
My last post didn't explain this all that well. I call this "ripple draw", because the image to be rendered to the screen is drawn repeatedly to either the screen, with clipping used to contain it to a small area, or a small off screen buffer used with clipping to render it all before displaying it.
Compute is more intensive. In the original graphics_demo.spin, the demo objects were drawn once per frame, with each frame double_buffered, so that they could be displayed as quickly as possible to the user.
In this code, the demo is drawn once PER STRIP, then the strip is copied to the screen quickly. It turns out the gr.copy is plenty quick enough to be used without display synchronization. Had it not been quick enough, it would have been necessary to read the display raster state, then copy while the TV beam is either blank, or not scanning the copy area.
In the screen captures I've attached, you can see in the lines where one is drawn to the next position, while part of it is at the last screen position. This is tearing, and it will occur based on how much a object moved, and whether or not that movement crosses the strips. That is the trade-off for screen flicker, and is necessary in a small RAM scenario.
There are a lot of displays, and even games possible with this display method, which only requires enough HUB RAM for the bitmap, and $600 of RAM for the off screen buffer. Smaller buffer sizes can be used with various trade-offs in terms of overall frame rate possible, and display tearing seen. Some sample loops are included that utilize a smaller buffer $300, to show the extreme of 16 strips, compared to the optimal 8 strips shown by default, and frame rate changes that insure tearing will be seen.
A tearing example is highlighted in the capture below.
The minimum, artifact free display rate is 60hz, or 50hz PAL, divided by the number of strips in the display. In the case of 8, this is 7.5 frames per second. I have the graphics digits running at that speed in the default draw loop, and the moving objects moving at double speed, relative to that.
Try incrementing frame mid loop to see the impact exceeding that rate has. The overall perception of going faster will be there, but the screen image will suffer losses because not all the display strips will see all the changes. YMMV.
If you have a tight memory situation, this may be helpful.
720 x 576 - 39K