Without unlocking, we trigger an assertion failure in SDL_sysmutex.c at line 80 (i.e. 'rc == 0'). Each lock-unlock pair should ideally cancel each other out, maintaining a reference count that returns to zero.
Currently, all SDL_Surfaces with an indexed pixel format have an
associated SDL_Palette. This palette either consists of entirely the
colour black, or -- in the special case of 1-bit surfaces, black and
white.
When an indexed surface is blitted to another indexed surface, a 'map'
is generated from the source surface's palette to the destination
surfaces palette, in order to preserve the look of the image if the
palettes differ.
However, in most cases, applications will want to blit the raw index
values, rather than translate to make the colours as similar as
possible. For instance, the destination surface's palette may have been
modified to fade the screen out.
This change allows an indexed surface to have no associated palette. If
either the source or destination surface of a blit do not have a
palette, then the raw indices are copied (assuming both have an indexed
format).
This mimics better what happens with most other APIs (such as
DirectDraw), where most users do not set a palette on any surface but
the screen, whose palette is implicitly used for the whole application.
The SDL_Surface rework in #10201 adds some extra checks that the pixel
format enum matches the SDL_PixelFormatDetails struct, which is largely
filled in with values from SDL_GetMasksForPixelFormat().
However, there are a few cases where these do not match:
- Indexed 1-, 2-, and 4-bit formats encode a bytes_per_pixel of 0, but
SDL_GetMasksForPixelFormat() gives a value of 1.
- Packed formats, like SDL_PIXELFORMAT_XRGB8888 encode a bits_per_pixel
of the number of used bits (24), but SDL_GetMasksForPixelFormat()
includes the padding byte, giving a total of 32.
We could change the encoding of these in the enum, or change what we store
in the details struct to match, but I suspect we'd either break something
that relies on it, or lose some (_maybe_ useful) information. In the meantime,
this gets the tests working again.
Signed-off-by: David Gow <david@ingeniumdigital.com>
SDL_Surface has been simplified and internal details are no longer in the public structure.
The `format` member of SDL_Surface is now an enumerated pixel format value. You can get the full details of the pixel format by calling `SDL_GetPixelFormatDetails(surface->format)`. You can get the palette associated with the surface by calling SDL_GetSurfacePalette(). You can get the clip rectangle by calling SDL_GetSurfaceClipRect().
SDL_PixelFormat has been renamed SDL_PixelFormatDetails and just describes the pixel format, it does not include a palette for indexed pixel types.
SDL_PixelFormatEnum has been renamed SDL_PixelFormat and is used instead of Uint32 for API functions that refer to pixel format by enumerated value.
SDL_MapRGB(), SDL_MapRGBA(), SDL_GetRGB(), and SDL_GetRGBA() take an optional palette parameter for indexed color lookups.
This reverts commit 3c90b1c1f6.
It turns out this is problematic for sdl2-compat. We're investigating a more complete separation between SDL2 and SDL3 surfaces, but in the meantime, I'll fix the breakage.
This declares that any `const char *` returned from SDL is owned by SDL, and
promises to be valid _at least_ until the next time the event queue runs, or
SDL_Quit() is called, even if the thing that owns the string gets destroyed
or changed before then.
This is noted in the headers as "the SDL_GetStringRule", so this will both be
greppable to find a detailed explaination in docs/README-strings.md and
wikiheaders will automatically turn it into a link we can point at the
appropriate documentation.
Fixes#9902.
(and several FIXMEs, both known and yet-undocumented.)
This better reflects how HDR content is actually used, e.g. most content is in the SDR range, with specular highlights and bright details beyond the SDR range, in the HDR headroom.
This more closely matches how HDR is handled on Apple platforms, as EDR.
This also greatly simplifies application code which no longer has to think about color scaling. SDR content is rendered at the appropriate brightness automatically, and HDR content is scaled to the correct range for the display HDR headroom.
This makes the existing SDL_SoftStretch code work with them, at least for
nearest-neighbor scaling; otherwise, it'll mangle the data trying to scale
it as 8bpp data without warning.
This means the allocator's caller doesn't need to use SDL_OutOfMemory directly
if the allocation fails.
This applies to the usual allocators: SDL_malloc, SDL_calloc, SDL_realloc
(all of these regardless of if the app supplied a custom allocator or we're
using system malloc() or an internal copy of dlmalloc under the hood),
SDL_aligned_alloc, SDL_small_alloc, SDL_strdup, SDL_asprintf, SDL_wcsdup...
probably others. If it returns something you can pass to SDL_free, it should
work.
The caller might still need to use SDL_OutOfMemory if something that wasn't
SDL allocated the memory: operator new in C++ code, Objective-C's alloc
message, win32 GlobalAlloc, etc.
Fixes#8642.
