Jump to content

  • Log In with Google      Sign In   
  • Create Account

Triple buffering, fps and surface location...


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
9 replies to this topic

#1 Daniel Benmergui   Members   -  Reputation: 122

Like
Likes
Like

Posted 21 February 2000 - 04:40 PM

Hello Everybody!!! I recently tested an application i made using my tile engine, and was surprised to discover that it wouldn''t throw more than 42 fps no matter what. This is the situation: I have a primary and backbuffer surface, both in VRAM. Then, i have a surface filled with tiles sized around 320x32 The tileset engine fills the screen with the tiles...but in no more than 42 fps!. It''s my f*** tile engine! i said. But then i tried copying a screen-sized bitmap from an offscreen buffer to the backbuffer, but it still threw me 42 fps!!! I switched back to my tile engine, but this time i tried triple buffering...and this time it threw 75 fps. So, i started wondering about this subject. I have a 4MB video card, but many people don''t, so, what would happen in a system with, say, 1 MB? And why i didn''t need to triple buffer in Heaven & Hell (a little game i made based on the tile engine, look in "please take a look at this game..." thread to see the example)? I didn''t use triple buffering there and it reached 84 fps (monitor refresh rate) comfortably. This matter is confusing to me, if anyone has this more clear, i''ll be grateful. I thought i had the behavior of the rendering chain more clear, but today i discovered i don''t THANKS!!!

Sponsor:

#2 Ingenu   Members   -  Reputation: 893

Like
Likes
Like

Posted 21 February 2000 - 08:46 PM

The triple buffering is a tool used for vsync games.
The more buffer you have ready, the less time you''ll lost waiting for blitting (waiting fo vsync)

For your second game, your card is so fast that it already have a buffer ready when a vsync occured.

Forget about less than 4Mb cards, most people have at least that, and most of the time 16Mb...
(TNT, TNT2, 3Dfx Voodoo?, PowerVR, ...)
I think you can assume that people have 8Mb cards.
Such you could enhance your game, isn''t it ?

-* Sounds, music and story makes the difference between good and great games *-

#3 TUna   Members   -  Reputation: 122

Like
Likes
Like

Posted 21 February 2000 - 11:38 PM

I''ve got a similar problem although it can''t be solved as easily as yours I don''t think ;(

I have my primary surface, and backbuffer in video ram. I then have a work surface in system memory as I want to do software alpha blending.

Now if I render my scene into the system surface (except for the interface) and then blt the system surface to the backbuffer, add the interface and call a flip.

Now I''m getting around 30fps. This isn''t exactly fast, but if I remove the blt from system to vidmem (still rendering all the info on the system surface) I get 60fps (my monitor refresh rate).

Now does anyone have any suggestions as how to get around the slowness of the system memory -> videomemory blt? Should I be doing this slightly differently?

Thanks

#4 errand   Members   -  Reputation: 122

Like
Likes
Like

Posted 22 February 2000 - 12:04 AM

Tuna: I assume you are using DirectX, and the question is do you use blt or bltfast when you blitt from sys mem 2 video mem?

I would say go for bltfast since you don't want/need clippers when you blitt a fullscreen and clippers while lower the performance

Edited by - errand on 2/22/00 6:05:30 AM

#5 TUna   Members   -  Reputation: 122

Like
Likes
Like

Posted 22 February 2000 - 11:57 AM

I''m already using BltFast ;(


#6 Rock2000   Members   -  Reputation: 122

Like
Likes
Like

Posted 22 February 2000 - 01:30 PM

Sys to video blitting is slow (unless there is acceleration for that). No way around it. The frame rate depends highly on how fast data can be written to the card. Fast cards can accept around 80 Megs per second, average ones around 40 Megs/sec (mine is about this), and slow ones can be down to 15 or even 8 Megs/sec (useless). If at all possible, avoid copying from system memory. Otherwise, you''ll have to accept that it won''t run on many cards (8 bit can be pushed pretty well, but 16bit will need around 30Meg/sec minimum).

Rock

#7 Void   Members   -  Reputation: 126

Like
Likes
Like

Posted 22 February 2000 - 01:45 PM

Try going to assembly for speed if u need to copy from system->vid mem.

#8 chronno   Members   -  Reputation: 122

Like
Likes
Like

Posted 22 February 2000 - 02:15 PM

Well, this technique is a bit more complex, but if you use it your speed will be really bigger.

Unless you are blitting the whole surface (i think that`s not the case), i suggest to you to build a list of rectangles that will be copied to the video. Theese rectangles are called "Dirty Rectangles" and only the portions of the screen that need to be redrawn will be copied to the video mem.

You can read more about this technique at the net, because i forgot the addresses right now. I only have one that''s the Allegro site. On the demo that comes with the package this technique can be observed (this is for substitute the Tripple Buffering too).


-Chronno-

#9 chronno   Members   -  Reputation: 122

Like
Likes
Like

Posted 22 February 2000 - 02:21 PM

ah, one more thing: if the system -> video is not hardware accelerated, i suggest to use Memcpy instead of Blit, or write your own code in ASM for that.

To memcpy do not forget to calculate the bitdepht for the copy...

-Chronno-

#10 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

Likes

Posted 23 February 2000 - 02:05 AM

I''ve written a sys->vid asm blitter to try to improve optimization in one of my games. Let me just say that nothing can beat BltFast, I don''t care how good you are at asm. I''ve used my own source, and source found on the net. Nothing can beat BltFast for sys-video transfers.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS