Offscreen surfaces in video memory being terribly slow in DDraw7

Started by
13 comments, last by FunkyTune 21 years, 10 months ago
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
Advertisement
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
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.
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
/John
I have just read in this thread that you guys do not lock the surfaces when you write to them (and only when you load bitmaps). Am I understanding this correctly? I am programming a simple 2D application in which I create the frame completely in software (no hardware blitting), and I always lock the backbuffer before the writing to it begins, and unlock it after it ends. I thought this was necessary. Is it?

Jason Doucette
www.jasondoucette.com
Jason Doucette / Xona.comDuality: ZF — Xbox 360 classic arcade shmup featuring Dual Play

This topic is closed to new replies.

Advertisement