We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

Bug 3889 - please allow for paletted surfaces with 32 bit depth
Summary: please allow for paletted surfaces with 32 bit depth
Status: WAITING
Alias: None
Product: SDL
Classification: Unclassified
Component: video (show other bugs)
Version: HG 2.0
Hardware: x86 Windows 7
: P2 normal
Assignee: Sam Lantinga
QA Contact: Sam Lantinga
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-10-16 11:09 UTC by Fabian Greffrath
Modified: 2018-08-15 21:55 UTC (History)
0 users

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Fabian Greffrath 2017-10-16 11:09:56 UTC 
Hi there,

as the API documentation for SDL_CreateRGBSurface() states "If depth is 4 or 8 bits, an empty palette is allocated for the surface. If depth is greater than 8 bits, the pixel format is set using the [RGBA]mask parameters."

However, I would like to create a surface with a 32-bit palette. Why? Because I am creating a source port for Doom, which usually uses a 256-color palette stored in a single byte per color. I want to extend the game to optional true-color rendering and will thus have to change the framebuffer to a 32-bit surface. In order to prevent the need to completely reimplement each rendering routine, I would like to increase the default framebuffer to 32-bit per pixel and interpret each pixel value as a palette index in "paletted" mode and as a RGBA tupel in "true-color" mode. However, with the current limitations on SDL_CreateRGBSurface() this seems impossible to achieve.

Please consider allowing for 32-bit paletted surfaces, thanks!

 - Fabian
Comment 1 Sam Lantinga 2017-10-16 18:19:14 UTC 
I'm fine with that, but it would be a feature of SDL_Surface, not the rendering system.

Would you like to attach a tested patch?
Comment 2 Fabian Greffrath 2017-10-17 10:29:33 UTC 
(In reply to Sam Lantinga from comment #1)
> Would you like to attach a tested patch?

I am not yet that far, just sharing the idea.
Comment 3 Sam Lantinga 2017-10-17 15:45:45 UTC 
Okay, that would be fine with me. :)
Comment 4 Sam Lantinga 2017-10-17 15:47:13 UTC 
Once you implement a patch you might want to check the performance. Shuffling around 32-bit data might be more expensive than working with 8-bit data and doing a final 32-bit expansion right before rendering.
Comment 5 Fabian Greffrath 2018-08-15 21:55:17 UTC 
This seems to be a lot more involved than I initially expected/hoped. There are assumptions about palette values being Uint8 all over the code.

However, I was pleasantly surprised that simply changing code from this

screenbuffer = SDL_CreateRGBSurface(0, SCREENWIDTH, SCREENHEIGHT, 8, 0, 0, 0, 0);

to this

screenbuffer = SDL_CreateRGBSurface(0, SCREENWIDTH, SCREENHEIGHT, 32, 0, 0, 0, 0);
SDL_Palette *palette = SDL_AllocPalette(256);
SDL_SetSurfacePalette(screenbuffer, palette);
SDL_FreePalette(palette);

does at least not crash, but then each paletted image will be displayed as shades of blue.