If you want access to the SDL_REVISION define,
you must explicitly include this header.
Language like this was present in the SDL2 version,
but disappeared in SDL3, even though it's still true.
This reverts commit a3992f504c.
The reason SDL_revision.h was not included by SDL.h or SDL_version.h is because SDL_revision.h changes with every git commit, causing a complete SDL rebuild for every trivial git commit.
* GPU: D3D12: Missing WinPixEventRuntime.dll now logs warning at device creation time.
* GPU: D3D12: Debug label functions are now a no-op when WinPixEventRuntime.dll is missing.
* Docs: GPU: Debug function documentation now notes WinPixEventRuntime.dll is required under D3D12.
In the unlikely case that the overflow check should fail,
the else clause would switch to the truncated stack message
without updating the len variable. This would contain the
return value from vsnprintf(), meaning it could point beyond
the buffer.
The subsequent code which trims NL and CR from the buffer,
would then read -- and possibly write -- out-of-bounds.
To fix this, we split the two joint conditions into separate
if-clauses, and adjust the len variable in the case where we
know the message buffer was truncated.
We already set the main thread when creating a thread or calling SDL_Init(), and applications can call SDL_SetMainReady() themselves for special cases, so there isn't a lot of value of forcing everyone through the SDL_RunApp() flow.
Fixes https://github.com/libsdl-org/SDL/issues/14580
This prevents validation errors on D3D12 caused by the previous solution
that utilized internal D3D12 functions. This is still the fallback
solution if WinPixEventRuntime.dll is not present in PATH, but a warning
is printed to let you know how to fix these errors.
SDL_SetWindowFullscreen now reports failure while a fullscreen transition is
already in progress on Emscripten, upsetting the test when it tries to come
back to windowed mode, but testautomation will never give correct results here
even when we fix the backend to queue pending reversal requests, because
you'll have to return to the Emscripten mainloop before these state changes
will occur.
It's just sort of luck this specific test passed before on this target.
At best, this is a no-op.
At worst, it might:
- Clobber a signal handler someone registered after us
- Overwrite the signal mask or flags
- Cause unregistration to fail (sigaction() isn't guaranteed to return the exact pointer passed to signal())