Jump to content

  • Log In with Google      Sign In   
  • Create Account

Interested in a FREE copy of HTML5 game maker Construct 2?

We'll be giving away three Personal Edition licences in next Tuesday's GDNet Direct email newsletter!

Sign up from the right-hand sidebar on our homepage and read Tuesday's newsletter for details!


We're also offering banner ads on our site from just $5! 1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


My own blitters continued. And some bench marks.


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
3 replies to this topic

#1 voodoo   Members   -  Reputation: 122

Like
Likes
Like

Posted 04 November 1999 - 05:11 PM

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
- ATI XPERT@PLAY PCI 4MB

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)

Blitters
- MS DirectX BLT(NO BLTFAST)
- No special written blitters

Situation
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.


Sponsor:

#2 stibbs   Members   -  Reputation: 122

Like
Likes
Like

Posted 04 November 1999 - 12:59 AM

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.

DDCAPS_BLT
Hardware blitting supported Video To Video only!!!

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

DDCAPS2_NOPAGELOCKREQUIRED
if DDCAPS_CANBLTSYSMEM then no page lock is required for hardware acceleration

DDCAPS2_NONLOCALVIDMEM
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.

DDCAPS2_NONLOCALVIDMEMCAPS
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()!


#3 Matt   Members   -  Reputation: 122

Like
Likes
Like

Posted 04 November 1999 - 04:03 PM

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.


#4 voodoo   Members   -  Reputation: 122

Like
Likes
Like

Posted 04 November 1999 - 05:11 PM

Alright this post will be stopped before it gets out of hands!

No more bashing each other...

We are all one big familly:P





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS