Thought I'd share a little trick.

wjsteele

I don't have any code to demonstrate this, but while using Ray's 4.3" LCD on his Prop System Board, I ran into memory issues because of the requirement for double buffering.

Or so I thought. What I found was that if I used gr.quad to draw over the areas that changed, then I can eliminate the gr.clear statement, which erases the entire screen. (gr.clear and redrawing a bunch causes the flicker.)

By doing this in my app, I now have freed up a bunch of memory but still have no screen flicker... all without double buffering.

Also, I noticed that if you are using vector graphics (with no fills,) like in Battlez0wned, you also have no flicker.

Bill

Rayman

good advice... I think Ariba posted drivers for 240x136 (double sized fat pixels) that could allow you to do fullscreen double-buffering...

Just in case you really do need double-buffering...

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
My Prop Info&Apps: ·http://www.rayslogic.com/propeller/propeller.htm

mpark

I suppose the gr.quad trick only works if the changed area is sufficiently small. If the whole screen changes, it'd be the same as gr.clear, right?

How do you keep track of what areas have changed?

Have you actually applied your trick to Battlez0wned?

MagIO2

I remember there was an XOR graphics driver a while back. I tried it out and must have it somewhere.

This will help to avoid flicker without double buffers. The idea is to erase only what needs to be changed by simply drawing it again. So, with the first line(x1,y1,x2,y2,col) you'd draw the line, calling the same again would erase it.

cgracey

Since flicker is caused by erasing and redrawing, if you just draw over an area with the new results, there's no erasure, just replacement, so no flicker. This is easy to do in cell-based graphics, but more tedious in bitmapped graphics.·In many cases, it can be faster than double-buffering, but takes sometimes a little smarter code to realize. In cases where drawings are layered pixel-over-pixel, double-buffering to eliminate flicker is almost required. The SX Tool uses smart redraw to make its debugger interface crisp, since it takes way less time to determine if something needs to be redrawn, than it does to actually redraw it. It's like spending money frugally, except it's time, not money than you are spending.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔


Chip Gracey
Parallax, Inc.

VIRAND

gr.clear can be avoided. Double buffering can be avoided. Someone beat me to the XOR and
backboxing before redraws, but if the redraw is small, no erasure at all is needed,
just copy (overwrite) a different "tile" onto the previous one, possibly from a much smaller buffer.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
I should be typing in Spin now.

wjsteele

Hey MagIO2, I'd be interested is seeing that code if you can find it. I've found a couple edge cases where there is a slight flicker and it would be real cool if I could XOR those areas without doing the entire screen. I'm thinking about writting something like gr.quad that takes the previous quad and only blacks out the non overlapped areas. I tried doing a search but came up empty.· ]

Nevermind, I found it.· It's here: http://obex.parallax.com/objects/310/

Bill

Post Edited (wjsteele) : 2/6/2010 2:50:41 AM GMT