It's too close the 3.2.0 release for an API change like this.
If/when we re-add these, some things for consideration:
* What use cases does this enable that aren't currently possible?
* What cross-platform API guarantees do we make about the availability of these events? e.g. do we try to simulate them where raw input isn't actually available?
* How is this different from the existing relative mode, and how do we clearly explain when you want these events vs wanting relative mode?
Notes from @expikr:
First observation: the reason I originally passed denominators instead of multipliers was because some rational values cannot be exactly represented by floats (e.g 1/120) so instead let the end-developer decide how to do the dividing themselves. It was the reason why it was using split values with an integer numerator to begin with, instead of having both as floats or even just normalize it in advance.
On the other hand, passing them as multipliers might have hypothetical uses for dynamically passing end-user controlled scaling in a transparent manner without coupling? (Though in that case why not just do that as additional fields appended to `motion` structs in an API-compatible layout?)
So it’s somewhat of a philosophical judgement of what this API of optional availability do we intend for it to present itself as:
- should it be a bit-perfect escape hatch with the absolute minimally-denominal abstraction over platform details just enough to be able to serve the full information (á la HIDPIAPI),
- or a renewed ergonomic API for splitting relative motion from cursor motion (in light of The Great Warping Purge) so that it is unburdened by legacy RelativeMode state machines, in which case it would be more appropriate to just call it `RELATIVE` instead of `RAW` and should be added alongside another new event purely for cursor events?
This alternate API stream was conceived in the context of preserving compatibility of the existing RelativeMode state machine by adding an escape hatch. So given the same context, my taste leans towards the former designation.
However, as The Great Warping Purge has made it potentially viable to do so, if I were allowed to break ABI by nuking the RelativeMode state machine entirely, I would prefer the latter designation unified as one of three separate components split from the old state machine, each independently controlled by platform-dependent availability without any state switching of a leaky melting pot:
- cursor visibility controls (if platform has cursor)
- cursor motion events (if platform has cursor)
- relative motion events (if the platform reports hardware motion)
Almost everything in this header is now documented! The remaining gaps are
literal C runtime wrappers like SDL_strdup, and the analyzer macros like
SDL_INOUT_Z_CAP.
This commit does the following:
- add logic in the `WM_MOUSEMOVE` case of the Window to conditionally call `WIN_UpdateClipCursor` upon receiving cursor motion if SDL is expecting the mouse to be clipped in some way (Fixes#7890)
- remove Windows-specific periodic refresh of cursor clipping and its `SDL_HINT_MOUSE_RELATIVE_CLIP_INTERVAL` hint (superceded by the above bullet point)
- streamline the processing logic within `WIN_UpdateClipCursor` for better readability of each branch, and avoid calling the Platform API until it is absolutely necessary.
- move `relative_mouse_center` field from Windows-specific per-window `SDL_WindowData` to the global `SDL_Mouse` struct, and the corresponding hint callbacks to `SDL_mouse.c` instead of `SDL_windowswindow.c`
- Removes SDL_RenderDebugTextV
- Changes SDL_RenderDebugTextF to SDL_RenderDebugTextFormat and tweaks it to
work in a world without SDL_RenderDebugTextV.
- Tweaked rendering position of formatted text in the example program.
It is not uncommon for clients to redundantly set the window size and position, either as a holdover from an SDL 1 port, when this was required, due to any window state change triggering a universal update function that sets all window state, even if unnecessary (e.g. always calling SDL_SetWindowSize(), even if the window is fullscreen), or due to the use of compatability layers. Historically, these clients expect that their behavior won't override the base window state, which is an assumption that the windowing changes in SDL 3 broke by caching size and position changes that can't be applied immediately.
This change drops size and position requests when the window is in the maximized and fullscreen states (fullscreen-desktop windows will be repositioned, but the non-fullscreen floating position will not be overwritten), which is behavior more in line with existing client assumptions, and should ease the porting process, as well as prevent annoying bugs when older software is run via sdl2-compat.
In the process of making these changes, pending window state has been moved to separate variables in the SDL_Window struct, as this fixes bugs regarding fullscreen display selection and centering windows immediately after resize on asynchronous platforms, which had issues due to pending state possibly being overwritten.
This can be reverted if a toolchain arrives that can handle C99 features like
variables declared in the middle of a scope, but for now we literally can't
compile SDL3 for this platform.
Fixes#11243.
This is a hard requirement on Apple platforms and while most other platforms don't have a concept of main thread, all video and input functions should be called on the same thread.
Everything in SDL3 up to the ABI lock is reported as available since 3.1.3.
Everything else will be reported as since 3.2.0 (what will be the first
official release).
Also ran a Perl script over the headers to change everything to 3.1.3 that
wasn't an API function, since fnsince.pl can't manage those. If there's a
macro or datatype that has snuck in that needs to be 3.2.0 instead, we'll
have to manually fix it up, but it shouldn't be a big deal in any case.
Reference PR #11304.
This is sent when the device is lost and can't be recovered.
Also fixed the vulkan renderer so it returns errors appropriately and will log and break if debug mode is enabled.
This reverts commit 2d3fa03d53.
Different JDK implementations define JNIEnv differently for C++, so we can't provide the definition here.
Fixes:
/usr/lib/jvm/temurin-11-jdk-amd64/include/jni.h:195:17: error: conflicting declaration ‘typedef struct JNIEnv_ JNIEnv’
/home/runner/work/sdlwiki/sdlwiki/.github/../external/SDL3/include/SDL3/SDL_system.h:266:24: note: previous declaration as ‘typedef struct _JNIEnv JNIEnv’
Wayland can expose displays in any arbitrary order, and doesn't have the native concept of a primary display. However, there are games that presume that the first listed display is the primary, which can lead to problems if that output isn't necessarily the ideal one, as they may use that display to build a resolution list or as the default fullscreen output. This sorts displays by position, then attempts to find the primary display, first by querying the explicit ordering hint, then the GNOME DBus property, then tries to determine the 'best' display according to the criteria that is generally ideal for games and media playback.
The makes the list of displays deterministic, as long as the desktop configuration remains static, with a reasonably appropriate one prioritized as primary, even if there is no explicit way to retrieve the primary display. In the case where a user has a particularly esoteric physical display configuration, the new hint enables explicitly overriding the sorting and selection logic, allowing the entire display order to be customized, if necessary.
My simplification of the conditions for including SDL_main_impl.h
had one problem: I forgot that SDL_main_impl.h must be included
even on Android when SDL_MAIN_USE_CALLBACKS is used, because then a
SDL_main() function that makes sure the callbacks get called is needed,
and that function is implemented in SDL_main_impl.h
But OTOH, even when SDL_MAIN_USE_CALLBACKS is used, SDL_main_impl.h
should not implement a standard `int main(...)` function on Android
(because there the SDL-using native code is compiled as a library and
the entry point is in SDLActivity.java, which calls SDL_main()
in said library).
So the check for platforms that don't have *any* native main function
but just SDL_main() called from the outside should be handled in
SDL_main_impl.h, so both the normal and the callback case can avoid
generating a standard main() in the same way.
To do this, SDL_MAIN_EXPORTED is defined for platforms like Android,
where the real entry point (main() function) is outside of the code
that uses SDL, so
- SDL_main() must be visibly exported with SDL_DECLSPEC, so the outside
code can call it
- SDL_main_impl.h must not implement a "real" main() function
Another small change based on this is defining SDLMAIN_DECLSPEC
at a more general place.
If another platform like Android (where the entry point is somewhere
else entirely, possibly implemented in a different programming language)
turns up, defining SDL_MAIN_NEEDED (so the users main() is renamed
to SDL_main()) and SDL_MAIN_EXPORTED should be all that's needed on the
SDL_main.h side - and if not then at least the implementation is
cleaner and clearer now, IMHO.
fixes#11162
SDL_DelayNS() now passes through to the high precision OS delay function, and SDL_DelayPrecise() tries to busy wait to get as close as possible to the desired wait time.
Fixes https://github.com/libsdl-org/SDL/issues/11141
This includes both wasm64 and wasm32 when addressing more than 2gb of memory.
Fixes: #9052
(Manually cherry-picked from 3deb07ea395373204462130c1e062bc1f71fe060.)
If WinRT returns after all, or a similarly bad platforms turns up,
the code can still be found in the git history.
But keep in mind that it then will have to be added *before* the
#if ( defined(SDL_MAIN_USE_CALLBACKS) || defined(SDL_MAIN_NEEDED) ...
case for platforms that support plain C to work correctly
Basically all platforms where SDL_main.h renames main() to SDL_main()
use the platform-specific main() (or WinMain() or whatever)
implementations in SDL_main_impl.h - and that renaming is enabled with:
#if defined(SDL_MAIN_NEEDED) || defined(SDL_MAIN_AVAILABLE) \
|| defined(SDL_MAIN_USE_CALLBACKS)
#define main SDL_main
#endif
The only exception is Android, where main() *is* renamed, but
SDL_main_impl.h isn't used, because SDL_main() is called from Java.
So I think it's cleaner and less error-prone (for adding additional
platforms that need SDL_main() in the future), to use the same check
for including SDL_main_impl.h as is used for `#define main SDL_main`
and only list the exceptions (currently Android) there explicitly.
If new platforms like Android turn up, they can easily be added there
by inserting "|| defined(SDL_PLATFORM_WEIRDPLATFORM)" right next
to the Android check.
See also https://github.com/libsdl-org/SDL/issues/11068#issuecomment-2399907535
Updates some documentation to correspond with changes made since it was originally written, clarifies some function behavior, and includes some assorted typo fixes.
This patch modifies the clipboard handling so that when we receive an external
clipboard update, the suppported mime types are included in the SDL_ClipboarUpdate
event. The patch also introduces the owner field that allows to know if the update
is because we own the clipboard (internal update) or if it was an external update.