Simon Hug
All OpenGL renderers always flip the rows of the pixels that come from glReadPixels. This is unnecessary for target textures since these are already top down.
Also, the rect->y value can be used directly for target textures for the same reason. I don't see any code that would handle the logical render size for target textures. Or am I missing something?
The attached patch makes the renderers only the flip rows if the data comes from the default framebuffer.
Simon Hug
The current SDL_SaveBMP_RW function that saves surfaces to a BMP uses an old bitmap header which doesn't officially support alpha channels. Applications just ignore the byte where the alpha is stored. This can easily be extended by using a newer header version and setting the alpha mask.
The attached patch has these changes:
- Extending the description of the function in the SDL_surface.h header with the supported formats.
- Refining when surfaces get stored to a 32-bit BMP. (Must have bit depth of 8 or higher and must have an alpha mask or colorkey.)
- Fixing a small bug that saves 24-bit BGR surfaces with a colorkey in a 24-bit BMP.
- Adding code that switches to the bitmap header version 4 if the surface has an alpha mask or colorkey. (I chose version 4 because Microsoft didn't lose its documentation behind a file cabinet like they did with version 3.)
- Adding a hint that can disable the use of the version 4 header. This is for people that need the legacy header or like the old behavior better. (I'm not sure about the hint name, though. May need changing if there are any rules to that.)
Simon Hug
The GL_SetBlendMode and GLES_SetBlendMode functions of the opengl and opengles renderers call the glTexEnvf to set the texture env mode to either GL_MODULATE (the default) or GL_REPLACE for the NONE blend mode. Using GL_REPLACE disables color and alpha modulation for textures.
These glTexEnv calls were put in the SetBlendMode function back in 2006 [1], but there the NONE code still used the GL_DECAL mode. The GL_REPLACE mode came in 2008 [2]. I'm a bit confused why that wasn't always GL_MODULATE and a bit surprised nobody reported that yet (unless I missed it). I guess only a few use the gles renderer and the newish shaders mask the issue.
Simon Hug
The GL_CreateTexture function doesn't have any checks for the case where the driver doesn't support the framebuffer object extension. It will call into GL_GetFBO which will call the non-existent glGenFramebuffersEXT.
Also, for some reason GL_CreateContext always sets the SDL_RENDERER_TARGETTEXTURE info flag, even if it is not supported. Changeset 6e6bd53feff0 [1] makes this change, but doesn't explain why. It seems to me like the code would already have taken care of this [2].
The attached patch adds some checks and stops SDL from reporting render target support if there is none. The application can then properly inform the user instead of just crashing.
Simon Hug
When the SDL_Blit_Slow function compares the pixel to the color key it does so without removing the alpha component from the pixel value and the key. This is different from the optimized 32-bit blitters which create a rgb mask and apply it to both to filter the alpha out. SDL_Blit_Slow will only skip the pixels with the exact alpha value of the key instead of all pixels with the same color.
The attached test case blits a surface with a color key and prints the pixel values to the console. The third row is expected to be skipped.
Simon Hug
It seems not everyone implemented glDrawTexfOES the same. Intel and Mesa ignore the viewport entirely, whereas the Raspberry Pi implementation offsets the coordinates and does viewport clipping.
The glDrawTexfOES extension text [1] for the function says "Xs and Ys are given directly in window (viewport) coordinates." I guess this wasn't clear enough.
Alex Szpakowski
Honestly I'd probably remove that codepath from SDL_Render entirely. It's an OpenGL ES 1-specific extension that isn't likely to give huge performance gains and adds additional maintenance overhead to SDL_Render while also having bugs in some drivers (as seen here).
SFC30 controller: http://www.8bitdo.com/sfc30/
The SFC30 controller can present itself in a variety of modes and it offers up
different names in each. This patch captures data for three modes (one USB and
two Bluetooth) on three platforms (Mac OS X, Windows, Linux).
However, USB mode on Linux and Windows is missing as the button events did not
make it through to SDL's controllermap tool on Fedora 24/Linux 4.5.5 nor Steam
Big Picture mode on Windows. The two Bluetooth modes were indistinguishable on
Windows. Two modes on OS X were indistinguishable.
There exists a similar controller called the SNES30 (And some others) that are
very likely identical except for the name, but I have not verified this yet so
haven't synthesized lines for those controllers until I can.
Kai Sterker
There are already patches available from mingw64 that fix the issue
https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-SDL2
With those applied, I could compile SDL2 without problems. But of course, it would be preferable if SDL built cleanly from source.
Vitaly Novichkov
Line 124
====================================================================
const DWORD flags = thread->stacksize ? STACK_SIZE_PARAM_IS_A_RESERVATION : 0;
====================================================================
Error of compiler:
====================================================================
CC build/SDL_systhread.lo
src/thread/windows/SDL_systhread.c: In function 'SDL_SYS_CreateThread':
src/thread/windows/SDL_systhread.c:124:45: error: 'STACK_SIZE_PARAM_IS_A_RESERVA
TION' undeclared (first use in this function)
const DWORD flags = thread->stacksize ? STACK_SIZE_PARAM_IS_A_RESERVATION :
0;
^
src/thread/windows/SDL_systhread.c:124:45: note: each undeclared identifier is r
eported only once for each function it appears in
make: *** [build/SDL_systhread.lo] Error 1
====================================================================
Fixing when I adding into begin of the file:
====================================================================
#ifndef STACK_SIZE_PARAM_IS_A_RESERVATION
#define STACK_SIZE_PARAM_IS_A_RESERVATION 0x00010000
#endif
====================================================================
The Apple TV remote is currently exposed as a joystick with its touch surface treated as two axes. Key presses are also generated when its buttons and touch surface are used.
A new hint has been added to help deal with deciding whether to background the app when the remote's menu button is pressed: SDL_HINT_APPLE_TV_CONTROLLER_UI_EVENTS.
Previously when the canvas was scaled up and the pointer was locked,
motion corresponding to less than one pixel was lost. Therefore,
slow mouse motion resulted in no motion. This fixes that.
Browsers don't have the functionality to fully support the generic
SDL_ShowMessageBox(), but this handles the likely most-common case.
Without this, you'd return immediately with a proper error result and no UI,
but probably no one checks that for SDL_ShowSimpleMessageBox. And if they
did: what would they do to handle this anyhow?
We'd need to lobby for an HTML spec of some sort that allows customizable
message boxes--that block!--to properly support SDL message boxes on
Emscripten, but this is probably Good Enough for now.
AudioQueues are available in Mac OS X 10.5 and later (and iOS 2.0 and later).
Their API is much more clear (and if you don't mind the threading tapdance
to get its own CFRunLoop) much easier to use in general for our purposes.
As an added benefit: they seemlessly deal with format conversion in ways
AudioUnits don't: for example, my MacBook Pro's built-in microphone won't
capture at 8000Hz and the AudioUnit version wouldn't resample to hide this
fact; the AudioQueue version, however, can handle this.
Generate the C protocol files from the protocol XML files installed by
wayland-protocols, and use them to implement support for relative pointer
motions and pointer locking.
Note that at the time, the protocol is unstable and may change in the future.
Any future breaking changes will, however, fail gracefully and result in no
regressions compared to before this patch.
Since we are loading shared objects dynamically, build our own version of the
core protocol symbols, so that we in the future can include protocol
extensions.
This will be used by Wayland compositors to match the application ID and
.desktop file to the SDL window(s).
Applications can set the SDL_VIDEO_WAYLAND_WMCLASS environemnt variable
early in the process to override using the binary name as a fallback.
Note that we also support the SDL_VIDEO_X11_WMCLASS in the Wayland
backend so that if a program correctly associated the desktop file with
the window under X11, only a newer SDL would be needed for it to work
under Wayland.
https://bugzilla.libsdl.org/show_bug.cgi?id=3376
Author: James Zipperer <james.zipperer@synapse.com>
Date: Sun Aug 21 01:19:19 2016 -0700
bugfix for controller / joystick add / remove being in the event queue at the same time
The repro steps were this:
1. run an sdl2 winrt/uwp app, on Win10, v10.0.10586.0 or higher
2. hide the cursor, via a call to SDL_ShowCursor(0)
3. make the Win10 game bar appear, by pressing the Windows + G hotkey
4. observe that the mouse cursor appears, in order to interact with the
game bar (this is expected behavior)
5. make the Win10 game bar disappear, either by pressing the Windows + G hotkey
again, or clicking somewhere in the app
EXPECTED RESULT: cursor disappears, as game bar disappears
ACTUAL RESULT: cursor didn't always disappear
Moved this code from winmm into core so both can use it.
DirectSound (at least on Win10) also returns truncated device names, even
though it's handed in as a string pointer and not a static-sized buffer. :/
The Windows 10 Anniversary Update (1607) breaks the method uses that SDL uses to
detect XInput devices. That is, on Windows 10 Anniversary Update, it is no longer
possible to query RAWINPUT for HID devices, and check for "IG_" in the device name.
Presumably, this will be fixed in the future.
This patch works around the issue by adding the Xbox One controller series to the
well-known device list.
This skips the more expensive RAWINPUT check for those devices, and causes them to
be detected as XInput devices once again.
Otherwise, if you had a massive, one-time queue buildup, the memory from that
remains allocated until you close the device. Also, if you are just using a
reasonable amount of space, this would previously cause you to reallocate it
over and over instead of keeping a little bit of memory around.
I think this was important for SDL 1.2 because some targets needed
special device memory for DMA buffers or locked memory buffers for use in
hardware interrupts or something, but since it just defines to SDL_malloc
and SDL_free now, I took it out for clarity's sake.
- It's now always called if device->hidden isn't NULL, even if OpenDevice()
failed halfway through. This lets implementation code not have to clean up
itself on every possible failure point; just return an error and SDL will
handle it for you.
- Implementations can assume this->hidden != NULL and not check for it.
- implementations don't have to set this->hidden = NULL when done, because
the caller is always about to free(this).
- Don't reset other fields that are in a block of memory about to be free()'d.
- Implementations all now free things like internal mix buffers last, after
closing devices and such, to guarantee they definitely aren't in use anymore
at the point of deallocation.
Turns out that libartsc isn't thread-safe, so if we run a capture and playback
device at the same time, it often crashes in arts's internal event loop.
We could throw mutexes around the read/write calls, but these are meant to
block, so one device could cause serious latency and stutter in the other.
Since this audio target isn't in high-demand (Ubuntu hasn't offered a libartsc
package for years), I'm just backing out the capture support. If someone needs
it, they can pull it out of the revision history.
(We probably never noticed because this is meant to block until it fully
writes a buffer, and would only trigger an issue if we had a short write
that wasn't otherwise an error condition.)
