Issue with DirectDraw switching from 16 to 32 Bpp

Hello,

It's my first post here and i thanks every people for reading or taking time to my post !

I'm processing to a source's refactoring of one old application before Recoding from scratch and testing a lot of things. I will use Diretct3D but for now it's Directdraw.

Is it possible to Convert surface from 16 BPP to 32 BPP before display on front screen. If yes, does it cost a lot of CPU/RAM ?

Or

Should i convert in every sprite's functions and change pitch, colors, pixels and other parameters ?

English isn't my first language so I hope that you will understand !

Thanks !

Why don't you do it offline, then it won't make a difference how much time or how much resources it took

All sprites are in 8bpp.

A lot of tools will be not reliable with change from 8 to 16. (And how i will Recode in 2-3 months, tools included...)
Loading sprite on demand with 32bpp maybe i will try this way with direct3d but for now i can't load 5.000+ sprites with 32 bpp unless having severals GB of Memory needed for. Actually it took 300mo in 8bpp.

To fit on the screen, display was set to 16. But I'm needing to use 32 now. when i'm changing the display with set_display function to 32, I have funny/crazy colors and screen divide per 2. So I have made a few changes to have complete screen i have change Pitch and some height/width variable, use Macro RGB unstead of RGB555 and some other changes but it seems to be 'dirty method' and with a lot of work i have +/- good display with little green color with sprites that have width/2 or cut in 2.

So before spending one week more i'm asking if it was possible to convert before final display...

Thanks for your answer :)

you can convert images between formats. Going from like rgb555 to rgb888 it is not that hard. It takes some CPU cycles. You should be able to google it how to convert one pixel to another. IOW, allocate enough memory to hold new 32 bit image, which most likely need to be rgba8888, and you can just set alpha to 255. Then walk every pixel in your rgb555, convert to rgba8888 and write that pixel into correct position in your allocated memory for this converted image. Hint, you will need to use masks and shifts to extract each individual parts of a pixel (rgb) from 16 bit and then put back together into 32 bit value.

Another option is to use some third party library which can do conversion for you on the fly.

I missed the part where images were 8 bits and not 16. Anyway, if it's 8 bit, then it uses color pallete to map pixel into actual color. The steps outlined above wil work for this also, but you will lookup value of each pixel in color pallete. Again, google should have enough references to get this working.

Mr. Spock

there is no conversion from one type of surface to another. This is because that's exactly what directdraw is supposed to solve in the first place (= fast blits without needing to convert as is needed in GDI).

you create your program to work for a specific mode, and your surface "bits" will be exactly matched to that mode.

if your program is designed for 16bpp and you want to change this to 32bpp, then this will involve (extensive) rewrites in all the code that fill/load/save the surfaces with textures, bitmaps etc. the actual page flipping mechanism as well as surface to surface blits shouldn't be affected.

However, changing mode to 32bpp will mean more video memory (for the active frame, the offscreen frame and all the surfaces) is needed, so it may not work well if you're exceeding the video memory limit.

You can load/convert sprites on demand but that will have an impact on the speed at which you build each frame. If you can assure plenty of system memory, you can cache converted 32bit sprites in system memory and just "fast"copy stuff over into a surface as needed. but that's still an extra step taking time.
you can design an elaborate caching system to keep regular reused sprites in videomemory and page load the rarer ones, but that'll take development time.

I really appreciate your help !

I considerate several solutions and I'm working on convert all sprite's functions to works in 32 bpp. (I'm adding a case 32 to keep 16bpp for old computers)
Work Progress but i have to understand some issues:

- Sprites are full but have their width divided by 2 with black surface that replace other parts.
- Some are divided by too with black part (but not full this way)
- Colors are wrongs (too green).
- Only left side of the screen is used.

(I can send a picture in Private)

- I'm not sure I understand that one
- as this one
- could be because the 16color mode is designed for rgb565 with 1 bit more for green (as the human eye is most sensitive to green, 1 bit more gives it a 2x smoother colorrange on green). Other than that, your conversion isn't doing things right. :p
- not sure I understand. but it could be an address issue if you are still calculating an offset in the surface data pointer assuming a 16bit mode, where you now need to be doing it for a 32bit mode. so the (x + (y*width)) * 2 shhould now be (x + (y*width)) * 4