Carlos
Angle supports GLES3 but when using these functions (SDL_CreateWindow and SDL_CreateRenderer), defaults again to GLES2.0.
A current workaround (hack) to retrieve a GLES3.0 context with Angle is:
1) set
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 3);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 0);
after InitSDL AND after calling SDL_CreateWindow (before SDL_CreateRenderer)
2) Comment lines 2032-2044 in SDL_render_gles2.c, funtion GLES2_CreateRenderer
window_flags = SDL_GetWindowFlags(window);
if (!(window_flags & SDL_WINDOW_OPENGL) ||
profile_mask != SDL_GL_CONTEXT_PROFILE_ES || major != RENDERER_CONTEXT_MAJOR || minor != RENDERER_CONTEXT_MINOR) {
changed_window = SDL_TRUE;
SDL_GL_SetAttribute(SDL_GL_CONTEXT_PROFILE_MASK, SDL_GL_CONTEXT_PROFILE_ES);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, RENDERER_CONTEXT_MAJOR);
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, RENDERER_CONTEXT_MINOR);
if (SDL_RecreateWindow(window, window_flags | SDL_WINDOW_OPENGL) < 0) {
goto error;
}
}
This retrives a GLES3 context as confirmed using glGetString(GL_VERSION). This should be fixed by modifying a few if's.
Ozkan Sezer
In my cross-build environment with cmake-2.8.12.1, cmake does not add
SDL_coreaudio.m to its makefiles and the result is a failure. The fix
is simple: set the language to C for it as it is done at other places
in CMakeLists.txt.
Ozkan Sezer
Since changeset 11607:60cd425a2f14, I am getting the following
error upon quit. Running testsprite2, clicking the mouse, and
quiting it is enough to trigger it. This is on my old Fedora9
x86-Linux:
X Error of failed request: BadCursor (invalid Cursor parameter)
Major opcode of failed request: 2 (X_ChangeWindowAttributes)
Resource id in failed request: 0xb057340
Serial number of failed request: 905
Current serial number in output stream: 906
Reverting https://hg.libsdl.org/SDL/rev/60cd425a2f14 removes
the error.
The audioqueue thread needs to keep running, and processing the CFRunLoop
until the AudioQueue is disposed of, otherwise CoreAudio will hang waiting for
final data to feed the device.
At least, I think this is how it all works. It definitely fixes the bug here!
Since AudioQueueDispose() calls AudioQueueStop() internally, there's no need
for our thread to handle this, either, which is good because the AudioQueue
would be disposed by this point. So now the AudioQueue is disposed first, and
then our thread is joined, and everything works out okay.
Just in case, we mark the device "paused" before setting everything in motion,
so any further callbacks from CoreAudio will write silence and not fire the
app's audio callback again.
Fixes Bugzilla #3868.
Steve Robinson
In my project, the 'uninstall' target is already created by the glew library. I get this error when SDL2 tries to create it:
CMake Error at _build/3rdparty/SDL2/SDL2-2.0.6/CMakeLists.txt:1816 (add_custom_target):
add_custom_target cannot create target "uninstall" because another target
with the same name already exists. The existing target is a custom target
created in source directory
"D:/Code/sdl2-tutorial/_build/3rdparty/glew/glew-2.1.0/build/cmake". See
documentation for policy CMP0002 for more details.
To fix it, go to the bottom of the SDL2 CMakeLists.txt file. Add an if statement to check for the existence of the target before creating it. The end result looks like this:
if(NOT TARGET uninstall)
configure_file(
"${CMAKE_CURRENT_SOURCE_DIR}/cmake_uninstall.cmake.in"
"${CMAKE_CURRENT_BINARY_DIR}/cmake_uninstall.cmake"
IMMEDIATE @ONLY)
add_custom_target(uninstall
COMMAND ${CMAKE_COMMAND} -P ${CMAKE_CURRENT_BINARY_DIR}/cmake_uninstall.cmake)
endif()
This is how the glew library deals with this possibility in their CMakeLists.txt file.
Steve Robinson
When I try to build the 'uninstall' target in CMake when SDL2 is added to a subdirectory of my project, I get this error:
1>CMake Error at cmake_uninstall.cmake:2 (message):
1> Cannot find install manifest:
1> "D:/Code/sdl2-tutorial/_build/3rdparty/SDL2/SDL2-2.0.6/install_manifest.txt"
The install_manifest.txt is actually in the top-level binary directory, not the project-specific binary directory.
To fix it, change all instances of:
CMAKE_CURRENT_BINARY_DIR
To:
CMAKE_BINARY_DIR
In:
cmake_uninstall.cmake.in
Trent Gamblin
The documentation for SDL_TouchFingerEvent says that the x and y coordinates are normalised between 0-1. I've found that to be true on Windows, Android and iOS but on X11 they are in pixel coordinates. This patch fixes the issue. This was the cleanest way I could do it with what was available without changing things around a lot but you may know a better way.
(I thought padding size ranged from 5 frames to ~30 frames (based around
RESAMPLER_ZERO_CROSSINGS, which is 5), but it's actually between 512 and
several thousands (based on RESAMPLER_SAMPLES_PER_ZERO_CROSSING)). It gets
big fast when downsampling.
Manuel
I would like this small patch merged that adds support for my GreenAsia Inc. PSX to USB converter, so SDL_IsGameController() returns true when using this adaptor.
It's interesting because PSX/PS2 controllers connected using this model won't be detected as gamecontrollers otherwise, only as joysticks.
Sylvain
There are various YUV-RGB conversion coefficients, according to https://www.fourcc.org/fccyvrgb.php
I choose the first (from Video Demystified, with integer multiplication),
but the current SDL2 Dither functions use in fact the next one, which follows a specifications called CCIR 601.
Here's a patch to use the second ones and with previous warning corrections.
There are less multiplications involved because Chroma coefficient is 1.
Also, doing float multiplication is as efficient with vectorization.
In the end, the YUV decoding is faster: ~165 ms vs my previous 195 ms.
Moreover, if SDL2 is compiled with -march=native, then YUV decoding time drops to ~130ms, while older ones remains around ~220 ms.
For information, from jpeg-9 source code:
jpeg-9/jccolor.c
* YCbCr is defined per CCIR 601-1, except that Cb and Cr are
* normalized to the range 0..MAXJSAMPLE rather than -0.5 .. 0.5.
* The conversion equations to be implemented are therefore
* Y = 0.29900 * R + 0.58700 * G + 0.11400 * B
* Cb = -0.16874 * R - 0.33126 * G + 0.50000 * B + CENTERJSAMPLE
* Cr = 0.50000 * R - 0.41869 * G - 0.08131 * B + CENTERJSAMPLE
jpeg-9/jdcolor.c
* YCbCr is defined per CCIR 601-1, except that Cb and Cr are
* normalized to the range 0..MAXJSAMPLE rather than -0.5 .. 0.5.
* The conversion equations to be implemented are therefore
*
* R = Y + 1.40200 * Cr
* G = Y - 0.34414 * Cb - 0.71414 * Cr
* B = Y + 1.77200 * Cb
