🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

DDraw... stuff :)

Started by
2 comments, last by GameDev.net 24 years, 6 months ago
3rd Paragraph should read 'creating all my offscreen surfaces in SYSTEM memory'.

Thanks,

--
Russ

Advertisement
Just a thought - it sounds like you're doing a redundant blit for every frame... is it any faster if you put your pirmary in vidmem, but your back buffer in system memory?

Mason McCuskey
Spin Studios
www.spin-studios.com

Founder, Cuttlefish Industries
The Cuttlefish Engine lets anyone develop great games for iPad, iPhone, Android, WP7, the web, and more!
Hi all,

For the past few weeks I have been working on
my tile engine using DDraw and I'd like to ask your advice on the matter of surfaces.

OK, some quick background. I have a primary surface, and secondary surface both in vid memory for page flipping.

I have implemented some alpha blending blitting routines, whcih obviously require fast access to each pixel. I've been told that video cards write fast, read slow so I have been creating all my offscreen surfaces in video memory. I then had a 'manipulation' surface on which I draw everything on, perform any blends, then blit the whole lot up to the secondary ready to be flipped... it seemed like a good idea at the time

However, due to no hardware acceleration, this is dog (well, quite) slow.

So the question is this:
Do I...

a) Do as I described above

b) Cram all my surfaces into video memory (video and offscreen surfaces), and perform any manipulation of pixels from the video memory.

c) Do as above, but blit each surface that I need to alpha blend into surface memory, then muck with the colours and re-blit it back up into video?

d) None of the above you idiot, do this...[insert wise and correct answer here]

c sounds ok, but the constant locking/unlocking eahc frame of the temp surface may slow it down a lot.

Anyway, any advice GREATLY appreciated as this is doing my head in.

Thanks

--
Russ

I doubt putting your back buffer in system memory would help, as this means that it is no longer a 'flip' operation (which takes only the time required for the video card to wait for an appropriate moment to show the back surface). In other words, if you don't have the back buffer in video memory, the 'flip' is HEL emulated - so I don't see any noticeable increase in speed.

You might want to look at the ordering of your blits and flips. Remember, on many cards, the blitting operation will be queued in hardware, and so if you queue a ton of blits and follow immediately with the command to blit your conventional memory buffer to video memory, and then a flip, the video card will be waiting a long time before it can flip, because it has a lot of blitting to do first. If your engine has other non-graphics work to do, best to put that in before you try to flip (if appropriate). I have seen this to make a big difference on some hardware.

If this isn't the problem, maybe you just have slow alpha routines, or are expecting too much of them. Non-accelerated alpha blending is still very slow compared to blitting regular pixels. If you're trying to use it on the entire screen, don't use a general alpha blending function, write something specific to suit your purpose.

2 questions before I finish up:
1. How slow is 'dog slow'?
2. How much alpha blitting are you doing?

Good luck

Starfall

This topic is closed to new replies.

Advertisement