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

My own blitters continued. And some bench marks.

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

Your benchmarks are useless without proper experimentation ie results on X number of machines using optimised software and hardware rendering!

I did exstensive research into this area and consider myself as quiet an expert at graphics programming mainly for my ASM experties so as you can guess I have written a few software renderers in my time.

Here is your quote:
"you can't beat the speed of hardware period. Use the blitter."
Very true but what happens if there is no hardware accleration or limited capabilities!!!

Not all graphics cards support all the latest accelerartion techniques even my computer, not even a year old does not support any form of video to system or system to video aceleration!

Now I know that the Microsoft documentation on Direct Draw hardware accleration usage is a little vague in this area so I will try and make things more clear.

Hardware blitting supported Video To Video only!!!

System to Video and Video to System blits using DMA. This may require the use of PageLock and PageUnlock to use the hardware acceleration

if DDCAPS_CANBLTSYSMEM then no page lock is required for hardware acceleration

AGP non local video memory support make sure your surfaces are created using the non local video memory flag when calling CreateSurface. Non local video memory is an area in system ram treated like video ram.

The blitting capabilities to non local video memory are not the same as video to video check dwNLVBCaps & dwNLVBCaps2

So in conclusion for a well designed game you have to anticipate a veriaty of hardware config's and write a number of update/rendering routines optimised for to use what hardware acceleration is avaliable and there are a hundred ways that can be writen. This can be seen with 3D games when they have different renderers for Glide, OpenGL, D3D, and Software.

Phillip stiby
Technical Manager Coull Ltd.

PS So the better quote to use is

Use hardware were avliable you can't out code it, but if it's not avaliable a piece of well designed personalised code is a lot faster then an all round blitter like IDirectDrawSurface::Blt()!

Share this post

Link to post
Share on other sites
Andre Lamothe isn't a famous game programmer, he is a famous game programming book author, there is a distinct difference.

As far as any benchmarks go, they mean nothing really. I don't see your code, so for all I know, it could be written horribly.

Or your structures could be garbage, I can't see any of that.

If you show me one circumstance where a hardware blitter beats a hand written one, I'll show you another in which the opposite is true.

Share this post

Link to post
Share on other sites
At the bottom are some bench marks I did with my own engine...

Guys, I think most of you are complicating your lives for nothing!

Just use the DX blitters! To tell yeah the truth I think DX is the only good thing to come out of MS. Especialy DDraw and D3D.

I say, use the blitters for what ever is supported, Colorkeying, Rotation, Scaling and writte your own stuff for what's not support ed like Alpha blending.

For those who mised out, I e-mailed Andre Lamothe(famous game programming author) and I asked him a simple question...

Should I write my own blitters or should I use the DX blitters, and I even went on to explain to him about the surface locking overhead and the system ram problems...

You know what he told me and I quote
"you can't beat the speed of hardware period. Use the blitter." That's all nothing else just one line reply

Bench marks:

Target computer
- P2 300
- 64 MB

Engine setup
- 16 bit
- 640x480 Res
- Double Buffering

Frame counting system
1- Get current time at top of loop
2- Do all blitting and game logic
3- Increment frame counter
4- Check time if it's past 1 sec display frame rate
(Just to make sure there no cheating going on)

- No special written blitters

All images loaded into system ram.
30 calls to GDI for putting text on screen
1 640x480 image back ground
100 sprites of 120x45 size

Frame result: 22-23 frames a sec
With triple buffering: 28-30 frames a sec.

Share this post

Link to post
Share on other sites