DirectDraw BltFast Vs Customised routine

Kosh · 2000-05-27T21:44:07

hi everyone, I would just like to know if someone can help me with this thought. it came to my attention that I might be able to make sprite blits so much faster and well, I want someone to read over this, perhaps give me some advice. the solution that I had in mind was this, to do all the blitting myself, but without using Directdraw, nothing complicated and nothing new, but what I noticed about bltfast, was for every sprite blitted, you have to lock and unlock the surface you''re blitting to, which is a 16bit call, I am lead to believe by a friend. so, could I do this, lock the surface once, blit all my stuff across using 4 byte copies and then unlock, hence you only have one set of lock/unlock calls and you done all your blitting in the middle. is this any faster than blitting each sprite individually, I think it is, but I am not sure, I would like to know if someone could verify whether it is or not, whether you know already thanks, kosh

Graphics and GPU Programming Programming

Started by Kosh May 17, 2000 06:11 PM

27 comments, last by Kosh 23 years, 11 months ago

dmaziarka

122

May 19, 2000 04:39 PM

quote:Original post by Kosh

ok, to clarify, I am loading all the sprites into display memory, so there is no system ram involved.

Also, yes, of course BltFast will have to lock the surface, cause what if DirectX decided to move it around (dont know why it would, but apparently, this is what you do if you want to draw to the surface, it says in the docs, lock the surface to get direct access to it). Hence if BltFast wants to get access to the surface, it will have to lock first, otherwise, how does it know the memory will remain where it is?

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

anyone else?

Not quite right. The first message inferred the locking penalty that we get when using DXSurface->Lock() which can be quite large. BltFast does not use this function before or after each blit like your friend implied. BltFast''s locking, being internal to the library, incurs no penalty worth noting.

The only worth while reasons to write your own blit would be RLEs, alpha, anti-aliasing etc...

nathany

123

May 19, 2000 10:13 PM

quote:Original post by dmaziarka
Not quite right. The first message inferred the locking penalty that we get when using DXSurface->Lock() which can be quite large. BltFast does not use this function before or after each blit like your friend implied. BltFast''s locking, being internal to the library, incurs no penalty worth noting.

Hm. Thats good... and the software emulation version sounds to be quite optimized as well (i.e. MMX)?

quote:The only worth while reasons to write your own blit would be RLEs, alpha, anti-aliasing etc...

Well, DX8 beta1 will be available tomorrow... we shall see if that is still the case! (i heard they are integrating DDraw/D3D better... and also the same with DSound/DMusic).

- n8

nathany.com

Anonymous

May 20, 2000 03:22 PM

ok, I read all the replies here

something that has been misinterpreted here is that YOU DONT LOCK THE SURFACE !! buy directx does, automatically, it has to, anyone who disagrees, please explain then why I have to? when I access the surface?

so that point cleared up (I hope) I should note that ANY operation that gets processed incurs a penalty, to say otherwise would mean that I can lock and unlock the surface in 0 clock cycles, which is obviously not true.

however perhaps this is not what you intended me to understand your statement like....

I am going to write my own routines yes, mainly cause I dont want to rely on dx too much, cause I am planning a os conversion for linux, therefore I would like to write something that I can convert with only needing to rewrite the routines for another compiler and not having to rewrite the game cause I have to use another lib

know what I mean?

kosh

Kylotan

10,510

May 20, 2000 07:46 PM

Portability is not a good reason to write everything yourself. That way, you will just end up with something that runs unacceptably slow on all platforms, rather than fast on one. Instead, you should look to making some sort of abstract interface between the rest of your code and your graphics. For instance, nearly all my graphics code comes down to blitting rectangles to the back buffer. So the rest of the program doesn''t care how the graphics side of things works, nor should it need to. And the actual graphics side of things can take advantage of hardware and platform specific things to get extra speed: just compile different modules for different platforms.

TheTwistedOne

122

May 22, 2000 07:23 AM

quote:Original post by Anonymous Poster

something that has been misinterpreted here is that YOU DONT LOCK THE SURFACE !!

Quite correct. Not directly, anyway. As dmaziarka said, BltFast does internal locking. People who say that to use Blt or BltFast you have to Lock/Unlock can''t have tried it, because they fail if the surface is already locked.

quote:so that point cleared up (I hope) I should note that ANY operation that gets processed incurs a penalty, to say otherwise would mean that I can lock and unlock the surface in 0 clock cycles, which is obviously not true.

The penalty is tiny, tiny, tiny. Relative to calling Lock, anyway.

quote:I am going to write my own routines yes, mainly cause I dont want to rely on dx too much, cause I am planning a os conversion for linux, therefore I would like to write something that I can convert with only needing to rewrite the routines for another compiler and not having to rewrite the game cause I have to use another lib

Hmm. Not very wise. kylotan''s approach is much better.
Do you think UT/Linux or Q3:A/Linux would''ve happened if id and Epic had to rewrite /everything/ to port it?

Why not go to the logical extreme and write your own OS, so that you''re not given the overhead of a modern multitasking system like Win2K or Linux? (I refuse to include anything remotely 16bit in a definition of a modern OS).

That last was a joke, by the way (except the bit about mostly-16bit OS''s being crap). I just think you''re chopping down the wood to see the trees (or some other slightly modified variation on a popular saying).

TheTwistedOne
http://www.angrycake.com

TheTwistedOnehttp://www.angrycake.com

Prosper/LOADED

100

May 22, 2000 09:36 AM

quote:Original post by nathany

Well, DX8 beta1 will be available tomorrow... we shall see if that is still the case! (i heard they are integrating DDraw/D3D better... and also the same with DSound/DMusic).

Could anyone tell me where i can find the SDK ?

Prosper / LOADED corporation

GoofProg

127

May 22, 2000 12:55 PM

ASM routines are good for blitting, but hardware acceleration is faster. If you are going to write your own 2D blitting routines then I would suggest to create a table of the sprites that need to be blitted and blast them. Also using a mix of C and ASM for the RLE routines will help out alot

The nightmare travels across the cosmos with his burning mane. The trail of ash that is produced.

?Have a nice day!?

NoEscom

122

May 27, 2000 08:08 PM

Also do remember that you don''t have to lock a surface in system memory period. The surface isn''t going to relocate or anything and so it''s perfectly safe.

NuffSaid

122

May 27, 2000 09:44 PM

I hope this doesn''t sound out of topic or anything, but I was wondering if you could still directly access video memory in Win2K?
I''ve tried using the Lock function and getting the pointer to surface memory, but all I get is some access violation error.
Any help would be appreciated

========================================================
If something sounds stupid but works, it's not stupid

==========================================In a team, you either lead, follow or GET OUT OF THE WAY.

DirectDraw BltFast Vs Customised routine

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

DirectDraw BltFast Vs Customised routine

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines