Archived

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

Offscreen surfaces in video memory being terribly slow in DDraw7

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

Recommended Posts

I create the primary buffer and the backbuffer in video memory. Then, if I create my offscreen surfaces(sprites) in system memory with the DDSCAPS_SYSTEMMEMORY flag, i get around 60 fps. However, if I create my sprites in video memory (DDSCAPS_VIDEOMEMORY), which I thought was the best choice, I get about 6 (six) fps. The profiling shows that blitting a 16x16 surface to the backbuffer takes about 17 ms! Does anyone have any suggestions what I am doing wrong? /John

Share on other sites
Are you reading from video mem anywhere (locking surfaces etc)?

Share on other sites
quote:
Original post by Carrot
Are you reading from video mem anywhere (locking surfaces etc)?

Yes, I am, but the function that does that comes far down the profiling list, and is not related to the blitting.
However, I removed that function just to be sure, but I''m still getting the same lousy fps.

Share on other sites
Sounds like a bandwidth/flush problem somewhere but its hard to say why.
What spec card do you have, and are you sure the surfaces are actually being created where you say?
Can you post some initialisation code?

Share on other sites
it dont matter how often you call the funtion that reads from vram. reading from vram is VERY VERY slow. you should NEVER need to lock a vram surface except ot write to it. in fact, if you have vram offscreen surfaces, you should be soly using blit to deal with them after your ONE time initlization and loading of images. blitting from an offscreen surface to your BACKbuffer should be quick. make sure you are NOT blitting to your primary buffer. NO locking of the surfaces either, that is bad and not needed.

Share on other sites
I think I remember reading a while ago that OFFSCREEN surfaces do not gaurantee a texture will be placed in video memory, maybe some special texture ram or even system. I think there might be a VID mem flag you can try and if that fails you should just dump everything in system.

Share on other sites
OK, here''s some of my init code:

  DDSURFACEDESC ddsd;DDE_INITSTRUCT(ddsd);ddsd.dwFlags = DDSD_CAPS | DDSD_WIDTH | DDSD_HEIGHT;ddsd.dwWidth = width;ddsd.dwHeight = height;ddsd.ddsCaps.dwCaps = DDSCAPS_OFFSCREENPLAIN | DDSCAPS_VIDEOMEMORY;  //<- Problem is here (I think)//Allocate memory for the surfacesif(!( lpdds = (LPDIRECTDRAWSURFACE*) malloc(numFrames * sizeof(LPDIRECTDRAWSURFACE)) ))		return(0);//Create surfacesint i;for (i=0; i<numFrames; i++){	if (dde->getDirectDrawObj()->CreateSurface(&ddsd, &lpdds[i], NULL) != DD_OK)	return(0);}

I''m really appreciating your help, by the way.

/John

Share on other sites
quote:

ddsd.ddsCaps.dwCaps = DDSCAPS_OFFSCREENPLAIN |
DDSCAPS_VIDEOMEMORY; //<- Problem is here (I think)]

Try:

ddsd.ddsCaps.dwCaps = DSCAPS_OFFSCREENPLAIN |
DDSCAPS_SYSTEMMEMORY;

Guy

Share on other sites
ddsd.ddsCaps.dwCaps = DDSCAPS_VIDEOMEMORY;

And... try just this and report back your frame rate... Don''t forget to check your return values because your video card may not have enough room for all your textures.

Share on other sites
Arion: I normally use the DDSCAPS_SYSTEMMEMORY flag, as I said in my first post. With that, everything works fine, but I''ve read that you should create as many of your sprites as you can in video memory, so I was a bit surprised with the lousy performance I got with DDSCAPS_VIDEOMEMORY.

iwasbiggs: Nope, same framerate. Everything works fine, except for the speed, and the sprites are displayed correctly, so I don''t think it''s a memory shortage.

/John

Share on other sites
Sorry FunkyTune, I missed that.
That lead to a totaly useless post by yours truly.

I made a Sprite engine, and all my sprites are created in system memory. It works fine for me. Of course I do alot of writing for my sprites for roatation, making holes in the sprites etc.

If your happy with system memory performance, than I don''t see any problem sticking to it. Unless you have a reason to use video memory. I believe it depends on what you are doing with your sprites.

What kind of video card/memory do you have ?

Guy

Share on other sites
I was searching the DD help files.
I found:

quote:

Blitting from display memory to display memory is usually much more efficient than blitting from system memory to display memory. As a result, you should store as many of the sprites your application uses as possible in display memory.

I''m not sure what to make of it. It does however say usually. A bit of a cop out. Maybe it depends on the video card.

Guy

Share on other sites
it depends on ACCESS requirments. you need to use blt() or bltfast() and NOT ever use lock() EXCEPT for the once time initial loading of the images. also you should have multiple frames of animations on the surface. one surface for each frame is WAY too much. instead group serveral frames together and try to use only a few surfaces for each sprite (depending on how large and how many frames of animation). try not to exceed surfaces that are too large (512x512 is a good size).

the reason they say ussually on the docs, is because certan usages (such as reading or using too many different surfaces) are slow. many different surfaces can cause fragmentation of the vram as well as causing "surface switches" which like tetxure switches in d3d or opengl will cause stalls in the video card pipeline.

Share on other sites
Thank you everyone for your help!

Arion: I think that I read that same part from DDHelp.
I''m not entirely sure what the specs for my video card is, since it''s integrated on the motherboard. However, it''s a three and a half year old Compaq we''re talking about, so it probably sucks.

A person: I use Blt() to display my sprites, and only lock surfaces when loading bitmaps, as you say. However, the thing you said about multiple surfaces is interesting. My engine uses one surface for each frame of animation, perhaps I should change that.

Well, well, it looks like I''m bound to stick to system memory, then. It works alright, so why not? Just feels strange that video memory is so much slower...

/John