Triple screen buffer, and ...

[Psychophanta]

I think it would be just perfect if OpenScreen() and OpenWindowedScreen() functions incorporate an optional parameter for 1, 2 or 3 screen buffers (2 as default).
And if selected 1 unique buffer, the drawing info just should be drawn in real time to the screen.

[blueznl]

yep makes sense

[LCD]

single buffer: yes
double buffer: yes
tripple buffer: why?

[blueznl]

tirple buffer *could* make animations smoother

[Psychophanta]

Triple buffer should be useful for games and other screen stuff.
You can use (play with) 2 buffers while the other one is being displayed, and this is useful sometimes, and allows animations smoother, as blueznl say, over all if it is used lots of drawing stuff (like multiple clipped scrolls, lots of sprites, lines, etc.)

Have you seen MAME32, Raine or other emulators? They have a checkbox to activate a third screen buffer or leave 2 only.

[GPI]

Triple buffer should be useful for games and other screen stuff.
You can use (play with) 2 buffers while the other one is being displayed, and this is useful sometimes, and allows animations smoother, as blueznl say, over all if it is used lots of drawing stuff (like multiple clipped scrolls, lots of sprites, lines, etc.)
Have you seen MAME32, Raine or other emulators? They have a checkbox to activate a third screen buffer or leave 2 only.

I don't know it exact, but tripple buffer is more than only 3 Buffers for drawing. At the moment you make it so: Draw on a screen and show a other screen and then switch. With 3 Buffers there are no diffrent: You draw on a buffer, show a buffer and do nothing with the third buffer. This will increase nothing.

And at the moment you can easy create a Third (4. 5. 6. ...) buffer (for background for example) with createScreen() and usebuffer()

So tripple buffer allready exist

[Psychophanta]

CreateScreen()
I can't see that funct.

Please might you write a small example to use 3 screenbuffers?

[GPI]

CreateScreen()
I can't see that funct.

Please might you write a small example to use 3 screenbuffers?

Sorry, Create Sprite.

[Psychophanta]

Mmmmh, you are right, even it might be a bit tricky and ugly.

Well, OKay, at least i miss the posibility to work with a single screen-buffer; i mean: just when the program draws, is just when the drawing is displayed, simple.

Weeell, i know and i understand perfectly that Fred intentions was to make easy smooth graphics movements on screen, avoiding flickering... so OpenScreen() creates 2 buffers.
But this is a limitation for real-time screen drawing testing purposes. :roll:

[Fred]

I will add support for single and triple buffering methods. BTW, you seem to misunderstand the use of the 3th buffer. It's not to make anim smoother (how could you do, with 2 buffers it's already perfect) but to use the CPU time better, when the frames to renders doesn't always take the same amount of time (which is very often in a 3D games). All the problem starts when the Vertical Blank synchronization is activated (VWAIT). The real case for a 50 fps game or a 50 Hz monitor (easier for the calcs, each frame can take 20 ms max to render to have a no slowdow game):

1) Double buffered game:

1 frame: 15 ms to render
2 frame: 10 ms to render
3 frame: 30 ms to render

With the Vertical Blank synchronization, the buffers are switched every 20 ms (50 times per seconds = 20 * 50 = 1000 ms). Ok, so the first frame is rendered in 15 ms. No problem, it's under 20 ms. Same for the 2nd frame. And now the 3th frame takes 30 ms so the game will slowdown as the buffer flip will occurs only 10 ms later (remember it's every 20 ms).

How a triple buffer could help here ?

1 frame is rendered on the 1st buffer and flipped. No problem
2 frame is rendered on the 2st buffer and as soon the rendering is finished you can start to render on the 3th frame ! So yes, you have 30 ms to render the next frame and the game will not slow down

Got it ? I don't know if the explainations are ok

[blueznl]

actually, fred, that is what i meant

[Psychophanta]

blueznl wrote:

actually, fred, that is what i meant

Mmmhhhhh, are you sure?

Fred took part of his time to explain it. Thnks
Continuing with his example; he said:

"1 frame is rendered on the 1st buffer and flipped. No problem
2 frame is rendered on the 2st buffer and as soon the rendering is finished you can start to render on the 3th frame ! So yes, you have 30 ms to render the next frame and the game will not slow down"

So, if i have understood well the matter is that when we are rendering on the 1 frame we have a surplus time of 5 ms, which are completely lost using 2 screenbuffers, because inmediatly after that rendering we are calling FlipBuffers(), and this func "eat" those 5 ms.
For the 2 frame, we are loosing 10 ms. of our marvellous time if using 2 screen-buffers.
But if we have a third buffer we are not obligated to wait after render on a frame buffer, because we can inmediatly start to work on that third buffer while the second one was displayed.

[Fred]

Psychophanta: That's exactly that. FlipBuffer() actually waits (your program is halted) for the Vertical Blank, so yes the first frame loose 5 ms of CPU time, and the second 10 ms.

But if we have a third buffer we are not obligated to wait after render on a frame buffer, because we can inmediatly start to work on that third buffer while the second one was displayed.

Not exactly. You will start to work on the 3th buffer when the 1st is still displayed (else no need for 3 buffer, you can start to work again on the 1st one). The time line looks like this:

0 ms: Render the on the first buffer
20 ms: Display the first buffer and start rendering on the 2nd buffer
30 ms: Start rendering on the 3th buffer
40 ms: Display the second buffer (done by DirectX via an interrupt)
60 ms: Display the third buffer.

As you can see, you have 30 ms to render the 3th buffer before displaying it (60 - 30)

[Psychophanta]

That's right, i was too much quickly imagine-ing it.
Of course, if i put to display the 2st buffer, i own the 1st to render, so why a 3rd?

As you can see, you have 30 ms to render the 3th buffer before displaying it (60 - 30)

That's the trick, the result is we have more time to render a 3rd buffer than the time needed to be displayed (20ms)
(whenever we have a surplus of rendering time for the 2nd buffer)