• Advertisement

Archived

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

One fullscreen blit in 800x600x32 -> 20 fps :(

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

Hiya, i am programming a 2d game using direct draw that always has the same background image. Its running in 800x600x32 so that all my (planned) effects work right and the pic / sprites look like they should. As my next frame to be shown ist rendered in a backbuffer located in vid mem and my bitmap image surface is also located in vid mem, i am doing a full screen blit from the bitmap surface to the backbuffer using the BltFast function. As i understand it this is a vid mem to vid mem transfer and it should be quiet fast. But ..it isnt. Even when having everything else that belongs to the game disabled so that this DrawBackground() is the only function in my gameloop i still get only about 28 fps. Anyone got an ideas what is wrong or how i can make it faster ? Please help me as i am stuck in the development process of my game unless i can at least get 50 better 85+ fps. cya Astral

Share this post


Link to post
Share on other sites
Advertisement
Guest Anonymous Poster
what kind of hardware do you have?

Share this post


Link to post
Share on other sites
Its possible, but probably unlikely, that your video card does not support blitting in 32bit mode (but this would be very much rediculous nowadays)

Its also possible that you may have a memory leak somewhere. Try blitting an image that is not fullscreen size (700 x 500) and see if that blits faster. If it does, your image size is bigger then the screen size, and typically Direct X doesn''t like that...

Hope that helps....



Demetrios Georgeadis
Director/Programmer
Oniera Software Artists
www.oniera.com

Share this post


Link to post
Share on other sites
are you certain it''s all in video memory?
i''m sure you requested it to all be in video memory.. but....
the primary buffer only will take up 800 * 600 * 4 = 1,920,000 bytes, which is about 1.8 megs (the 4 is 4 bytes per pixel, 32 bits). add the backbuffer to that, and you''ve got about 3.6 megs.. and if the background image is the same size and color depth (which i''m assuming it is), that makes it about 5.5 megs.. do you have that much video memory? when you run out, the program won''t crash, it''ll just use system memory, and a system to video copy will take more time..

or maybe i''m wrong and it''s something else...

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Try setting the correct Height and Width of the bitmap. When I forgot that, my program slowed down from 70+ fps to 30 fps. Try it.

Share this post


Link to post
Share on other sites
hiya,

thanks for trying to help ! Unfortunately nothing you mentioned before seems to be the cause of my problem...ah well i dont know enough about the 32 bit capabilities of my card but that shouldnt be the problem. First of all blitting my image into / from a smaller rect doesnt cure anything. Then, yes i am sure that all buffers are located in video memory (well kind of) because my display adapter, namely a matrox mystique 220 with 8mb, really should have enough ram left. Ah btw i tried it on a machine from one of my friends. It has 100mhz more cpu power and a geforce gfx card (32 mb vid mem and he got 36 fps So its not my equipment ..it must have to do with the code.
Hase anyone ever programmed something in 2d with a background image that has to be blit-ed once per frame ?? Or probably there is another work arround. Please help !!

cya and thanks for every advise you can give
Astral

Share this post


Link to post
Share on other sites
Isn''there a tutorial with DX7 in Direct draw (Tutorial 5 or so, a checkboard as a background, with 3 rotating donuts in the foreground) which should help you out ?

Share this post


Link to post
Share on other sites
Why do you need 32 bits? 16 should give you more than reasonable results.

Share this post


Link to post
Share on other sites
You really shouldn''t blow this kind of thing off and say "Oh well, I''ll just use 16bit...", because if it is making a GeoForce crawl, something isn''t right and it will likely become more prominent as you draw more to the screen.

So, can we see a few code snippets? That may well help...

-> Briar LoDeran <-

Share this post


Link to post
Share on other sites
Strange...
I use 1280x1024x32 mode, and i use Direct3D (with ZBuffer) and I get around 40fps, and when i switch to 16bpp I get over 60 fps... And my machine is not high end (P2-333, TNT-1 16MB).
Are you rely sure, that all your sufraces are in video memory (created with DDSCAPS_VIDEOMEMORY flag)??

Share this post


Link to post
Share on other sites
I may be wrong here (and let me know if I am) but I don''t think that the vid/system mem thing is what''s slowing him down. On an old 4mb ati graphics card and a shitty system I was getting like 60 fps blitting (800x600x32) a background from system memory to video memory. Is there anything special in the code outside of your graphics routine that we should know about?

-BacksideSnap-

Share this post


Link to post
Share on other sites
hiya,

BltFast is what i am using and i allready tried disabling ALL
other game functionality. Still i am only getting about 29 fps.
If it wasnt slow on my friends machine too i would guess its a driver issue. Could it be a sdk / lib issue as i am still using the dx7 sdk but i have the dx7A runtime installed ??

cu
Astral

Share this post


Link to post
Share on other sites
Why it is so slow on all computers is because, you moving douwords at a time meaning more info per pixel, the 2d features of all cards weather it be geforce 2 super caduper ddr or a milenium 220 are optimized to the max theses days hardware guysa re focusing on 3d, that why 1280x1024x32 is so fast because 3d is being always optimized. Your best bet would be to drop down to 16bit it will increase your spead big time.

Share this post


Link to post
Share on other sites
Damn I need a new mouse, keeps double clicking on me

I also forgot, make sure your screen refresh rate is higher then 60 Hz other wise it caps your frame rates. Usually most monitors show the rate when you press the setup button on them, run your app and press the button c what it says if it says 60, then try manualling setting the rate with ddraw!

Share this post


Link to post
Share on other sites
First of all, I think BriarLoDeran is absolutely right that you shouldn''t just blow this off as "well 32bpp is just slow". Also, if the background image is getting put in system memory for some weird reason, I think BacksideSnap is right -- even that wouldn''t cause such a poor framerate.

I have another guess along the lines of the system-memory/video-memory thing: maybe your background image is in video memory and your backbuffer is somehow in system memory. I think blitting from video memory to system memory is really slow (like paddling upstream or something...).

So make sure you''re creating your backbuffer surface before creating your background image surface, for one thing.

Also, I can''t imagine there being a conflict with dx7A run-time and dx7 code.

One more thing: make sure your fps counter is working correctly, because it''s not like you''d be able to see the difference between 28 fps and 280 fps when rendering a static background.

Share this post


Link to post
Share on other sites
> I think blitting from video memory to system memory is really slow

... yes, so slow that the framerate would drop far below 29 fps It''s definately not the problem.

Astral, what is your system config ? Could you post your call to BltFast here ? Are you *sure* you are providing the correct size of the screen ? AFAIK, if your screen is 800x600 your rectangle should go from 0,0 to 801,601.. if you don''t, DX will stretch your screen, which won''t be noticable for a 1 pixel difference, but will make things far slower.

Y.

Share this post


Link to post
Share on other sites
>Astral, what is your system config ? Could you post your call >to BltFast here ? Are you *sure* you are providing the correct >size of the screen ? AFAIK, if your screen is 800x600 your >rectangle should go from 0,0 to 801,601.. if you don''t, DX will >stretch your screen, which won''t be noticable for a 1 pixel >difference, but will make things far slower.

(How do you copy a message into your own message?)

Anyway,shouldn''t the rect actually be from 0,0 to 799, 599?

Astral, try to do this. In your blt routine do
HRESULT ddrval

ddrval = BackBuffer->BltFast(bla bla)

if(ddrval!=DD_OK)
{
//Log out some kind of error to a file or to the screen
}

The reason for this is because I noticed when the blt does fail it slows down the FPS considerably. If you find that BltFast is returning an error then you could further investigate to find out the reason.

But then again, I might be completely off, but I think it''s definately worth a try

Share this post


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

AFAIK, if your screen is 800x600 your rectangle should go from 0,0 to 801,601.. if you don''t, DX will stretch your screen, which won''t be noticable for a 1 pixel difference, but will make things far slower.
Y.



Since the poster is using bltfast you couldn''t possibly specify the destination rectangle size,

but for the record, I''ve never heard of this. I think if you have a screen of 800x600, then you make the rectangle 0,0 to 800,600. Don''t add an extra one to it. The SDK examples don''t do anything extra either.

Share this post


Link to post
Share on other sites
Hi

1.Try to use Blt() and not BltFast() ....

Blt() will use hardware accel if available i think bltfast will not

2.Try to have all sufraces in Videomemory not by just that u have more VRAM but by setting VIDEOMEMORY Flag in create sufrace caps structure ... if u get an error... maybe u get smthing in ur caps that makes them in systemmemory

3.What speed is ur PC? because moveing 800x600x32 data over the system PCI data bus is slow...and u will not even get 29fps

4.I think it can be done because i have a RTS game 2D in 800x600x16 with a lots of Alpha FX and shadows and logic and stuff .... it gets as low as 30fps with all FX enabled...so u must be able to do the same...
(hmmm i make it in ASM but i think is no diffrence in DDRAW calls)

5.PS.Take care not to strech sufraces and not to get into half sincronization with VSYNC signal....this last will kill ur framerate to half... (there is an article on this formu about this)

Hope u make it...

Bogdan

Share this post


Link to post
Share on other sites
from 0,0 to 800,600 goes a length of 801,601 pixels.
You are supposed to make your rects 0,0 to width,height of the screen wich is in itself one pixel more than the screen(surface, whatever) so the correct rects are 0,0,800,600
The idea is that the last line and column do not belong to the surface(and to allow the computing of width and height with only one subtraction)

By the way, I think BltFast will also use acceleration, it will just be faster than Blt if there isn't any availlable.

You might want to check how long the blitting to the backbuffer and the Flip itself take (The Flip can be conditioned by the refresh rate, but at 30 fps that shouldn't have much weight.)

Edited by - alexmoura on June 28, 2000 3:55:40 PM

Share this post


Link to post
Share on other sites
So if you pass it a 0,0,799,599 rect it'll stretch it by one pixel hence killing performance? Damn.
Seems like a weird way to pass dimensions (good - the point about fast dimension calcs is a good one - but unexpected), and at the very least the SDK ought to mention this point seeing as most people will give it a 0,0,799,599 rect seeing as that's the pixels on the screen.

p.s. - BltFast does use hardware acceleration. So does Blt. Both only use it on vidmem->vidmem blts. If a system memory surface is involved in any way, the blt gets handled by the CPU instead of the video hardware.

p.p.s. - I noticed on the first post that Astral's app uses the same background image every frame. Astral, if your background doesn't change, there's no need to redraw it every frame anyways. Are you familiar with the concept of "dirty squares"? It basically involves only updating the area directly around your sprites each frame instead of erasing the entire screen... I'm sure there's a tutorial on it somewhere (it's also called "dirty rectangles", "dirty blitting", "smart blitting", "smart refresh" or something like that.), but I don't have a url for ya. Sorry.

Edited by - PyroBoy on June 28, 2000 8:23:53 PM

Share this post


Link to post
Share on other sites
Just a little info I thought I''d post.

A while back I did some quick little performance tests. Basically I made up a "screen" on an system memory surface, then copied it myself onto the back buffer. I tested this at most resolutions, but at 800x600x32 I got 31 fps or so. Noticing this I think your offscreen surfaces are not in vid-mem for some reason...

-Zims

Share this post


Link to post
Share on other sites
quote:
Original post by PyroBoy
... the SDK ought to mention this point seeing as most people will give it a 0,0,799,599 rect seeing as that''s the pixels on the screen.



quote:
the SDK
[DestRect is] Address of a RECT structure that defines the upper-left and lower-right points of the rectangle to blit to on the destination surface...



A common mistake, points aren''t really pixels.
If you specified 800x600 as the right and bottom, it would fill everthing from 0 through just-less-than-the-800th pixel and same for height. (point 0,0 is before the pixel at 0, 0).
here is point 0,0
/
\/
O ---- 0
/pixel@/
/__0x0_/
0______0 <- is point 1,1

Share this post


Link to post
Share on other sites
Hmm yes sorry, it''s a mistake. (0,0) to (800,600), not to (801,601) as i said (and not (799,599)). The dimensions of your rect should be (width+1,height+1).

Y.

Share this post


Link to post
Share on other sites

  • Advertisement