Partial Buffer Graphics Demo
potatohead
Posts: 10,254
Had reason to revisit this basic, but fun stuff today. I will post up some video links, and or screenies tomorrow. Setup on a real TV today, just to evaluate what flickers and what does not. Capture cards, depending on what one does with them, hide flicker, as do some of the better LCD / Plasma displays. HD sets have a lot of signal processing. SD sets may have this, though many do not, and in particular, the discrete LCD modules people use generally don't.
Two bits of code here.
One is a 1/8 screen buffer, and the other is a 1/4 screen buffer. That means they consume the memory associated with the Parallax graphics display, minus the portion of the double buffer not used. This savings can be considerable, over 10K in some cases.
Or... One can simply run a higher resolution screen, say 384x192, filling what is usually the double buffered 256x192, with more pixels, and a quarter screen buffer. I'll post a example of that up later, after I add some other techniques to it. I want to show use of the color re-direction, which hasn't seen much here, and it's quite useful as another form of display buffering, in that things can be drawn to the live graphics screen, then "popped" into view rather quickly, simply by using color / tile control. On the higher resolution screen, that might make sense, particularly in the highest resolution, no off screen buffer scenario. Need to author some examples that are not the graphics demo though. Probably will put those here too.
I've gone through and optimized things a bit, from the last examples in my blog, also applying the color / tile technique in what I think is a useful way. Those methods, as with my first efforts to build on graphics_demo.spin, can be inserted into your graphics_demo.spin program with few to no changes, depending on what you've done with graphics_demo.spin. These demonstrate the tile color / palette options, replicating and in some cases, adding to the color presented in the original.
These are Demo Board standard @ 80Mhz, as they are built off the standard code that ships with the Prop Tool. Any changes for your setup apply to these as they would the standard code. Compile 'n run with Prop Tool or BST on the Demo Board, no changes or input required.
There is pretty much no flicker on these. There is some screen tearing of the image, and the occasional visible "sweep" motion, depending on draw speed. The graphics demo is actually instructive here as it's draw speed varies with primitive size on screen, and it's got several challenges for buffering. Be sure and compare the overall effect with the demo at it's minimal, fast, initial state, and it's near final, much slower end state. Small tweaks in when and how much motion occur made a big difference over the first pass, which was the demo slammed into the partial buffer technique, with no adjustments really.
I call this "ripple draw", because it can exhibit that effect at the extreme conditions. The basic idea here is that only a small portion of the entire screen is drawn at any one time. With the graphics demo, it's pretty easy to just execute it to draw one frame, allowing the Parallax graphics library to clip objects into the buffer boundary. The off screen buffer is 64 pixels x 192 pixels, and gr.setup is called just prior to the demo code, so that the drawing for a particular strip of the screen occurs in that same off screen space, clipped, ready to be dropped onto the screen with gr.copy, followed by a gr.clear for the buffer to be used again and again, round robin style.
I chose the gr.copy method, because it is fast enough, and it's really easy. One could swap the buffer region for the screen region too by changing tile addresses on the screen to point to the finished image in the buffer, essentially transforming the region of the screen memory no longer visible into a new buffer to be cleared and drawn fresh. That can move the clear screen operation off screen entirely. The graphics demo did not require this, so I didn't do it this time around. That idea would require managing the memory itself round robin style with pointers to which region is actually "the buffer" at any one time.
In any case, the trade off is overall frame rate. If every single element of the screen needs to be accurate, your max possible frame rate is 1/60th second / 4 buffers = 15 FPS NTSC. On the other hand, if that's not so important, and you can live with some image integrity downgrade, the frame rate can go up considerably. If partial screen updates are needed, those only can be double buffered in various ways, allowing for a full frame rate, with no other issues. That's some of what I'll put in the higher resolution one, once I think up some easy examples. It's possible to mix 'n match these things too.
At a 1/8th buffer, the overall frame rate drops to 7 FPS, requiring more motion compromises to get a similar effect. Run the two on a real display to see the differences. Still useful, but on a smaller sub-set of displays. No flicker though
These show balanced motion, giving the illusion of the full double buffered motion, with many little trade-offs here and there. At a glance, it's difficult to tell. Dropping it here for those who may be interested in this kind of thing.
Not so useful for games, though some titles could use it. A flight sim, strategy type game, or space 3D view / vector style art presentation would work very well. Instrumentation is the main target, where flicker is just not ok, but other artifacts may well be, and memory use is important.
Two bits of code here.
One is a 1/8 screen buffer, and the other is a 1/4 screen buffer. That means they consume the memory associated with the Parallax graphics display, minus the portion of the double buffer not used. This savings can be considerable, over 10K in some cases.
Or... One can simply run a higher resolution screen, say 384x192, filling what is usually the double buffered 256x192, with more pixels, and a quarter screen buffer. I'll post a example of that up later, after I add some other techniques to it. I want to show use of the color re-direction, which hasn't seen much here, and it's quite useful as another form of display buffering, in that things can be drawn to the live graphics screen, then "popped" into view rather quickly, simply by using color / tile control. On the higher resolution screen, that might make sense, particularly in the highest resolution, no off screen buffer scenario. Need to author some examples that are not the graphics demo though. Probably will put those here too.
I've gone through and optimized things a bit, from the last examples in my blog, also applying the color / tile technique in what I think is a useful way. Those methods, as with my first efforts to build on graphics_demo.spin, can be inserted into your graphics_demo.spin program with few to no changes, depending on what you've done with graphics_demo.spin. These demonstrate the tile color / palette options, replicating and in some cases, adding to the color presented in the original.
These are Demo Board standard @ 80Mhz, as they are built off the standard code that ships with the Prop Tool. Any changes for your setup apply to these as they would the standard code. Compile 'n run with Prop Tool or BST on the Demo Board, no changes or input required.
There is pretty much no flicker on these. There is some screen tearing of the image, and the occasional visible "sweep" motion, depending on draw speed. The graphics demo is actually instructive here as it's draw speed varies with primitive size on screen, and it's got several challenges for buffering. Be sure and compare the overall effect with the demo at it's minimal, fast, initial state, and it's near final, much slower end state. Small tweaks in when and how much motion occur made a big difference over the first pass, which was the demo slammed into the partial buffer technique, with no adjustments really.
I call this "ripple draw", because it can exhibit that effect at the extreme conditions. The basic idea here is that only a small portion of the entire screen is drawn at any one time. With the graphics demo, it's pretty easy to just execute it to draw one frame, allowing the Parallax graphics library to clip objects into the buffer boundary. The off screen buffer is 64 pixels x 192 pixels, and gr.setup is called just prior to the demo code, so that the drawing for a particular strip of the screen occurs in that same off screen space, clipped, ready to be dropped onto the screen with gr.copy, followed by a gr.clear for the buffer to be used again and again, round robin style.
I chose the gr.copy method, because it is fast enough, and it's really easy. One could swap the buffer region for the screen region too by changing tile addresses on the screen to point to the finished image in the buffer, essentially transforming the region of the screen memory no longer visible into a new buffer to be cleared and drawn fresh. That can move the clear screen operation off screen entirely. The graphics demo did not require this, so I didn't do it this time around. That idea would require managing the memory itself round robin style with pointers to which region is actually "the buffer" at any one time.
In any case, the trade off is overall frame rate. If every single element of the screen needs to be accurate, your max possible frame rate is 1/60th second / 4 buffers = 15 FPS NTSC. On the other hand, if that's not so important, and you can live with some image integrity downgrade, the frame rate can go up considerably. If partial screen updates are needed, those only can be double buffered in various ways, allowing for a full frame rate, with no other issues. That's some of what I'll put in the higher resolution one, once I think up some easy examples. It's possible to mix 'n match these things too.
At a 1/8th buffer, the overall frame rate drops to 7 FPS, requiring more motion compromises to get a similar effect. Run the two on a real display to see the differences. Still useful, but on a smaller sub-set of displays. No flicker though
These show balanced motion, giving the illusion of the full double buffered motion, with many little trade-offs here and there. At a glance, it's difficult to tell. Dropping it here for those who may be interested in this kind of thing.
Not so useful for games, though some titles could use it. A flight sim, strategy type game, or space 3D view / vector style art presentation would work very well. Instrumentation is the main target, where flicker is just not ok, but other artifacts may well be, and memory use is important.
