Jump to content
  • Advertisement

Archived

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

Kosh

DirectDraw BltFast Vs Customised routine

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

Have you written a game using BltFast yet?
I had sprites all over the place and never had a problem with this method running too slowly.
Just use it for a while before you decide to optimize it.

If people spent more time making their game fun to play and less time trying to find the holy grail of speed we''d have better games.

Just my two cents.

MCSE, MCSD, Sun Certified Java Programmer
Pimp Daddy ;)

Share this post


Link to post
Share on other sites
Advertisement
What I want to know is what the professionals use, like blizzard

But here are the arguments of between using blt & bltfast against your own routine.

1- If you choose to write your own routine, it is easily more portable to other systems
2- Blt & bltfast will do colorkeying, but no transparencies so you will still have to write some type of blit routine for transparencies etc...
3- Blt & bltfast actually are pretty fast when it comes to vidoe to vidoe ram, plus hey, video cards are only getting faster and faster and more ram. I mean who cares of the joe who has the 4 meg vidoe crad these days, do those cards even still exist??

I remember with my ati 4mb card I was laoding all to system ram an doing individual blits to back buffer I wasnt loosing any speed at all.

Share this post


Link to post
Share on other sites
quote:
Original post by Kosh

So, the question now, is how much faster is hardware blitting from video to video than software 32bit copies?

anyone else?


I tested speed of different blits by blitting 100 times a 640x480x16 surface on another. Here are the result on my PIII-500 / GeForce PC :



Transfert type - Time spent (milliseconds)
--------------------------------------------
VIDEO->VIDEO 40
SYSTEM->SYSTEM 400
SYSTEM->VIDEO 400
VIDEO->SYSTEM 4000



Even with an astonishing optimization, i don''t think you''ll beat the hardware blit.

You''d better use BltFast()



Prosper / LOADED corporation

Share this post


Link to post
Share on other sites
quote:
Original post by voodoo
I mean who cares of the joe who has the 4 meg vidoe crad these days, do those cards even still exist??



the vast majority of all computers out there have 2 and 4 meg cards. Just because YOU have a {32/54/128} meg card, it doesnt mean everyone else does.



===============================================
If there is a witness to my little life,
To my tiny throes and struggles,
He sees a fool;
And it is not fine for gods to menace fools.

Share this post


Link to post
Share on other sites
I''m a little surprised that system to system is as slow as system to video. Is this a fluke? Or is this the norm?

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
GeForce card is AGP, Allowing fast system to vidmem copies.

In my adventures through the DirectX documentation I have never read that blt or bltfast need to lock a surface in order to copy it. Where are you getting this information from (not trying to sound sarcastic)?

Share this post


Link to post
Share on other sites
quote:
Original post by Gorky

I''m a little surprised that system to system is as slow as system to video. Is this a fluke? Or is this the norm?




er... In fact, system->system is a bit faster. Here are more accurate digits :


VIDEO->VIDEO : 47
SYSTEM->SYSTEM : 488
SYSTEM->VIDEO : 405
VIDEO->SYSTEM : 4757
[code]




Prosper / LOADED corporation

Share this post


Link to post
Share on other sites
I tried quite a while back to beat the Bltfast routines. It turns out it really isn''t worth it. Like cyberben said, DX uses all kinds of stuff like MMX. I beat it slightly when I turned off its use of MMX, but not by enough to warrant the amount of time I put into it. With MMX (and without it in my code), it was faster. And then of course vid to vid hardware blits buried me.

A valid reason to do it is to support Alpha blending, but besides that it isn''t worth it. But if you''re planning to try, DON''T put the surfaces in video memory like you said Kosh. Copying from video to video across the system bus is terribly slow. If you''re writing your own routines, I''d say use your own sprite structures (there isn''t any reason to use system DX surfaces if you''re blitting it all yourself; except for the video screen).

One other reason to blit yourself would be to utilize things like RLE blitting (which I haven''t done). This should be faster for blitting transparent images. But I''d suggest jumping to MMX if transparent blitting is a bottleneck.

Rock

Share this post


Link to post
Share on other sites
If you are doing sysram to sysram Blts with BltFast, you can get faster speeds with your own ASM routines. For one, locking the surface once per frame vs once per Blt. And there is no overhead of deciding to use software or hardware blts... you can make certain assumptions.

But I think that if this is all you wanted to do, it''s probably not worth while.

I''ve been looking into alpha blending and "rle encoded" blts... besides encoding spans of a color key, a solid color, or raw data... one can also encode a 25%,50%,75% alpha blending command for a give span. The blending can be done with a shift, mask, and add making it quite fast. This can also be used for antialiased sprites, and yes... it is possible to optimize this kind of stuff with MMX.

I''m still questioning how much alpha blending you can do in this way though. If it were a little simpler to utilize 3D hardware for a 2D game, it might make sense to only support alpha blending on a 3d card, and forget about doing all this weird ASM coding.

Of course, the best method is probably to do both... detect hardware and use it, don''t detect hardware then use custom ASM routines. Unfortunately it''s a bit of a pain dealing with "rle encoded" sprites for one method, and textures for the other method.

Fun, fun, fun

Nathan.




nathany.com

Share this post


Link to post
Share on other sites
", but what I noticed about bltfast, was for every sprite blitted, you have to lock and unlock the surface you''re blitting to"

I honestly have no idea what you''re talking about here. I have NEVER needed to lock the surface to call bltfast, to me, that would kind of defeat the purpose.

----
Windows and Unix suck, I''m going back to CP/M.

Tape_Worm

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!