The Graphics.Spin object ... time to have another look

Beau Schwabe

I've been wanting to put something like this together for quite some time, that introduces, or rather re-introduces some graphics re-draw techniques that were used in the early days of computing.

This demo was mainly intended to illustrate that Graphics are possible without using two pages of graphics memory and thus freeing up a large portion of program memory that can be used on valuable code. The caveat is that you must apply more manual or local maintenance to the area of screen you are updating.

There are a couple techniques used here that avoid and minimize the amount of display flicker you get when only using one bitmap display. Notice also that there are several objects used here and room for plenty more.

Enjoy!

JT Cook

Looks good, double buffering with only 32K of RAM is rough. I assume most of the updates are done during the refesh period, but how do you tell the program to update the graphics during refresh (or is it done automatically)?

Beau Schwabe

JT Cook,

The 'trick' is to not update the entire screen at the same time. Only focus on the area that's changing. The flicker of an entire screen is annoying and is what happens if you blank everything immediately before you redraw it. If you only blank small portions of the screen the 'flicker' is less noticible and less annoying. Moving animated graphics with lots of pixels moving around can also be tricky but not impossible with just a single buffer. That's something I will try to implement later, where you can have pseudo double buffering, meaning that you have some memory reserved for double buffering but not for the entire screen. Imagine a screen divided into 3 by 4 tiles... the 'buffer' of memory would then only be for one of those tiles, so right there you have 1/12th of the memory requirement. In your program you write and update the buffer, and then when you copy that buffer to the main display buffer you assign which tile that it goes to. That Example method alone has a 46% reduction in the amount of total required memory for graphics, it just requires a little bit more management but completely within the capabilities of the Propeller.

Phil Pilgrim (PhiPi)

Beau,

I wonder if maybe the least visually jarring technique of all would be to double buffer the even lines, then double buffer the odd lines (interlaced buffering). Your memory savings would only be 25% over full double buffering, but that might be enough for some apps. And with NTSC output, there would be no flicker at all if you could do a half-frame (single-field) update in 16 ms.

-Phil

Beau Schwabe

Phil Pilgrim,

That would work also ... I was thinking in terms of my old ATARI days where memory was limited and expensive. The idea of 'page flipping' or double buffering was relatively new.

I was also thinking in terms of using most of an object that was already in existence rather than re-write one from the ground up to handle the kind of interlacing your talking about... or perhaps it's as simple as changing a +1 to a +2 and alternately providing an EVEN/ODD start reference. I haven't look at it in that detail.

Phil Pilgrim (PhiPi)

You would probably want the even and odd display fields each in their own contiguous memory blocks so you could longmove the buffer to them in one fell swoop. Unfortunately, that would entail modding the TV and VGA objects.

-Phil