Jonas Kulla
The configure script didn't differentiate between Linux and Android, unconditionally compiling in the unix implementation of SDL_sysfilesystem.c.
I'm probably one of the very few people building SDL for android using classic configure + standalone toolchain, so this has gone undetected all along.
With this commit, you can compile SDL2 with Emscripten
( http://emscripten.org/ ), and make your SDL-based C/C++ program
into a web app.
This port was due to the efforts of several people, including: Charlie Birks,
Sathyanarayanan Gunasekaran, Jukka Jylänki, Alon Zakai, Edward Rudd,
Bruce Mitchener, and Martin Gerhardy. (Thanks, everyone!)
binarycrusader
Since changeset 358696c354a8, SDL 2.0 has been broken on Solaris when compiling with the Solaris Studio compiler (which uses the pthread implementation of SDL_AtomicLock).
Notably, it gets stuck at the MemoryBarrierRelease in SDL_GetErrBuf:
6585 # 218
6586 if (!tls_errbuf && !tls_being_created) {
6587 SDL_AtomicLock_REAL ( & tls_lock );
6588 if (!tls_errbuf) {
6589 SDL_TLSID slot;
6590 tls_being_created = SDL_TRUE;
6591 slot = SDL_TLSCreate_REAL ( );
6592 tls_being_created = SDL_FALSE;
6593 { SDL_SpinLock _tmp = 0 ; SDL_AtomicLock_REAL ( & _tmp ) ; SDL_AtomicUnlock_REAL ( & _tmp ) ; };
^^^ loops forever above
6594 tls_errbuf = slot;
6595 }
6596 SDL_AtomicUnlock_REAL ( & tls_lock );
6597 }
Running: testthread
(process id 28926)
^Cdbx: warning: Interrupt ignored but forwarded to child.
signal INT (Interrupt) in __nanosleep at 0xfe52a875
0xfe52a875: __nanosleep+0x0015: jae __nanosleep+0x23 [ 0xfe52a883, .+0xe ]
Current function is SDL_Delay_REAL
204 was_error = nanosleep(&tv, &elapsed);
(dbx) where
[1] __nanosleep(0xfeffe848, 0xfeffe850, 0xfe75a5ac, 0xfe5169d8), at 0xfe52a875
[2] nanosleep(0xfeffe848, 0xfeffe850), at 0xfe516a3b
=>[3] SDL_Delay_REAL(ms = 0), line 204 in "SDL_systimer.c"
[4] SDL_AtomicLock_REAL(lock = 0xfeffe88c), line 104 in "SDL_spinlock.c"
[5] SDL_GetErrBuf(), line 225 in "SDL_thread.c"
[6] SDL_ClearError_REAL(), line 216 in "SDL_error.c"
[7] SDL_InitSubSystem_REAL(flags = 0), line 116 in "SDL.c"
[8] SDL_Init_REAL(flags = 0), line 244 in "SDL.c"
[9] SDL_Init(a = 0), line 89 in "SDL_dynapi_procs.h"
[10] main(argc = 1, argv = 0xfeffe948), line 65 in "testthread.c"
As far as I can tell, this is because pthread_spin_trylock() always returns EBUSY for this particular lock; since it works in other places, I'm suspicious.
Different Solaris Studio compiler versions seem to make no difference.
I've verified this is broken on Linux as well if SDL_spinlock.c is modified to use the pthread implementation.
This appears to be because pthread_spin_init() and pthread_spin_destroy() are not used with the locks as required.
The D3D11 renderer is now slightly faster than D3D9 on my Windows 8 machine (testsprite2 runs at 3400 FPS vs 3100 FPS)
This will need tweaking to fix the Windows RT build.
Based on the original port to Wayland by: Joel Teichroeb, Benjamin Franzke, Scott Moreau, et al.
Additional changes in this commit, done by me:
* Wayland uses the common EGL framework
* EGL can now create a desktop OpenGL context
* testgl2 loads GL functions dynamically, no need to link to libGL anymore
* Assorted fixes to the Wayland backend
Tested on the Weston Compositor (v1.0.5) that ships with Ubuntu 13.10,
running Weston under X. Tests ran: testrendercopyex (all backends), testgl2, testgles2,testintersections
Haiku uses most of the standard pthread API, with a few #ifdefs where we
still need to fallback onto the old BeOS APIs.
BeOS, however, does not support pthreads (or maybe doesn't support it well),
so I'm unplugging support for the platform with this changeset. Be Inc went
out of business in 2001.
This uses libudev for hotplug, but it's optional, so we'll just try to find
some reasonable defaults without it (maybe an older Linux box or under
FreeBSD's Linux emulation?).
It's a long-dead platform, and we don't have any way to build for, test, or
maintain it, so there's no sense in doing acrobatics to support it.
If you need Windows CE support, use SDL 1.2. If you need Windows Phone support,
send SDL 2.0 patches for the newer Windows Mobile platform.
2.Replaced XKeycodeToKeysym with XkbKeycodeToKeysym since XKeycodeToKeysym is deprecated in newer X11 version
3.Rewrote testime.c since it was disabled after SDL_compat.c removal
4.Take into account common arguments also in testrelative.c
1.initial work on XInput2 support
2.Implemented relative mouse motion when XInput2 is enabled
3.Created a test app to test relative mouse motion
4.Fixed Bug #1498
It was very confusing to have configure generate an SDL_config.h and then not have it be used when building on Mac OS X or Windows. I'll just have to remember to use SDL_config_windows.h when building official releases that are supposed to be ABI compatible with Visual Studio.
Scott Percival 2011-07-03 06:41:51 PDT
This submission is aimed at making life easier for OpenGL ES capable devices
running a X11 stack (e.g. Maemo, Meego, TrimSlice, other ARM SoC boards not
running Android). SDL's Pandora support already has the neccesary GLES-to-X11
glue code, however it's all ghetto'd off in Makefile.pandora and not very
flexible.
The patch:
- adds an awesome --enable-video-opengles option to configure
- re-modifies the opengles and opengles2 SDL_renderers to use function pointers
- no idea why this was removed?
- for SDL_Renderers, links in libGLESv1_CM, libGLES_CM (for PowerVR fans) or
libGLESv2 at runtime
- links in libEGL.so at runtime - the old code made an assumption that
eglFunctions could be pulled from the active GLES library, PowerVR for one
doesn't let you do that with their libGLESv2
- allows you to pick which of GLES v1 or v2 to load via
SDL_GL_CONTEXT_MAJOR_VERSION
So far I've tested this on a Nokia N900 (OMAP 3430/SGX 530 running Maemo 5) and
a Toshiba AC100 (Tegra 2 running Ubuntu 10.10). I haven't tested it on... well,
everything that isn't those two, such as a Pandora, iOS or Android device. The
Pandora specific code should be kept intact (fingers crossed), and nothing
painfully drastic has been added to the SDL_renderers. The library loading
sequence in SDL_x11opengles has been updated to accomodate both NVIDIA's
propensity to let developers get away with murder and PowerVR's alternative of
punishing every missed step.
The test apps work okay with GLES or GLES2 as the renderer. For some reason
alpha blending doesn't seem to work on the Tegra 2; last week NVIDIA pushed out
a new set of X11 GLES drivers, so I'll try and investigate once I upgrade
those. Also, this patch adds things to configure.in, include/SDL_config.h.in
and test/configure.in. I didn't know what the policy was re. committing
generated spaghetti from autotools, so ./autogen.sh has to be run again. Sorry.
I think that's about everything, let me know if there's anything I've
overlooked.
