Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 363
  • Last Modified:

DirectX Draw Question - ?

I use DirectX Draw in normal cooperative level mode and I need to blit off-screen surfaces onto primary. My off-screen surfaces are 8-bit palettized image data (with same palette as primary surface if video mode is in 8-bit palette). What I want to know is if the primary surface is in 16,24,32bit RGB, can I rely on the blitter to convert my offscreen surfaces to necessary RGB during blit? I don't mind if DirectX has to emulate the procedure if hardware doesn't support it but I don't want to have to code a 2nd alternative if it can't be done on certain user's systems. And DirectX SDK doesn't give me many clues.

If you are somewhat in the least unsure about the answer, PLEASE do not answer and let someone that knows for sure answer instead. I need a definitive answer since alot of work depends on your confidence in the subject.

Thanks
0
overworked
Asked:
overworked
  • 3
  • 2
1 Solution
 
chensuCommented:
Yes, you can do it. Check out the DirectX sample "Donut". Set your display to 16,24,32-bit mode and run donut.exe. It works fine.
0
 
overworkedAuthor Commented:
Thanks chensu. One more thing: Do the majority of video cards support this type of blit and if the video card doesn't, is the emulation operation tremendously slow. You may not know but I'm just wondering. Also, I know this wasn't included in the 150 pts but I've increased to 170 (all my pts for answer to this perhaps ez question): I also do direct writing to display surface and in 16/24/32 bit modes, are the pixels on screen in the same format? (I know they're not of course between 16 and 24 and 32 but what I mean is can I expect the format of for example the 32 bit value in 32 bit modes to be universal or must I obtain/consult a DDPIXELFORMAT for the primary surface. Thanks!
0
 
overworkedAuthor Commented:
Well there goes my points again. You do this to me every time chensu. If you check donut.cpp you'll see that it calls DDLoadBitmap function which is found in ddutil.cpp (in ..\misc) to load the bitmaps. The bitmaps are StretchBlt from DIB hdc to the current Direct Draw hdc. This means that later on the off screen surfaces being blitted to primary are in the same format as the primary surface and not palettized, thus the blit is going from palettized to palettized, 16 to 16, 24 to 24, or 32 to 32 depending upon the current mode. All of this holds no significance to my question and I have no points to ask it again.
I thought perhaps that maybe this time, my additional clause in my original question would safegaurd me from this.
0
 
chensuCommented:
I am sorry. Yes, you are right. In the sample "Donut", the conversion occurs when blitting from the memory DC to the off screen surface. When the off screen surface is created by CreateSurface(), it has the same format as the current primary surface. It seems that there is no such an example in the DirectX SDK samples. (The sample "Wormhole" loads the DIB data into an off screen surface directly, but it uses exclusive 640x480x8 mode.)

When you create such an off screen surface, you need to set the DDPIXELFORMAT ddpfPixelFormat according to your 8-bit palettized image data exactly. Also, you need to set the palette of the off screen surface using IDirectDrawSurface2::SetPalette. Then, when you blit the off screen surface to the primary surface, DirectX should do the conversion for you. I don't think it will be slow because the operation is not complicated. But, you should avoid it because the conversion occurs every time.

I am really sorry that I made a mistake.
0
 
overworkedAuthor Commented:
no prob, thanks for the apology
0

Featured Post

Get your problem seen by more experts

Be seen. Boost your question’s priority for more expert views and faster solutions

  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now