Update SDL2 port with latest changes from upstream #8
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This lets applications embed SDL with other widgets surrounding it. Already possible on Windows and X11. Fixes Bugzilla #5060. --HG-- extra : rebase_source : 4e31c8c5b15cf001b3f4eae63d79e1620b351b67
Anthony Pesch's notes on his patch: "Currently, the WASAPI backend creates a stream in shared mode and sets the device's callback size to be half of the shared stream's total buffer size. This works, but doesn't coordinate will with the actual hardware. The hardware will raise an interrupt after every period which in turn will signal the object being waited on inside of WaitDevice. From my empirical testing, the callback size was often larger than the period size and not a multiple of it, which resulted in poor latency when trying to time an application based on the audio callback. The reason for this looked something like: * The device's callback would be called and and the audio buffer was filled. * WaitDevice would be called. * The hardware would raise an interrupt after one period. * WaitDevice would resume, see that a a full callback had not been played and then wait again. * The hardware would raise an interrupt after another period. * WaitDevice would resume, see that a full callback + some extra amount had been played and then it would again call our callback and this process would repeat. The effect of this is that the pacing between subsequent callbacks is poor - sometimes it's called very quickly, sometimes it's called very late. By matching the callback's size to the stream's period size, the pacing of calls to the user callback is improved substantially. I didn't write an actual test for this, but my use case for this was my Dreamcast emulator (https://redream.io) which uses the audio callback to help drive the emulation speed. Without this change and with the default shared stream buffer (which has a period of ~10ms) I would get frame times that were between ~3-30 milliseconds; after this change I get frame times of ~11-22 milliseconds. Note, this patch also has a change that removes passing a duration to the Initialize call. It seems that the default duration used (when 0 is passed) does typically match up with the duration returned by GetDevicePeriod, however the Initialize docs say: > To set the buffer to the minimum size required by the engine thread, the > client should call Initialize with the hnsBufferDuration parameter set to 0. > Following the Initialize call, the client can get the size of the resulting > buffer by calling IAudioClient::GetBufferSize. This change isn't strictly required, but I made it to hopefully rule out another source of unexpected latency." Fixes Bugzilla #4592. --HG-- extra : histedit_source : cc22ed774514f2596fed80632d7f6d60035b6b95
In order to generate meaningful output from SDL_GetRevision()
The first terminator is for input parameters. The second terminator was for the output parameters. If an error occurs when calling MakeThreadHighPriority(), e.g. a bad thread id, then the reply from connection_send_with_reply_and_block() will be null.
…there's some activity, not saturation - only force it on if the analog value is 0.
This does not account for scrollbars nor margins. But is much better then returning the full display size when not running fullscreen, but for example in an iframe.
Fixes pointer lock with DISABLE_DEPRECATED_FIND_EVENT_TARGET_BEHAVIOR=1
…leb!). Caleb Cornett's comments: "A few weeks ago, Alex added a partial Metal API to SDL2: https://hg.libsdl.org/SDL/rev/b87ba0fad17e I noticed it was missing a few features that would help Metal become a first-class citizen in SDL, so I went ahead and wrote them! Here are the new APIs: 1. SDL_WINDOW_METAL flag for SDL_CreateWindow(). This allows the programmer to specify that they intend to create a window for use with SDL_MetalView. The flag is used to ensure correct usage of the API and to prevent accidentally defaulting to OpenGL on iOS. 2. SDL_Metal_GetLayer(). This function takes a SDL_MetalView and returns a pointer to the view's backing CAMetalLayer. This simplifies things considerably, since in the current version of the SDL_Metal API the programmer is required to bridge-cast a SDL_MetalView handle to an NSView or UIView (depending on the platform) and then extract the layer from there. SDL_Metal_GetLayer automatically handles all of that, making the operation simple and cross-platform. 3. SDL_Metal_GetDrawableSize(). This function already exists in the current SDL_Metal API (and is used behind-the-scenes for SDL_Vulkan_GetDrawableSize on Apple platforms) but was not publicly exposed. My patch exposes this function for public use. It works just like you'd expect. Tested on macOS 10.14 and iOS 12.4." Fixes Bugzilla #4796.
From hmk: "When scaling is enabled (e.g. via SDL_RenderSetLogicalSize, size not equal to window size), mouse motion events are also scaled. Small motions are rounded up (SDL_max() when the value after scaling is less than 1), while larger motions are truncated by the floating point -> integer conversion. https://hg.libsdl.org/SDL/file/18ede62f3f14/src/render/SDL_render.c#l658 The end result feels something like mouse reverse mouse acceleration + angle snapping at low speeds, but less consistent (amount of truncation & rounding depends on how fast the mouse is moved) and potentially much worse if the scaling factor is large. This pretty much makes it useless for anything where you need precise mouse aiming (think of games). I suspect this is why aiming gets so terrible in some games that let you use scaling to reduce the render resolution (e.g. Ion Fury). With 4x4 scaling, I can reproduce a situation where it takes three fast flicks of the mouse across the pad to undo one slow sweep across the pad. In other words, extreme reverse acceleration. This does not happen when scaling is disabled. Furthermore, any game that uses relative mouse motion events for 3D camera rotation probably wants the raw mouse deltas and not a value that depends on scaling and resolution and rounding and truncation. Ideal camera rotation just takes mouse input, multiplies it by sensitivity, and adds it to the angle-in-radians or whatever measure is used for yaw & pitch. Pixels and screen resolution or window dimensions should not be a part of the equation at all, even if it could be implemented without rounding errors. [...] This [patch] completely eliminates angle snapping for me, and makes sensitivity consistent. In other words, it's completely usable for, say, aiming in a first person shooter." Partially fixes Bugzilla #4811. --HG-- extra : histedit_source : 9ddb125b0f448d9bba5c3ba73c22babafbbab2ad
Fixes Bugzilla #4811.
pkg-config already prepends Libs to Libs.private when you specify --static so there's no need to duplicate them. Most other projects don't do this.
This behavior matches SDL_RecreateWindow and makes it less likely that another piece of code (e.g. a DestroyWindowFramebuffer implementation) will attempt to use or free the stale surface pointer.
…upport (thanks DominikD!)
A project being built entirely statically will call pkg-config with --static, which utilises the Libs.private field. Conversely it will not use --static when not being built entirely statically, even if there is only a static build of SDL available. This will most likely cause the build to fail due to underlinking unless we merge the Libs fields. This is what the Meson build system does when it generates pkg-config files. This also also follows the behaviour of sdl2-config. At the same time, the runtime linker flags are not applicable to static-only builds so only add them for shared builds.
…artin!). This allows you to bind surfaceless contexts on a background thread to, for example, load assets in a separate context, for platforms that have different requirements about sharing surfaces, etc. Martin's notes on the matter: "Here's a patch that enables passing NULL windows to SDL_GL_MakeCurrent, if the involved APIs allow it. Currently, this is only the case for EGL, and even then only if some specific extensions are present (which they usually are). If "surfaceless" contexts are not supported, SDL_GL_MakeCurrent continues to generate an error (albeit with a more specific error message than it used to), so this should not break anything that wasn't broken before." (Please see https://bugzilla.libsdl.org/show_bug.cgi?id=3695 for more discussion.) Fixes Bugzilla #3695.
Solves a crash in OpenClaw.
|
@WinterMute done! |
|
There are conflicts |
Yes. It should be rebased and force pushed. This keeps the local history together until it gets upstreamed (assuming it does at some point) making local maintenance easier. Merging upstream to a fork ends up with a local history intermingled with upstream commits & makes it harder to follow the changes. |
|
Exactly, @mirh, there are conflicts because both branches (my I'm not the owner of this repo. I think rebasing is better, as @WinterMute suggests, but if whoever is responsible of merging this prefers a merge commit, I can offer both approaches 🤷♂️ |
|
Yes don't worry about the conflicts. Let me test this and then force-push when I verify it all works. I might also create a new branch for this, I will think about it. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This massive PR comes from
mergingrebasing this portwithon top of https://github.com/spurious/SDL-mirror and making changes to use the new internal API.As you can see the changes are massive, but only a few are actual changes on this port. I'll add comments to the relevant parts (which belong to this changeset: https://github.com/sergiou87/SDL-Vita/compare/c6281eb..726296f)
So far I've only tested this in my project https://github.com/sergiou87/open-supaplex/ and all worked perfectly