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

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

Share this post


Link to post
Share on other sites
Advertisement
As far as I am aware, what you''re saying is right. BltFast locks and unlocks the surface each call, whereas a custom one where you lock and unlock only once would be ''much'' faster (I''m not sure as to how much of an increase in speed you would get).

David

Share this post


Link to post
Share on other sites
does anyone know how much of a speed increase this would give over the default solution?

kosh

Share this post


Link to post
Share on other sites
Bltfast, like all of DirectDraw uses hardware functions, which means, if you load your sprites into video memory, it is a faster copy from vidmem to vidmem than it is from sysmem to vidmem. If you don''t plan on using this hardware functionality, then what you plan on doing will probably be faster.

- Tom

Share this post


Link to post
Share on other sites
Lock and unlock the surface to use BltFast? I think you''re using a different version than I am.

BltFast runs without locking.

Share this post


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

Share this post


Link to post
Share on other sites
Great minds think alike!

Yes, I thought that too. So I''ve already done that. I wrote my own blitting code in assembler and it worked great except for one thing, it wasn''t actually faster at least not on my machine.
The reason for this is that directx will use your system to the max, if you have mmx it will use mmx, if you have Hardware Blitting it will use this, and if all else fails it will use their own emulation. The last scenario and only the last scenario is beatable easily with your own blitting code. You''d have to program in optimized assembly, w/ mmx, and use system ram, in order to beat DX. And even then you wouldn''t have the functionality of hardware support. So even though I have my own routine I''m still using DX''s BltFast (Until I can use MMX well.)

My last idea was to do just that. I thought, we''ve seen like seven (maybe more) people saying that they''de like to use system ram to compose part of the backbuffer and use their own optimized assmbler routine to do the blitting. So why don''t we band together make the very best routine then give it to the people who contribute?
Anybody interested? E-mail me. (I am an assembler programmer, of about the intermediate level)

Hope this helps,
Ben

Share this post


Link to post
Share on other sites
hi ben

the bad thing about optimised assembly and optimisation in general is that the more optimised you get, the less generalised you can be

therefore, the more optimised a solution, the less flexible the solution is to fitting into more and more situations, so you end up coding a section that will only work with 64x64 sprites for example, but sucks at 40x40 sprites

you know what I mean?

kosh

Share this post


Link to post
Share on other sites
hi everyone

one thing I still dont understand is why you need to lock the surface memory before accessing it, you never had to under DOS, so why is windows so different, a surface is used in an application, therefore it''s memory protected against anything other than your application from drawing on it.

You never have to lock a char array to change stuff do you? why? cause the memory is only accessible to your application and it never moves.

Why directX needs to move stuff around, thats just bad management, there is a perfectly good way to solve this without locking.

you should need to lock the surface unless your moving it, if you are moving it, well, you lock, move, reset the pointer to the new location and unlock, then, the IDirectDrawSurface structure contains the new location and away, no need to lock unless it moves it again.

so why you need to lock just cause you wanna draw on it ?

I can probably understand in multitasking screen sharing solutions, but full screen??? perhaps when a windows dialog pops up, but how often do you get that? so perhaps you lock it there, draw your dialog and let go.

anyone got replies

Share this post


Link to post
Share on other sites
quote:
Original post by Kosh
one thing I still dont understand is why you need to lock the surface memory before accessing it, you never had to under DOS, so why is windows so different, a surface is used in an application, therefore it''s memory protected against anything other than your application from drawing on it.


Well, there''s one reason I can think of. When you lock the surface you get a pointer to it right? Well, think about how video memory would be arranged when you have one or more backbuffers. A flip tells the hardware to start drawing from one point in video memory. Meanwhile, the pointer to your backbuffer becomes what was the primary surface. At least that''s how you would do it in DOS...

So each frame, the pointer you get from Lock is different.

Otherwise, I don''t know why... Windows is weird .

Nathan.






nathany.com

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!