Jump to content
  • Advertisement
Sign in to follow this  
commy2005

bitblt win32 and directx bitblt

This topic is 4904 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 guys, I was wondering could bitblt be use in directx 9.0?COuld I do whatever win32 bitblt does in directx?Thanx in advance. TIA, Commy2005

Share this post


Link to post
Share on other sites
Advertisement
No, you can't really use BitBlt in DX 9.0. It would be too slow, and anyways you have to hack around anyways to get GDI working with D3D. There are some equivalents, look into ID3DXSPRITE.

Share this post


Link to post
Share on other sites
You can though obtain the (GDI) device context from a buffer, for example the primary one, using GetDC(). That would allow BitBlt I suppose. It could be useful on loading. On load performance is not really an issue and it is not a hack, it is just a very valid API use.

Alternatively, you could lock a surface and copy the contents yourself.

Greetz,

Illco

Share this post


Link to post
Share on other sites
Quote:
Original post by Illco
You can though obtain the (GDI) device context from a buffer, for example the primary one, using GetDC(). That would allow BitBlt I suppose. It could be useful on loading. On load performance is not really an issue and it is not a hack, it is just a very valid API use.


That's DirectDraw. [wink] DirectX 9 uses all Direct3D for graphics, and you can't used the GDI with Direct3D without copying the contents of a GDC to a rendering surface. Not particularly efficient, when you could just use ID3DXSPRITE and get extra speed and efficiency.

Share this post


Link to post
Share on other sites
Thanx guys...

I really wondering what I can do with directx 9.Is there another way to copy surface and put to somewhere else?Or maybe reload the surface and store to somewhere?Like copy surface and save as bitmap?Sounds ironic man!Hopefully some other ways.Thanx guys for a quick respond.

cannot sleep thinking of a way,
Commy2005

Share this post


Link to post
Share on other sites
Quote:
Original post by Oberon_Command
Quote:
Original post by Illco
You can though obtain the (GDI) device context from a buffer, for example the primary one, using GetDC(). That would allow BitBlt I suppose. It could be useful on loading. On load performance is not really an issue and it is not a hack, it is just a very valid API use.


That's DirectDraw. [wink] DirectX 9 uses all Direct3D for graphics, and you can't used the GDI with Direct3D without copying the contents of a GDC to a rendering surface. Not particularly efficient, when you could just use ID3DXSPRITE and get extra speed and efficiency.


That's odd because I'm going to paste from the SDK docs:

IDirect3DSurface9 Members
-- snip --
GetDC Retrieves a device context.

I really believe an IDirect3DSurface9 belongs to Direct3D, wouldn't you agree? It will not be particularly fast. Obvious uses would be loading a Windows bitmap via GDI (because DX does not support it natively) or rendering text using a font. I'm confident the overlay D3DX framework does it in this manner.

Greetz,

Illco

Share this post


Link to post
Share on other sites
Hmmm, my mistake. Must have been thinking of DirectX 8. However, the docs also have this to say:

Quote:

When a device context is outstanding on a surface, the application may not call these methods:

IDirect3DCubeTexture9::LockRect
IDirect3DDevice9::ColorFill
IDirect3DDevice9::StretchRect
IDirect3DDevice9::UpdateSurface
IDirect3DDevice9::UpdateTexture
IDirect3DSurface9::LockRect
IDirect3DSwapChain9::Present
IDirect3DTexture9::LockRect


This means that he must use the GDI for EVERYTHING, which could potentially be very slow, and also quite inefficient since he won't be able to use hardware blitting for colour fills and other things, such as drawing bitmaps. It would also be slow for drawing pixels, since that would have to go through the GDI, which would be quite slow.

In other words, it's not a good idea to use GDI with DirectX, since it can be rather slow, and you can do the same things with DirectX, and you can do it faster, so why not just do it with DirectX? Even Microsoft, who wrote all of this stuff, encourages you to use the faster DirectX methods instead of the GDI. This is shown by how deeply buried all this GDI stuff is in the DirectX docs.

Share this post


Link to post
Share on other sites
Yes true. But not everything happens between Begin() and End() of the rendering. With loading it may be useful to use the structures and functions GDI provides, which DX does not provide. Also, you can return the DC after which all those calls are fine again.

Share this post


Link to post
Share on other sites
Okay guys...thanx for the replies and sorry for my ironic question that causes confusion for everyone.I am still wondering does Directx sdk explain how to copy surfaces??I am still confused of you guys ideas and recommendation.

:( This is so confusing.Basically,I am trying just copy surfaces (WIN32 bitblt the backbuffer to a HBITMAP).Is just a small program(for testing).Just a cube though..:)..I know how to do it in WIN32,i was wondering how to do it in directx 9.0 anyway.

If following the way recommended was like GetDC() then releaseDC(),will it work?Anyway..speed was not a big problem,but how BIG problem was the speed you guys was talking about?FPS drop to like less than 10?:)..let me know guys..:)

Thanx in all the confusion and trouble I causes.Sorry guys.

cannot sleep,
Commy2005

Share this post


Link to post
Share on other sites
You could use that approach. The speed penalty will be quite heavy, as Oberon said, GDI is slow as it was not designed for real time high quality graphics.

The DirectX way is to lock the surface and copy the bits elsewhere as you like. The D3DX extension provides some functions for this. There is also StretchRect() which allows you to copy portions of (or whole) surfaces around.

Illco

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • 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!