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 6937 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

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

Share this post


Link to post
Share on other sites
Advertisement
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

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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

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!