Author: FloppusMaximus
Posted: 05 Mar 2013 12:22:57 am (GMT -5)
A few possible answers:
- Be clever and figure out a way to redraw the sprite and background at the same time. You might get tearing but you won't get flicker.
- Double buffering using partial images. (This is theoretical, I haven't heard if anybody's tested partial images yet or how well they work.)
For example, if you need to be able to atomically update a 32-pixel-wide region, you could limit the program to a 288x240 area of the LCD, giving yourself an extra 32 columns' worth of GRAM to play with.
Code:
Generalizing this, you could update the whole screen in rolling fashion, or you could shuffle the "extra" columns around whenever you need to update a different part of the screen. There are lots of possibilities.
(Of course there's the possibility of flickering while you're changing the LCD registers, but that shouldn't take more than a few tens of microseconds.)
- Poor man's double buffering using R60. I suggested this to KermM at one point, I don't know if anybody's tried it yet. As he said earlier, when you hide part of the screen using R60, the image that was previously displayed *stays there*, and fades to white *slowly* over the course of a few seconds. I would guess that if you set NL to 0, draw something to the hidden part of GRAM, then set NL back to 27h, all in the space of a millisecond or so, the flicker would be imperceptible.
Posted: 05 Mar 2013 12:22:57 am (GMT -5)
A few possible answers:
- Be clever and figure out a way to redraw the sprite and background at the same time. You might get tearing but you won't get flicker.
- Double buffering using partial images. (This is theoretical, I haven't heard if anybody's tested partial images yet or how well they work.)
For example, if you need to be able to atomically update a 32-pixel-wide region, you could limit the program to a 288x240 area of the LCD, giving yourself an extra 32 columns' worth of GRAM to play with.
Code:
(partial image 0) (partial image 1)
DISPLAY |###|==================|-------|----------------|###|
. . . . .
. . . . .
. . . . .
GRAM |==================|.......|-------|----------------|
| | | | |
| left part of | X | Y | right part |
| background | | | of background |
| | | | |
|==================|.......|-------|----------------|
|| draw stuff to "X",
\/ then change R82-R84
GRAM |==================|=======|.......|----------------|
| | | | |
| left part of | X | Y | right part |
| background | | | of background |
| | | | |
|==================|=======|.......|----------------|
. . . . .
. . . . .
. . . . .
DISPLAY |###|==================|=======|----------------|###|
\
unused area (white or possibly black)
Generalizing this, you could update the whole screen in rolling fashion, or you could shuffle the "extra" columns around whenever you need to update a different part of the screen. There are lots of possibilities.
(Of course there's the possibility of flickering while you're changing the LCD registers, but that shouldn't take more than a few tens of microseconds.)
- Poor man's double buffering using R60. I suggested this to KermM at one point, I don't know if anybody's tried it yet. As he said earlier, when you hide part of the screen using R60, the image that was previously displayed *stays there*, and fades to white *slowly* over the course of a few seconds. I would guess that if you set NL to 0, draw something to the hidden part of GRAM, then set NL back to 27h, all in the space of a millisecond or so, the flicker would be imperceptible.