• Advertisement

Archived

This topic is now archived and is closed to further replies.

More than 1 backbuffer?

This topic is 5698 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

What''s the point? When might one need more than 1 backbuffer? I remember somebody suggesting it to solve a problem before, but I totally forget what it was.. and it''s annoying me now. What kind of advantages does it give to use more than 1?

Share this post


Link to post
Share on other sites
Advertisement
More than 1 backbuffer can help with speed issues if the performance is being hindered due to waiting for vsync. With more than 1 backbuffer, graphic data can be written to that buffer while waiting (for vsync) to flip the other to the screen. DirectX won't use it, though, if you don't have enough video memory.
-Sam

[edited by - SamCN on June 1, 2002 3:46:28 PM]

Share this post


Link to post
Share on other sites
Interesting.. so it could be a solution to my problem with low frame rates in full screen? It goes from 300 fps about down to 60 when I switch it to fullscreen. Making 2 back buffers would solve this? I tried increasing the backbuffer count but there must be something else to do because it was giving me a run-time error (DX 8.1).

Share this post


Link to post
Share on other sites
G''day!

In full-screen, by default, is synced to the refresh rate, which in your case is probably 60Hz. You can change it to present immediately, but then you risk tearing and other graphical unpleasantness.

Stay Casual,

Ken
Drunken Hyena

Share this post


Link to post
Share on other sites
Can you increase the refresh rate? 60hz is unbarable unless you are using a TV or something...

on a side note: I use 2 backbuffers, one for 3d rendering and a separate one for all my old 2D code. I did that to improve performance on my new video card, writing to a 3d surface was just way to slow

Share this post


Link to post
Share on other sites
You can by changing manually the FullScreen_RefreshRateInHz (something like that) paramater of the Presentation Parameters of the device.. it''s dangerous though if you don''t check to see if the computer supports the refresh rate, I''m not sure how to get the supported refresh rate. But yeah, I manually put mine to 100 hz and raised the FPS to about 100 or so, but that''s something you just can''t do in a real application. If you can find a way to check to see if the computer supports a refresh rate, and you find that it does, then you can put that value in the RefreshRate parameter of the PP and it''ll change it.

Share this post


Link to post
Share on other sites
This will get the best possible refresh rate


D3DDISPLAYMODE dm;
short maxcounter;
short counter;
UINT highesthz = 0;

maxcounter= p_D3D->GetAdapterModeCount(D3DADAPTER_DEFAULT);
for(counter = 0; counter < maxcounter; counter++)
{
p_D3D->EnumAdapterModes(D3DADAPTER_DEFAULT, counter, &dm);
if(Width == dm.Width && Height == dm.Height)
{
if(dm.RefreshRate > highesthz)
{
highesthz = dm.RefreshRate;
}
}
}
d3dpp.FullScreen_RefreshRateInHz = highesthz;

Share this post


Link to post
Share on other sites
It would be nice to have 2 back buffers for triple buffering AND v-synch on at the same time. I would like the flip to occur at the start or end of the retrace, but not with a waiting loop. If a command could be triggered at the start/end of the retrace to run the flip, then the waiting part of the code could be removed, and instead of waiting for something, the CPU can be producing the next frame. This makes for a fully triple buffering, v-synched game that will never run above the refresh rate, and will never have shearing, even if it''s running 68 Hz on a 70 Hz refresh monitor. This is how is was done in the good ol DOS days.

Is this possible in DirectX?

As far as my limited knowledge (I just got into it last week), the answer is no, which makes me question the need of the 3rd buffer to begin with. If you use vsync, the only way I know how is to use the command that waits for it (which removes any hope of using this idle time for drawing the next frame). If you don''t use v-sync, then you get shearing, since the card isn''t waiting for the v-sync. I finally now realize why all of the newest games with the newest graphics hardware still shear like the crappy DOS games back in the day - it''s because DirectX (and the hardware, I assume) simple do not support true shear-free triple buffering. What a shame...


Jason Doucette
http://www.jasondoucette.com/

Share this post


Link to post
Share on other sites
I don''t know what you refer with v-sync, is it the same as waiting for vertical retrace?

This is what I know, from the book ''inside directx (microsoft press)'':

Using a tripple buffer will help you will be not waiting for the vertical retrace, never. When you call ''flip'' the surface in which you draw changes (to the other backbuffer) and when the vertical retrace succeeds, it effectively flips the backbuffer and the primary surface. This helps in reducing the time lost in a usual call to ''flip'', which must always wait for the vertical retrace.


  
Refresh......: |_____|_____|_____|_____|_____|_____|
Backbuffer .A: d*****d*****d*****d*****d*****d*****d
Backbuffer .B: ddddddd*****ddddddd*****ddddddd*****d
Backbuffer C1: ddddddd***** ddddddd** dddddd**
Backbuffer C2: dddddddd*** ddddd***


Legend: d=drawing, *=occupied (we called flip and is waiting for the retrace really flip)

Well, the graphic shows 3 cases:

Case A: The game draws a frame in less than a ''refresh cicle'', so it can always draw a frame, then flip... we spend some time waiting for real flip (***) but it doesn''t matter because we can draw the next frame in less than a retrace.

Case B: We spend more than a ''refresh cicle'' in drawing a frame (ddddddddd), so we draw a frame, then call flip (we have to wait), and when we can draw again we have lost a vertical retrace. Bad, here we can speed up drawing in the moments that we are now waiting retrace (case C).

Case C: We first draw to backbuffer 1, then call flip but, instead of wating, we begin drawing to backbuffer 2 (gaining time), when we flip backbuffer 2, we can draw again to backbuffer 1 (the real flip has already been done). And so on.

By the way, I''ve tried it, and it of course worked. Triple buffering was invented for that.

Hope it helps.

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

Share this post


Link to post
Share on other sites
Actually, I have that same book, and I remember reading that page a long time ago. Long before that, I understood triple buffering and the book explained it perfectly. So, obviously, it must be possible in DirectX. The whole key is that there should never be any waiting. Of course, if you don''t care about synching to the retrace (yes, that''s what I meant by v-sync), then you can just flip whenever, never waiting for the retrace, althought you''ll get a bunch of sheering in the screen. Triple buffering is supposed to allow you to do the the same carefree animation, but making the images only flip at the retrace. But I have tried this, and it doesn''t work. Since you say it does, and the book says it''s possible, I can only assume my hardware doesn''t allow it. I have a Radeon 8500.

Also, are you sure it works for you? If you see are tearing in the screen at all, it''s not working. I can use triple buffering on my card, but it doesn''t allow the flipping to be v-synced unless I specifically wait for it (which removes the purpose of triple buffering over double buffering to begin with).

Jason Doucette
http://www.jasondoucette.com/

Share this post


Link to post
Share on other sites
It is a shame, because it''d be a great thing if it worked. I can''t get it work on my machine either (Voodoo 3..) I''m not sure if it''s a hardware problem so much as maybe a compatibility problem in the code somewhere? Like having to change specific code in certain places to make it use both buffers. I dunno, but whenever I change my code to use triple buffering I get an error.

Share this post


Link to post
Share on other sites
quote:
Original post by Jason Doucette
Actually, I have that same book, and I remember reading that page a long time ago. Long before that, I understood triple buffering and the book explained it perfectly. So, obviously, it must be possible in DirectX. The whole key is that there should never be any waiting. Of course, if you don''t care about synching to the retrace (yes, that''s what I meant by v-sync), then you can just flip whenever, never waiting for the retrace, althought you''ll get a bunch of sheering in the screen. Triple buffering is supposed to allow you to do the the same carefree animation, but making the images only flip at the retrace. But I have tried this, and it doesn''t work. Since you say it does, and the book says it''s possible, I can only assume my hardware doesn''t allow it. I have a Radeon 8500.

Also, are you sure it works for you? If you see are tearing in the screen at all, it''s not working. I can use triple buffering on my card, but it doesn''t allow the flipping to be v-synced unless I specifically wait for it (which removes the purpose of triple buffering over double buffering to begin with).

Jason Doucette
http://www.jasondoucette.com/


I''m not sure, but my other PC has a Radeon, and I know that the drivers have issues with v-sync (i.e. it doesn''t always work), so I assume that this would mean triple-buffeing is not implemented properly either. I have used DirectDraw apps that use double buffering before, but I never tried it on my Radeon. Without writing my own test app, I''m not sure how to make sure it is working.

But considering it''s ATI, I would bet it is a driver issue.

--TheMuuj

Share this post


Link to post
Share on other sites
Yes, driver issues are always nice to have.

You can do a simple test to see if the card is actually waiting for the retrace or not - just print think verticle lines that travel horizontally across the screen at least 4 pixels / frame (change their location according to the frame count - not the frame rate), and if you are not waiting for the retrace (or if you are asking your card to, and it''s not listening), then you will see terrible shearing. It works best when the lines contrast a lot against the background. Just program the lines in over your existing code, and you''ll see.

When I synch, even when using triple buffering, I only get frame rates of a factor of the retrace. For example, if the refresh rate is 100 Hz, I can only get 100 Hz, 50 Hz, 33.3 Hz, 25 Hz, 20 Hz, etc, which is the exact same thing as double buffering (as you can see in that book, or by the example given above by jjmontes.

Also, if triple buffering is so easy, then why do so many games choose not to use it? Perhaps this is a driver problem, as well. Can anyone confirm that Unreal or Serious Sam 2 uses triple buffering and synchs to the refresh rate?

Jason Doucette
http://www.jasondoucette.com/

Share this post


Link to post
Share on other sites
I'll try and run some tests on the 'UseTrippleBuffering' feature of UnrealTournament tonight. If I'm not mistaken, triple buffering with vsync off should have better performance than vsync on. And triple buffering with vsync would basically be pointless.

I wonder if it be possible to implement triple buffering at the driver level, forcing all applications to use it. It seems like it might be fairly complicated, but it would be great for apps that are tear-happy.

EDIT--apparently you are supposed to turn on both vsync and triple buffering in UT, so it wouldn't be 'pointless.'

--TheMuuj

[edited by - themuuj on June 5, 2002 12:30:21 PM]

Share this post


Link to post
Share on other sites
But using triple buffer is not necessary in many cases. In simple games and examples, you can draw a frame in less than a screen cicle... no need. And in other games the improvment may be not too noticeable.

In ANY case, triple buffering is not very used actually because programmers prefer use that enough amount of memory in having more sprites in de video memory. In fact, the recommended way to do it is:

- create the screen and 2 buffers (triple buffering)
- load all sprites in video memory
- if done, ok, if not, unload de sprites, create the screen with only one backbuffer, then load the sprites again.

This means that having all the sprites in video memory is much more important than having two backbuffers.

The real improvement can be seen with low number of different sprites. For example, we can make an example that draws many 30x30 (more or less) sprites moving and bouncing in the screen. This can be easily done in less than a screen cicle, but if we put many many sprites (+350 in my PentiumII) we lose the retrace and have to wait. The case is that we lose time drawing (if we losed time calculating, we could think in doing before). Well, in this cases, we can earn time if we draw those sprites while the other backbuffer is waiting to flip (it flips with the vertical retrace, while we can draw in the other backbuffer since we call Flip() --> that amount of time is what we save with triple buffer).

As you see, this only applies to cases when the time is lost drawing to screen and then waiting for the next retrace. Most actual games doesn''t fit here, since they spend time calculating things and have a considerably need of video memory for sprites.

Hope it helps.

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

Share this post


Link to post
Share on other sites

Waiting for the VSync stops tearing, it doesn''t matter how many back buffers you use, you''ll still get tearing if you don''t use vsync.

Triple buffering helps smooth out your rendering since your app spends less time waiting to flip.

Why don''t more games support Triple-buffering? Some do, but don''t tell you, others don''t because it''s a huge increase in memory allocation for what is often a marginal gain.


Stay Casual,

Ken
Drunken Hyena

Share this post


Link to post
Share on other sites
quote:
Original post by DrunkenHyena

Waiting for the VSync stops tearing, it doesn''t matter how many back buffers you use, you''ll still get tearing if you don''t use vsync.Triple buffering....




Right. I think this too, as I''ve said. But here is some people who seem sure that their card doesn''t support it and this is something that video cards support since their begginings.

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

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
One question: How do framerates higher than your refresh rate really matter? I mean, they''re being "drawn" between the monitor''s painting cycles, right?

Share this post


Link to post
Share on other sites
quote:
Original post by Anonymous Poster
One question: How do framerates higher than your refresh rate really matter? I mean, they''re being "drawn" between the monitor''s painting cycles, right?



But you never get framerates higher than that. As much, you can have framerates equal to that. Triplebuffering is just a technique to reach the best framerate if with doble-buffer (1 backbuffer) you can''t.


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

Share this post


Link to post
Share on other sites
quote:

But you never get framerates higher than that. As much, you can have framerates equal to that. Triplebuffering is just a technique to reach the best framerate if with doble-buffer (1 backbuffer) you can''t.



Right. With vsync, the framerate should equal to your refresh rate, or some value that divides it (n, n/2, n/3, n/4...).

And it''s not that the cards don''t support it. It''s that ATI has had a bug in their driver that causes vsync not to work in some situations. So the hardware supports it, the API supports it, but even if the programmer uses it, it won''t work. And without the sync you can''t really benefit from triple buffering.

But, it is important to try and get the framerate of your rendering engine high. In order to maintain the refresh rate, your engine must be able to maintain framerates HIGHER than the refresh rate. If your monitor is 60Hz, your engine can''t sort of get 60fps and be okay, because then your app will be getting 30fps at times.

When I play games, I up the detail until I can consistantly get 1.5x my refresh rate, and then I turn on vsync. This usually eliminates all problems.

Triple buffering is beneficial because it allows vsync without the side effect of halving the FPS everytime the rendering speed slows down.

--TheMuuj

Share this post


Link to post
Share on other sites
quote:
Original post by jjmontes
This means that having all the sprites in video memory is much more important than having two backbuffers.


You are quite correct. This is possibly the reason many of the new games do not have triple buffering on by default.

But I do believe that triple buffering can improve the frame rate of any game (as long as all the sprites/textures still fit into memory), as long as the frame rate is under the refresh rate. Particularly if it is very close to the retrace rate, say at 65 fps when the retrace is 70Hz. Triple buffering allows the game to run at 65 fps, and double buffering only allows it to be run at 1/2 of 70Hz, 35 fps. Quite a difference.

What exact command do you guys use to synch with the retrace? Maybe I am using the wrong command. It looks like I am asking the entire program to wait specifically for the retrace before the flip occurs (doing absolutely nothing in the mean time). I only want it to flip at the retrace - so to wait for the retrace for the flip, BUT do not delay the entire program from starting the next frame while waiting. See what I mean?

My command for flip is:

dd WaitForVerticalBlank(DDWAITVB_BLOCKBEGIN, 0);
primary Flip(0, DDFLIP_WAIT);

(I left out the arrows)


Jason Doucette
www.jasondoucette.com

Share this post


Link to post
Share on other sites
quote:
Original post by jjmontes
...But here is some people who seem sure that their card doesn''t support it and this is something that video cards support since their begginings.


I believe that my video card supports waiting for the retrance to synch with it - I''ve done that. I don''t believe my video card supports (probably because of drivers) proper triple buffering, which means waiting for the retrace to flip BUT, at the same time, processing the next frame on the 3rd buffer. My system waits, and does nothing while waiting, for the retrace, and then flips, and then starts on the next frame. The 2nd buffer is ready at this point, which makes the 3rd buffer useless. The problem is that the flip stalls the entire program while waiting.



Jason Doucette
www.jasondoucette.com

Share this post


Link to post
Share on other sites

  • Advertisement