The public headers saw lots of cleanups, backporting from SDL3 docs, and
merging with the wiki.
The markdown files in docs/README-*.md were converted to Unix endlines.
For whatever reason, `ExtractIconEx` returns icons whose sizes are
inappropriate for the current DPI, resulting in terribly-blurry
window icons at higher DPIs.
To solve this, the window icon is now set to the first icon group
that is present in the executable. This behaviour should match what
Explorer does. By selecting an icon group instead of a specific icon,
Windows is free to select the icon within the group that best suits
the current DPI.
This fixes an macOS bug that is only known to occur in fullscreen windows on the built-in displays of newer MacBooks with camera notches. When the mouse is moved near the top of such a window (within about 44 units) and then moved back down, the cursor rects aren't respected. This can cause the default cursor to be visible when it should not be.
I believe there was a O(n^2) device walking issues on startup
- MaybeAddDevice gets called for every device at startup
- MaybeAddDevice calls IsJoystick
- IsJoystick calls SDL_UDEV_GetProductInfo
- SDL_UDEV_GetProductInfo calls udev_enumerate_scan_devices
- udev_enumerate_scan_devices walks all the devices
Prior to commit 3b1e0e1 this was mostly masked as IsJoystick only
called SDL_UDEV_GetProductInfo when a JSIOCGNAME ioctl was
successful. This fixes the O(n^2) behaviour by directly getting
the device via udev_device_new_from_devnum (based on type, major,
and minor number) instead of enumerating everything via
udev_enumerate_scan_devices and matching on name.
if all one needs is a raw framebuffer to the PSP's vram,
instead of dealing with renderers and textures, that need to be
copied hence and forth, this method allows one to create a window,
set the pixel format using SDL_SetWindowDisplayMode() - preferably
BGR565 for optimal speed (the other possible natively supported
option is ABGR8888) - and then request SDL_GetWindowSurface(),
which provides one with a surface with direct framebuffer access.
note that the pixels pointer inside the surface will be switched
after each call because of double-buffering.
it's advisable to overwrite all pixels of the PSP visible area
(480x272) to not encounter old data.
after writing the pixels, a call to SDL_UpdateWindowSurface()
sends the changes to the graphics chip.
the result is a raw framerate of 250 fps with BGR565 mode, under
optimal circumstances - i.e. nothing else is done than drawing,
and the drawing loop is as simple as possible.
that leaves about 12 ms per frame for other tasks and still allow
a fluent 60 fps.
This fixes getting a deflected axis as the first buffered input reading on a generic USB controller (G-Shark GS-GP702)
(cherry picked from commit 70b0d33106)
- The name for simplified Chinese should be `zh_CN`.
- Ensure `cfguExit` is called even if `CFGU_GetSystemLanguage` failed.
(cherry picked from commit 390fff4ae0)
By using the SDL_WaitEventTimeout_Device() path even when polling is required,
we can still achieve sub-millisecond latency for non-gamepad/sensor events when
a gamepad or sensor is in use by the application.
using the blocking sceCtrlReadBufferPositive() effectively turns SDL_PollEvent() into WaitForVblank(), because the functions does exactly that if no input is buffered.
due to this, calling SDL_PollEvent() once per frame averaged in 7 ms delay out of the available 16ms budget to get a frame calculated and drawn to achieve 60 fps.
The CRC is used to distinguish between different controllers that have the same VID/PID, so if the CRC doesn't match, it's probably a different controller that we don't know about.
Fixes https://github.com/libsdl-org/SDL/issues/9265
(cherry picked from commit 30e93b40c2)
Sam Lantinga
Ryan C. Gordon
Ozkan Sezer
yassineimounachen
Cameron Cawley
Romans-I-XVI
Anonymous Maarten
Clownacy
Zhuoran
Brian Collins
Alynne
Wouter Wijsman
Tyson Whitehead
rofl0r
Sylvain
Marcel Hild
Frank Praznik
Pierre Wendling
Cameron Gutman