double-buffering and frame flyback

[ervin]

Hi everyone.

I'm using double-buffering in Chunky Pixel Curator, and I'm waiting for frame flyback to prevent little flickers between buffer swaps.
Unfortunately, using frame flyback makes the program a little slower.
(It's noticeably faster without flyback, but of course I get little flickers all over the screen).

Is it possible to have flicker-free double-buffering without waiting for frame flyback?

A quick explanation:
I swap buffers, then I clear the 1st raster (and every 4th raster thereafter) on the back-buffer.
All sprites etc. are drawn to those cleared lines, and then those lines are copied 3 times to create chunky 4-pixel high lines.
What I'm finding is that without frame flyback, the clearing of every 4th raster is visible sometimes, as if the buffer swap doesn't quite complete in time, before the clearing begins.

[arnoldemu]

I'm using double-buffering in Chunky Pixel Curator, and I'm waiting for frame flyback to prevent little flickers between buffer swaps.
Unfortunately, using frame flyback makes the program a little slower.
(It's noticeably faster without flyback, but of course I get little flickers all over the screen).

Is it possible to have flicker-free double-buffering without waiting for frame flyback?

Use 3 buffers.

One is visible, two for drawing.

When you are done with drawing the first, start drawing directly on the next.
You need to remember to keep track of which buffer to show next.

The hardware reads the screen start address, with normal parameters, once every 50th of a second.
The monitor/television also displays at 50 frames per second.

You can't change that part.

But what you can do, is avoid the wait until the next frame by using another buffer and start using that immediately, but you then loose another 16KB for another screen.

Of course to make this work you then need to use an interrupt to show the screen you just made and to keep track of which in the list is available. If your code takes too long you still need to wait until a buffer is ready to be used.

Alternatively, you can not wait for frame flyback and draw to the same screen immediately, but you will get tearing and flicker.

EDIT: The buffer swap is effectively instant, just make sure you program the new crtc start address before the end of the frame.

[ervin]

That's brilliant information. Thanks for all of that.

You've given me an idea...

[TotO]

Triple buffering was basicaly used on PC DOS, 20 years ago.
I remember that was more accurate than double buffering when enabled.
Curious to see the result on CPC!

[Overflow]

Is it possible to have flicker-free double-buffering without waiting for frame flyback?

Hi!
I faced something similar, and the fix was so obvious that I had a laugh at myself.
Depending on your case, you may find my case useful.
I did at one loop:
1) empty buffer
2) calculate objects
3) draw objects
Well, since "calculate objects" takes much time (more than 1 frame), I switched to:
1) calculate objects
2) empty buffer
3) draw objects
With this, no need to wait for frame flyback. Is this helpful in your case?
Oliverflow

[ervin]

Thanks Overflow, yes that is indeed very helpful!
I'll give it a go!

[arnoldemu]

Yes you can re-arrange your code to maximise the time.

The critical path is the drawing of the sprites and graphics to the hidden screen. At this point you can indicate a new buffer is wanted, but you don't need to wait until it's done it, you may continue with ai and other updates to "soak" up the remaining time in the frame.


e.g.

draw stuff
indicate swap ready
do more stuff


in frame interrupt:
swap requested? - do swap
do other stuff.



i.e. exactly as overflow says.

[AMSDOS]

I made a little Double-Buffering example based around Kevin's "Hardware double buffering using the Firmware" example, but what I done was:
* change the visible screen
* draw an image to screen (using my own slow plotting pixel generator)
* use SCR SET BASE (&BC08) to display the image.


The effect works without any flicker, so no need to Frame Flyback, though it's a little on the slow side - probably due to a combination of using BASIC as well as my routine to get the image to screen, though the wipe on/wipe off effect was so hideous I was curious to give this a try.    It probably won't be much use to you though.


In my Hisoft Pascal 4T thread, @HAL 6128 made an example of Double Buffering using BASIC, along with a few other tricks which I'd need to look up. The original example only worked in BASIC 1.1, but I made one to work in BASIC 1.0, one of the differences was the Firmware Address varied from those computers & TAG/TAGOFF works a little bit differently on a 464, but the result worked very well.

[AMSDOS]

I was wondering, while this thread is on the subject of Double-Buffering, I'm assuming Double Buffering is only effective when 2x 16kb screens are used?

[opqa]

Not necessarily, you could use two 8KB screens within the same 16KB bank.

[AMSDOS]

Not necessarily, you could use two 8KB screens within the same 16KB bank.

Just wondered if this "Hardware Double Buffering Using the Firmware" could be modified to work on the MODE 3 Screen?

[opqa]

What do you mean by MODE 3 Screen?

[TotO]

MODE 3 is a hardware drawback when you set the 2bit to select the screen mode. (00, 01, 10 and 11)
Its side effect is to display the MODE 0 resolution with the MODE 1 colours, but not save memory at all.

[remax]

MODE 3 is a hardware drawback when you set the 2bit to select the screen mode. (00, 01, 10 and 11)
Its side effect is to display the MODE 0 resolution with the MODE 1 colours, but not save memory at all.

There have been a topic on this here where people tried to find something useful about it but i think without any valuable result...

Anyway, BEST MODE EVA! (no wonder why Amstrad hid it)

[opqa]

Ok, I knew that but wanted to be sure we were talking about the same.

In that case, as Toto says you are not going to save any byte by using mode 3, you are going to save bits, which you can use to store the second screen. But you can achieve the same result with palette changes, no need to mess with mode 3. The idea is that you always work in mode 0 but use 2 different degenerated 4-color palettes as following.

For screen 0:
Pen    Ink
00xx  Color1
01xx  Color2
10xx  Color3
11xx  Color4

And for screen 1:
Pen    Ink
xx00  Color1
xx01  Color2
xx10  Color3
xx11  Color4

Where xx represents all 4 possible combinations of this 2 bits. This is, both palettes are 16 color, but with the same 4 colors repeated with different pattern. Every time you want to change the displayed screen you just swap the one palette for the other.

The drawback of this method is that you can't write bytes to the screen in an opaque (blind) mode anymore, every time you want to change a pixel color in one of the screens you must "respect" the color bits for the other one, so you need to read the affected byte first, then apply a suitable mask, and OR the result with the desired color (also suitably masked).

[opqa]

There have been a topic on this here where people tried to find something useful about it but i think without any valuable result...Anyway, BEST MODE EVA! (no wonder why Amstrad hid it)

Well, if fact the above technique can be somewhat improved (in terms of speed) using mode 3. The thing is that a whole 16 colors palette swap takes quite some cycles to complete, it requires a lot of OUT's which is a slow instruction. By alternating between mode 0 and mode 3 you can reduce the color swaps to just 3 as follows.

For one of the screens you use the same configuration as before in regular mode 0:

Pen    Ink
00xx  Color1
01xx  Color2
10xx  Color3
11xx  Color4

And for the other screen you set mode 3, this has the effect of the hardware ignoring the two MSB of the pen and using only the first 4 colors of the palette, so you only need to adjust the first four pens:

Pen   Ink
0000 Color1
0001 Color2
0010 Color3
0011 Color4

The first one has already this value so there's only need to change the last three pens. To revert the changes just map those three pens to Color1 and set mode 0 back again.

[AMSDOS]

What do you mean by MODE 3 Screen?

Sorry it's called The Fourth Mode 


I have a routine which plots the image to screen using it's PEN number, along with an Article from ACU called "The Fourth Mode", just wondered if I could use my routine to test that out, guess there's no harm in trying.


Sorry for stealing your topic @ervin 

[arnoldemu]

I think there was a magazine that had a "mode 3" which was 20 columns wide, or something like that on the cpc.

I know there was one in a bbc magazine, but I am sure I remember a similar one for cpc.

[AMSDOS]

I think there was a magazine that had a "mode 3" which was 20 columns wide, or something like that on the cpc.

I know there was one in a bbc magazine, but I am sure I remember a similar one for cpc.

Only familiar with the ACU Article "The Fourth Mode" with RSX program.


I've attached Disk Image of that Program along with 2 Demos. The first Demo is using my Graphical routine to plot one ship in Pen 1 and the other in Pen 4 which flickers a bit. The 2nd Demo, demonstrates more of the RSX provided from The Fourth Mode program. In this situation, the Fourth Mode gives you 1 Screen that you can draw your image to without displaying it, though the other screen needs to be drawn and then switched to the second screen if things need to be moved around.