Direct3D 9 dictates that caps.NumSimultaneousRTs must always be at least 1,
which is to say that Direct3D 9 level hardware must always support render
targets.
(caps.NumSimultaneousRTs is meant to show if you can draw to multiple render
targets in a single draw call.)
We had already hardcoded SDL_RENDERER_TARGETTEXTURE as available earlier in
the function anyhow.
Fixes#4781.
Some wayland compositors report the refresh rate as 0. Since we want to
force a minimum refresh rate of 10 frames worth, we were dividing by the
reported refresh rate, causing a divide-by-zero.
If the refresh rate is 0, instead force a frame every second if no frame
callbacks are received.
This fixes bug #4785
This will still happen occasionally as the mouse is whipped around, if there is a window overlapping the game window, but it should happen less often now. This could even happen with the original code that warped the mouse every frame, so this should be a good compromise where we don't warp the mouse continously and we still keep the mouse in the safe area of the game window.
Note that notifications can be any size, so the safe area may need to be adjusted or even dynamically defined via a hint.
We don't use it, it was a leftover from 1.2, I think, and it doesn't exist
on Solaris, so this should hopefully fix the build there.
This also means we don't need the configure/cmake checks for
SDL_VIDEO_DRIVER_X11_CONST_PARAM_XEXTADDDISPLAY, so that was removed also.
Fixes#1666.
One place known to differ in a significant way is a single line segment that
starts and ends on the same point; the GL renderers will light up a single
pixel here, whereas the software renderer will not. My current belief is this
is a bug in the software renderer, based on the wording of the docs:
"SDL_RenderDrawLine() draws the line to include both end points."
You can see an example program that triggers that difference in Bug #2006.
As it stands, the GL renderers might _also_ render diagonal lines differently,
as the the Bresenham step might vary between implementations (one does three
pixels and then two, the other does two and then three, etc). But this patch
causes those lines to start and end on the correct pixel, and that's the best
we can do, and all anyone really needs here.
Not closing any bugs with this patch (yet!), but here are several that it
appears to fix. If no other corner cases pop up, we'll call this done.
Reference Bug #2006.
Reference Bug #1626.
Reference Bug #4001.
...and probably others...
Vista and later provide the SleepConditionVariableCS() function for this.
Since SDL_syscond_srw.c doesn't require SRW locks anymore, rename it to
SDL_syscond_cv.c which better reflects the implementation of condition
variables rather than the implementation of mutexes.
Fixes#4051.
* Fixed: Whitespace being striped from the end of IME strings incorrectly
* Fixed: Google IME Candidate Window not placing correctly
* Why are PostBuild events stored in the vcxproj and not a user file?
* Revert SDL.vcxproj properly...
* Remove whitespace as per code review
* Fix Werror=declaration-after-statement error in code
In the future, we might want to support special swap intervals. To
prevent applications from expecting nonzero values of vsync to be the
same as "on", fail with SDL_Unsupported() if the value passed is neither
0 nor 1.
Currently, if an application wants to toggle VSync, they'd have to tear
down the renderer and recreate it. This patch fixes that by letting
applications call SDL_RenderSetVSync().
This is the same as the patch in #3673, except it applies to all
renderers (including PSP, even thought it seems that the VSync flag is
disabled for that renderer). Furthermore, the renderer flags also change
as well, which #3673 didn't do. It is also an API instead of using hint
callbacks (which could be potentially dangerous).
Closes#3673.
See SDL bug #4703. This implements two new hints:
- SDL_APP_NAME
- SDL_SCREENSAVER_INHIBIT_ACTIVITY_NAME
The former is the successor to SDL_HINT_AUDIO_DEVICE_APP_NAME, and acts
as a generic "application name" used both by audio drivers and DBUS
screensaver inhibition. If SDL_AUDIO_DEVICE_APP_NAME is set, it will
still take priority over SDL_APP_NAME.
The second allows the "activity name" used by
org.freedesktop.ScreenSavver's Inhibit method, which are often shown in
the UI as the reason the screensaver (and/or suspend/other
power-managment features) are disabled.
The recent change to make SDL_AUDIODRIVER support comma-separated lists
broke the previous behavior where an SDL_AUDIODRIVER that was empty
behaved the same as if it was not set at all. This old behavior was
necessary to paper over differences in platforms where SDL_setenv may
or may not actually delete the env var if an empty string is specified.
This patch just adds a simple check to ensure SDL_AUDIODRIVER is not
empty before using it, restoring the old interpretation of the empty
var.
Originally, SDL 1.2 used "pulse" as the name for its PulseAudio driver.
While it now supports "pulseaudio" as well for compatibility with SDL
2.0 [1], there are still scripts and distro packages which set
SDL_AUDIODRIVER=pulse [2]. While it's possible to remove this in most
circumstances or replace it with "pulseaudio" or a comma-separated list,
this may still conflict if the environment variable is set globally and
old binary builds of SDL 1.2 (e.g. packaged with older games) are being
used.
To fix this on SDL 2.0, add a hardcoded check for "pulse" as an audio
driver name, and replace it with "pulseaudio". This mimics what SDL 1.2
does (but in reverse). Note that setting driver_attempt{,_len} is safe
here as they're reset correctly based on driver_attempt_end on the next
loop.
[1] d951409784
[2] https://bugzilla.opensuse.org/show_bug.cgi?id=1189778
This change corrects the mappings for the Atari gamecontroller and
adds support for the Atari Xbox 360 compatible gamecontroller. The Atari
game controller can switch between Atari and Xbox 360 mappings.
This might have changed at some point in the Pulse API, or this might have
always been wrong, but we didn't notice because the dynamic loading code
hides it by casting things to void *. The static path, where it
assigns the function pointer directly, puts out a clear compiler warning,
though.
With Dear ImGui + software renderer, it draws:
- by default at 250 fps
- drops to 70 fps if you show the color picker
- drops to 10 fps if put the color picker fullscreen
There were a few places throughout the SDL code where values were
clamped using SDL_min() and SDL_max(). Now that we have an SDL_clamp()
macro, use this instead.
This was the original intent (note SDL_UpdateWindowGrab() in SDL_OnWindowFocusGained() and SDL_OnWindowFocusLost()) and fixes a bug where relative motion unexpectedly stops if the task bar is covering the bottom of the game window and the mouse happens to move over it while relative mode is enabled.
Another alternative would be to confine the mouse when relative mode is enabled, but that generates mouse motion which would need to be ignored, and it's possible for the user moving the mouse to combine with the mouse moving into the confined area so you can't easily tell whether to ignore the mouse motion. See https://github.com/libsdl-org/SDL/issues/4165 for a case where this is problematic.
This is the mouse focus except in the case where relative motion is enabled and the mouse is over a window floating on top of the application window (e.g. the taskbar)
This fixes restoring the cursor clip rectangle after the mouse has moved off of the window.
Also try to better synchronize cursor visibility with mouse position changes when changing relative mode. This doesn't work perfectly, but it seems to improve things on Windows.
Don't rely on checking __clang_major__ since it is not comparable
between different vendors. Don't use "#pragma clang attribute" since it
is only available in relatively recent versions, there's no obvious way
to check if it's supported, and just using __attribute__ directly (for
gcc as well) results in simpler code anyway.
If we are already in the desired mode, changing it is a no-op at best,
and harmful at worst: on Xwayland, it sometimes happens that we disable
the crtc and cannot re-enable it.
Resolves: https://github.com/libsdl-org/SDL/issues/4630
Signed-off-by: Simon McVittie <smcv@collabora.com>
- cmake, configure (CheckDLOPEN): --enable-sdl-dlopen is now history..
detach the dl api discovery from SDL_LOADSO_DLOPEN functionality.
define HAVE_DLOPEN. also define DYNAPI_NEEDS_DLOPEN (CheckDLOPEN is
called only for relevant platforms.)
- update SDL_config.in and SDL_config.cmake accordingly.
- SDL_dynapi.h: set SDL_DYNAMIC_API to 0 if DYNAPI_NEEDS_DLOPEN is
defined, but HAVE_DLOPEN is not.
- pthread/SDL_systhread.c: conditionalize dl api use to HAVE_DLOPEN
- SDL_x11opengl.c, SDL_DirectFB_opengl.c, SDL_naclopengles.c: rely
on HAVE_DLOPEN, not SDL_LOADSO_DLOPEN.
- SDL_config_android.h, SDL_config_iphoneos.h, SDL_config_macosx.h,
SDL_config_pandora.h, and SDL_config_wiz.h: define HAVE_DLOPEN.
Closes: https://github.com/libsdl-org/SDL/pull/4351
Without this change, driver names don't get matched correctly;
for example "a" can get matched with "alsa" since it only checks
whether the string matches up to the length of the requested
driver name.
Without this change, driver names don't get matched correctly;
for example "x" can get matched with "x11" since it only checks
whether the string matches up to the length of the requested
driver name.
b08b1bde introduced a subtle bug. Despite not using D-Bus types directly,
the code used the SDL_USE_LIBDBUS definition set by SDL_dbus.h to conditionally
compile calls SDL_DBus_ScreensaverTickle() and SDL_DBus_ScreensaverInhibit().
As a result, it still compiled without SDL_dbus.h included, but screensaver
suspension silently failed to work.
The D-Bus stuff could probably use some tweaks to be harder to accidentally
break, but for now just restore the header includes.
Configure events from compositors have an extremely annoying habit of giving us
completely bogus sizes, from all sorts of places. Thankfully, the protocol
gives us the ability to completely ignore the width/height and just stick with
what we know, so for all windows that are not meant to be resized, pretend we
never even got the width/height at all, the compositor is required to respect
our dimensions whether they match configure's suggestion or not.
Otherwise only the display resolution is changed, but the SDL window size
(and for example the window-surface size) aren't adjusted accordingly
and thus don't fill the whole screen.
See #3313
.. and maybe other platforms as well (though X11 was not affected)?
The issue was that passing a higher resolution than the current desktop
resolution to SDL_CreateWindow() with SDL_WINDOW_FULLSCREEN didn't switch
to that resolution (even though it did switch to lower resolutions).
When creating a fullscreen window, window->fullscreen wasn't even set
at all (only zeroed out), setting it only happened if the user explicitly
called SDL_SetWindowDisplayMode(). So without that, SDL_CreateWindow()
-> SDL_UpdateFullscreenMode() -> SDL_GetWindowDisplayMode() used the
resolution from window->windowed.w/h which were limited to the desktop size
due to some weird combination of WIN_AdjustWindowRectWithStyle() and
WIN_WindowProc() being called after a call to SetWindowPos().
fixes#3313
This prevents a race if two threads that need d-bus try to init it at the
same time. Note that SDL_Init will likely handle this from a single thread
at startup, but there are places outside of init where one might trigger
D-Bus init, like setting thread priority (a common first thing for a new
thread to do) resulting in SDL trying to use RTKit.
Fixes#4587.
This reintroduces the fix from 0e16ee8330, but just marks
the viewport state as dirty after a clear that needs to expand the
viewport to fill the render target, as we'll need to also reset
the orthographic projection state elsewhere, and that won't
happen if we clear the dirty flag here.
Fixes#4210.
(again.)
(...sorry...!)
The Renderer logical scaling code scales mouse coordinates, and needs to
take the window DPI into account on HIGHDPI windows. However, the
variable which tracks this, renderer->dpi_scale, is set once when the
renderer is created, and then not updated. In the event that the window
is moved to another screen, or the screen DPI otherwise changes, this
will be outdates, and potentially the coordinates will be all wrong.
So let's update the dpi_scale on the SIZE_CHANGED event: it's at least a
possibility that this will be issued on some OSes when DPI changes, and
it's otherwise already handled by SDL_Renderer's event filter.
Otherwise you might have set the viewport to the full size of
the render target in SDL's API but this change hasn't been
transmitted to Direct3D yet by the time we attempt to clear.
Fixes#4210.
SDL_AddHintCallback() uses SDL_malloc(), which means this would
run before main(), so the app wouldn't be able to supply its own
replacement SDL_malloc() implementation in time.
This code was moved to under SDL_Init. Since the hint callback
already makes efforts to not override the app manifest's
orientation settings, this is safe to move until after pre-main()
startup.
Fixes#4449.
This removes the CM_Register_Notification code on WinRT. Note
that this API _is_ available to UWP apps as of Windows 10.0.17763
(version 1809, released October 2018), according to:
https://docs.microsoft.com/en-us/uwp/win32-and-com/win32-apis#apis-from-api-ms-win-devices-config-l1-1-1dll
So it might be worth readding with some sort of preprocessor check
for minimum targeted version, or whatever is appropriate for WinRT
development.
This was causing configure events to not inform SDL of window size
changes, even when they were based on resizes that we fully expected. The
result was fullscreen->windowed not working at all, because it would
retain the desktop resolution instead of reverting to the floating size
that it had before moving to fullscreen mode.
Fixes Super Hexagon fullscreen toggling.
The flush has been removed in e5f9fae034.
Unfortunately, even though ideally the flush shouldn't be necessary,
our resize sequence isn't... well, perfect, and removing that flush causes
tons of troubles.
We're also still flushing in other paths where the window size can be
changed by the compositor and where we may potentially have to obey that
change, like in Wayland_MaximizeWindow.
This also removes the hack introduced in 7f261d3b76,
which introduces problems with protocol violations and seems to not be
necessary when flushing.
We have issues with correct resize sequence and happen to commit old-sized
buffers even after configure event for the new size has been already
acknowledged. While the reason for that stays unknown, let's at least
workaround the problem by faking window geometry into expected size.
This does not fix visual glitch on e.g. fullscreen toggling, but having
a split-second glitch is still a much better outcome than being
terminated by the compositor for protocol violation.
This was causing window changes to completely break, resulting in broken
decorations and bizarre frame timing, I don't know what exactly it's doing
but it's not good. Kept the libdecor_frame_is_floating logic, at least.
Commit 871c11191b removed delayed
resize handling, but it left the whole structure untouched that
now became unnecessary. To help with code clarity, get rid
of the structure where pending resize state used to be stored
and pass all the data directly to Wayland_HandlePendingResize
(now renamed to Wayland_HandleResize, since it's not "pending"
anymore but applied immediately)
Otherwise our windows have no window decoration on compositors that
support xdg-decoration-unstable-v1, but default to client-side mode.
Contrary to what the comment was stating, there is nothing in the protocol
that would make redundant calls to zxdg_toplevel_decoration_v1::set_mode
problematic.
Some Wayland compositors send (0,0) as "suggested" configure event sizes to
indicate that the client has to decide on its own which sizes to used. This
is commonly done when restoring from maximised, fullscreen or tiles states
to fullscreen.
We now store the last known floating states in a new set of variables and
restore them when we receive such a (0,0) configure event.
From the vfork manpage:
> The vfork() function has the same effect as fork(2), except that
> the behavior is undefined if the process created by vfork() either
> modifies any data other than a variable of type pid_t used to store
> the return value from vfork(), or returns from the function in which
> vfork() was called, or calls any other function before successfully
> calling _exit(2) or one of the exec(3) family of functions.
unsetenv is still called inside a child process, so it does not
influence the rest of the application.
This fixes a crash on pressing keyboard button when compositor sends
zero as repeat rate, indicating that key repeat should be disabled.
From Wayland protocol spec:
> Negative values for either rate or delay are illegal. A rate of zero
> will disable any repeating (regardless of the value of delay).
This is a workaround and not a proper fix, but this is possibly complicated,
and possibly a corner case, so this will do for 2.0.16, if not the
foreseeable future.
Reference issue #4561
When we removed the OpenGL resize workaround it introduced a problem for
fullscreen windows in particular: When leaving fullscreen we tried to send a
resize event, but UpdateFullscreenMode would send a SIZE_CHANGED immediately
after, deleting our resize event and causing the following configure event's
resize to be ignored. This timing issue resulted in fullscreen windows not
being resized at all when becoming a floating window.
By always forcing resize events from configure events, we ensure that RESIZED
always makes it through. SetWindowSize-type changes should be unaffected as
they do not fire configure events.
The RenderDrawLinesWithRects and RenderDrawLinesWithRectsF functions can
sometimes call QueueCmdFillRects() with the data pointed to by frects
uninitialised. This can occur if none of the lines can be replaced with
rects, in which case the frects array is empty, and nrects is 0.
gcc 10.3.0 will detect this possibility, and print a warning like:
/home/david/Development/SDL/src/render/SDL_render.c: In function 'RenderDrawLinesWithRectsF':
/home/david/Development/SDL/src/render/SDL_render.c:2725:15: warning: '<unknown>' may be used uninitialized [-Wmaybe-uninitialized]
2725 | retval += QueueCmdFillRects(renderer, frects, nrects);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/david/Development/SDL/src/render/SDL_render.c:499:1: note: by argument 2 of type 'const SDL_FRect *' to 'QueueCmdFillRects' declared here
499 | QueueCmdFillRects(SDL_Renderer *renderer, const SDL_FRect * rects, const int count)
| ^~~~~~~~~~~~~~~~~
This is harmless, because when this is uninitialised, nrects is always
0, so QueueCmdFillRects() does nothing anyway. We therefore can work
around this by only calling QueueCmdFillRects() when nrects is nonzero.
Somewhat impressively, gcc recognises that this is now safe.
Sam Lantinga
Sylvain
Cameron Cawley
Ryan C. Gordon
Ethan Lee
Martin Mauersics
David Gow
Northfear
Cacodemon345
pkubaj
Ivan Epifanov
Cameron Gutman
Alex R
Zach Reedy
Misa
Jaylon Gowie
Zach Reedy
Rokas Kupstys
Lee Salzman
Vanfanel
Eric Engestrom
Shawn Ellis
Oschowa
Ozkan Sezer
Aleksey Rybalkin
Jānis Rūcis
Joseph Kogut
Charlie Birks
Charlie Birks
Joshua Root
Simon McVittie
Andrei Alexeyev
hgs3
Sebastian Krzyszkowiak
Daniel Gibson
Christian Rauch