Jump to content
  • Advertisement

Archived

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

cyberben

DirectX Triple Buffering?

This topic is 6933 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

Hi there, I''m having a very weird problem with DirectX. Specifically Direct Draw. I''ve create a primary and back buffer surface properly and have my game working great. It''s running in either 640 x 480, 800 x 600, or 1024 x 768 @ 16 bpp. Everything works great no problem yet. Now I''d like to fade the screen out, so hears what I did. (I wrote this in assembler but, that''s beside the point) I wrote a function which loops 64 times. Each loop iteration it reads in 4 pixels at a time (MMX) from the back buffer and darkens the pixels then places them back. Then it flips the surface. Now instead of a nice fade I get every second frame a nice fade and the other frames black. (ex: Draken frame, Black Screen, Darkened frame, Balck screen...) This makes no sense to me, I''m wondering if maybe DirectX is forcing me to triple buffer because It''s not done copying the backbuffer to the screen while I''m trying to darken the backbuffer again. Any help? Thanks, Ben

Share this post


Link to post
Share on other sites
Advertisement
Well, when you flip surfaces it just replaces the pointers, I think.. So what it looks like is happening to me (unless I don''t understand the problem fully) is that you are darkening, then flipping, then trying to darken what was previously on the primary buffer, which might already by black.

It''s late, and I don''t think what I wrote just now made sense. But maybe it did, who knows??

I really hope this helped!

Share this post


Link to post
Share on other sites
Hehe, you fell into the ol "DirectX Back Buffer Flipping Scenario". When you flip a surface, your simply switching the pointers that point to the primary and secondary surface, not actually blitting the back buffer to the primary buffer. Of course, when you switch the pointers, the primary surface pointer now points to what was the back buffer, and the back buffer pointer now points to the primary surface, thereby tricking the hardware into drawing that instead. So, since your primary buffer (which is now refered to as the back buffer) was initially black (assuming you clear the "back buffer" each frame), the back buffer now points to a black surface. Your code is now fading black, which is black. See how it works? However, every frame, it blits to the opposite surface, which results in the pattern of blackness. What you have to do is create a third surface, do all fading work there, and then blit that suraface to the back buffer, and then flip. Try to visualize this process in your head. It confusing at first. I'd be glad to elaburate further .

Edited by - Zipster on 4/30/00 12:45:45 AM

Share this post


Link to post
Share on other sites
Also to point out, thats why its faster to flip a back buffer than to blit one, since only pointers are changed in flipping, while bytes of data are changed during blitting.

Damn, Qoy beat me to the response. Hes luccky it takes me a while to type .

Share this post


Link to post
Share on other sites
I just wanted to comment on one thing you said, "maybe DirectX is forcing me to triple buffer". I''m pretty sure that you always have to explicity create back buffers, so if you only ask for one, I don''t think DirectX could sneak in another.

Share this post


Link to post
Share on other sites
Thanks guys,
Yeah the pointers makes sense. I should have known that too! Thanks again, I''ll try this now and post in a bit to see if it worked.

Share this post


Link to post
Share on other sites
Actually one more thing. In my studies I''ve seen both that accessing system memory is faster and slower than accessing the memory on the graphics card (I forget the techy name for that).
So which is it? If I''m going to create a third surface should I put it in System memory? Keeping in mind that I''m going to alter every single pixel in the surface manually.
Thanks,
Ben

Share this post


Link to post
Share on other sites
I can''t remember what i read, but i think my book said to put all those other buffers into System Memory or something, I''ll get back to ya!

Share this post


Link to post
Share on other sites
Generally speaking, shove all of your graphics into videomemory. If they won''t fit (or you have slow videocards) putting all the surfaces into system memory may be faster. If you give the user the option to choose the destination you may have the best of both worlds, but that depends on your target audience.

btw, the creation flag OFFSCREENPLAIN tries to create the surface in vid, but if it fails, it is created in the next available fastest memory. (like tries texture->systemmem).

Share this post


Link to post
Share on other sites
If I know what I''m talking about, then you should put anything you''re manually editing in system memory. If you''re going to manually edit it, I think that it''s faster to edit system RAM than to send data off the motherboard into the graphics RAM.

Plus, if I''m correct, then there''s no point in putting the surfaces in video memory unless you are using hardware acceleration functions to draw to the surfaces, because you''re not keeping the operations on the card anyway. If you are using the card to blit, then it''s faster to blit from the graphics RAM. But if you''re using the CPU to blit, then it''s faster to go off system RAM.

I think

------------------------------
Jonathan Little
invader@hushmail.com
http://www.crosswinds.net/~uselessknowledge

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!