quote:
As others have pointed out, triple-buffering requires video memory to be used solely as a frame-buffer. Given today''s high PC resolutions, this is a big problem given the relatively small memory on current graphics cards. (800 x 600 @ 32 = 1.8Mb. That''s excluding Z-buffering data. And you could have used that memory for a lot of textures.)

But cards are coming out with 128MB of memory now. 1.8MB out of 128MB is only a small fraction. I have a 32MB card and I don''t mind turning triple buffering on.

quote:
Triple buffering is still frame-limited: if your target platform refreshes at 60 Hz (and most consoles do), your game won''t display its images any faster than this. You can only achieve high speeds if your engine runs (a) faster than the refresh rate, and (b), you turn v-synch off. In which case, double-buffering is all you''ll need anyway.

Maybe I''m misinterpreting: Why would you want to get higher than 60Hz? The point isn''t high framerates, but good quality without reducing framerate. You can run at 500fps and still get horrible tearing. Yes, on a console where you can figure out what the framerate will be, you may not need it. But one PC may run at 500fps and another at 50fps. I''m sure the owner of the second PC would appreciate being able to get 50fps without tearing, as opposed to 30 with double-buffering. If the game would enable it without asking, maybe more people would use it. Enabling it in UT isn''t exactly something you find in the users manual.

I think your engine should get either the highest framerate it is capable of, or a framerate equal to your refresh rate. Image quality is also important, as tearing reminds the player that they are playing a game with flaws. Triple buffering solves these problems.

quote:
(The XBox only has to render Halo at 640 x 480, so it''s no great surprise that it doesn''t drop frames. )

You''re joking, right? I can find NUMEROUS places in the game where Halo''s framerate is well below 60fps. There are many others where it drops to what appears to be about 15 or 20 fps.

I have to say this: now that I know that UT''s triple buffering works, I will never play with it turned off. This lets me run at high resolutions with high detail and no tearing WITHOUT being forced to play at 30 or 20fps. I say more games should have the OPTION to turn on triple buffering.

--TheMuuj

Hey! Please notice that 3D games are not candidates for triple buffering... for these are better techniques like asyncronous rendering and so. Many of you are thinking about 3D games, but in these, the benefits of using triple buffering are doubtful.

In 2D, you gain the time of waiting for flip because you draw in other surface. In 3D, as the drawing is hardly assisted by hardware, is prefered to send the triangles to the card and gain the time while the card is rendering. When the card ends rendering, it waits for retrace and flips; but is no need for triple buffering because, between the ending of drawing and the flip, the programmer can do other things in any case (as managing sound, calculating AIs, etc). Yes, a triple buffer could always help, but every designers prefere to put more textures in memory and don't use the triple buffer, instead, they "optimize/plan" the code to do things while waiting for the retrace.

Many of us don't bother of all this when programming small games but it is posible to peform many of the cards operations "asynchornously", and many commercial 3d games do. Triple buffering is not, probably, a technique for 3d games (except 3d games with software rendering engines: the processor can't work "asynchronous" because is only 1 processor).

PLEASE do the tests with your own source code, because, by the way, you don't know what are commercial games EXACTLY doing. I think tripple buffering works correctly on many cards, it does on my Matrox G200 Productiva, on my gForce 400MX, and did before that on my old Matrox G100.

I think it would help an article about all this with some tests to prove all this. I'm quite sure anyway but don't have enough knowledge about 3d cards arquitecture to do one, I think.

Real programers are not afraid from maths! (I am)
(from an Asfixia Member I think)
JJpRiVaTe (Private Zone)

[edited by - jjmontes on June 9, 2002 1:08:25 PM]

There''s two benefits to triple buffering. First, you don''t have to wait for v-sync to render the back-buffer, which targets the 60/30 fps problem.

For a moment, pretend there''s no such thing as a GPU, and it''s 1994 and we''re all programming software renders on multi-processor SGI machines.
With such an SMP system, you can pipeline the rendering of the frames such that the first processing unit renders to back-buffer1, and the second unit renders to back-buffer2.

There might be a similar situation today with mixed vertex processing and SMP machines.

It seems as though there is a lot of confusion in this topic. Let me make a few points to clear things up:

1. Triple Buffering can be used on any type of animation, 3D or 2D.

It is not just limited to 2D. The same is true for Double Buffering.

2. Triple Buffering and V-Sync are not related.

They are used together, but one doesn''t imply the other. My video card (Radeon 8500) does triple buffering no problem. I have 3 buffers. I can tell that I have 3 buffers easily by not clearing the buffers for each frame of the animation, and there are 2 inbewteen buffers before I start drawing on the 1st buffer again. What my card does not do properly is V-sync. If you are not V-syncing, there is absolutely no reason to have a 3rd buffer - since you might as well just draw to the 1st buffer, as the video card is no longer displaying it, anyway. The 3rd buffer would just be a waste of memory.

3. If you do not V-sync, then you get tearing. If you v-synch, you do not get tearing.

Since the screen is drawn from the top down, the tearing is visualized as horizontal tears, and therefore is most noticeable when there is something scrolling horizontally (which can happen in 2D and 3D). V-sync''s only purpose is to avoid tearing.

4. Since V-sync and triple buffering are in no relation to each other, you can v-sync (or not v-synbc) in double buffering and in triple buffering.

The problem is that V-syncing in double buffering slows down the frame rate, since once you are done drawing your frame to buffer #2, the video card is still half-way displaying #1, you have to wait until it is done drawing #1 before you can start writing the next frame to it. This forces a framerate that is a multiple of the current refresh rate (i.e. among others: 20, 25, 33.3, 50, or 100 on a 100 Hz refresh rate - notice the HUGE gap between 100 and 50). If you didn''t care about tearing, you could switch right now (and get a tear), and start using #1, but you don''t want to tear - so you are v-synching. That''s why we need buffer #3. Buffer #1 is begin drawn right now. Buffer #2 has the frame that will be drawn next. And you are just starting to draw to Buffer #3.

Now my specific problem is:

I ask to triple buffer AND v-sync (obviously, since triple buffering is pointless without v-synch), and I get triple buffering and tearing. Since I get tearing, it means the video card is not v-synching. This implies when I call ''flip'', it is actually flipping the buffers right then and there - right as I call it, and it is not waiting for the v-synch to flip. Note that I don''t want my program to wait for the v-synch to flip - I want my program to start drawing to the 3rd buffer. I want the video card to wait for the v-synch to flip.

I can only assume this is a driver problem with the Radeon 8500 - I can''t figure out anything else.

Maybe when you specify 2 backbuffers in directX that v-synch is implied (again, because triple buffering is pointless without v-synching) and you don''t actually have to tell it to flip at the v-synch? Is this the case?

Jason Doucette
www.jasondoucette.com

quote:
Now my specific problem is:

I ask to triple buffer AND v-sync (obviously, since triple buffering is pointless without v-synch), and I get triple buffering and tearing. Since I get tearing, it means the video card is not v-synching. This implies when I call ''flip'', it is actually flipping the buffers right then and there - right as I call it, and it is not waiting for the v-synch to flip. Note that I don''t want my program to wait for the v-synch to flip - I want my program to start drawing to the 3rd buffer. I want the video card to wait for the v-synch to flip.

I can only assume this is a driver problem with the Radeon 8500 - I can''t figure out anything else.

Maybe when you specify 2 backbuffers in directX that v-synch is implied (again, because triple buffering is pointless without v-synching) and you don''t actually have to tell it to flip at the v-synch? Is this the case?

Jason Doucette
www.jasondoucette.com

What version of DirectX are you using? I know that in a fullscreen DirectX8 application, vsync is turned on for all present modes EXCEPT D3DPRESENT_INTERVAL_IMMEDIATE. If you have 3 or more back buffers it is supposed to chain them for you.

I am not familiar with programming in DirectDraw 7, so I can''t help you there.

You may need to manually tweak your driver settings. I''m not sure if this still applies to the current drivers but give this site a look: http://www.rage3d.com/radeon/reg/index2.shtml

--TheMuuj

quote:Original post by Jason Doucette
I can only assume this is a driver problem with the Radeon 8500 - I can''t figure out anything else.

If you are creating your device with present parameters other than IMMEDIATE and you are seeing tearing, you should report the bug to ATI. They''ll likely want a minimal app that displays this behaviour (to make sure you aren''t doing something wrong).



Stay Casual,

Ken
Drunken Hyena

I am using DirectX 8.1.

But, I am not using Direct3D, I am using DirectDraw. I declare DirectDraw and its surfaces like so:

IDirectDraw7* dd;
IDirectDrawSurface7* primary;
IDirectDrawSurface7* back;

I can only assume that this means I am using DirectDraw 7 - I am very new to this, so I don''t really know. I do know that DirectDraw and Direct3D were combined in DirectX 8.x, but I don''t know if I am asking to use DirectX 8.1, or if the above requests that the program uses DirectDraw 7. Maybe they are the same thing?

I set the co-op level as so:

r = dd->SetCooperativeLevel(g_hwnd, DDSCL_EXCLUSIVE | DDSCL_FULLSCREEN | DDSCL_ALLOWREBOOT);

I set the primary surface as so:

ddsd.dwSize = sizeof(ddsd);
ddsd.dwFlags = DDSD_CAPS | DDSD_BACKBUFFERCOUNT;
ddsd.ddsCaps.dwCaps = DDSCAPS_PRIMARYSURFACE | DDSCAPS_FLIP | DDSCAPS_COMPLEX;
ddsd.dwBackBufferCount = NUMBEROFBACKBUFFERS;

I set the back buffer as so:

ddsd.ddsCaps.dwCaps = DDSCAPS_BACKBUFFER;
r = primary->GetAttachedSurface(&ddsd.ddsCaps, &back);

I was told the only difference between double buffering and triple buffering is to set ddsd.dwBackBufferCount to either 1 or 2 (for the number of back buffers, duh). But is this the only thing I have to do?


Jason Doucette
www.jasondoucette.com