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.
Alex Nankervis 2012-01-15 14:20:01 PST
SDL_cocoawindow.m, windowDidResize needs to also send a window move event.
Depending on the corner you resize a window from, or when maximizing a window,
the window position will change. Discovered this when creating a maximized
window and found that the window position was stuck at the un-maximized
window's value.
Diff with fix attached.
Tim Angus to SDL
void function( SDL_Surface* surface )
{
SDL_Surface* anotherSurface =
SDL_ConvertSurfaceFormat( surface, ... );
// surface->map->dst is now equal to anotherSurface
// Do some stuff with anotherSurface
SDL_FreeSurface( anotherSurface );
// anotherSurface is now a dead pointer,
// but surface->map->dst still points to it
}
int main( )
{
SDL_Surface* surface = CreateAValidSurface( );
function( surface );
}
At this point blit something from surface. SDL_LowerBlit is called, which checks surface->map->dst against the blit destination. If the pointers happen to match (not that unlikely), the map is decided to be valid and bad things happen.
It seems to me like the whole idea of caching the blit mapping is fundamentally flawed in that the source surface has no knowledge of the lifetime of the destination surface.
Alex Nankervis 2012-01-15 11:19:45 PST
DirectX joysticks can enumerate their axis out of order. This results in some
joysticks having vertical/horizontal swapped, for example (vertical axis gets
assigned to axis0). Joysticks that I've tested with this problem: XBOX 360
controller, Logitech Extreme 3D Pro.
Attached is a diff that fixes this by sorting the DX joystick objects by their
data offsets into the DX data structs. This puts the joystick objects into a
standard ordering (X axis -> axis0, Y axis -> axis1, and so on).
bastien.bouclet@gmail.com 2011-06-26 02:15:36 PDT
SDL_Keyboard::focus does not seem to be reset when the window that has focus is
destroyed, resulting in the following crash :
#0 X11_SetWindowGammaRamp (_this=0x8ed9cb0, window=0x91f25c0, ramp=0x0) at
src/video/x11/SDL_x11window.c:948
#1 0x001bd15e in SDL_OnWindowFocusLost (window=0x91f25c0) at
src/video/SDL_video.c:1900
#2 0x00168a2e in SDL_SendWindowEvent (window=0x91f25c0, windowevent=<value
optimized out>, data1=0, data2=0)
at src/events/SDL_windowevents.c:157
#3 0x00166454 in SDL_SetKeyboardFocus (window=0x9678a08) at
src/events/SDL_keyboard.c:612
morgan.devel@gmail.com 2012-01-13 00:32:23 PST
The android version of SDL_SYS_JoystickUpdate doesn't check if there is
actually new data and always generate the SDL_JOYAXISMOTION event.
Consequently, doing a while(SDL_PollEvent()) will result in an endless loop.
The attached patch fix this issue.
It also scale the incoming values properly in the Sint16 range. The scale from
[-gravity;+gravity] is done directly in the java part because one may want to
map the sensor values with a non-linear method for example.
I'm playing with SDL on android, and did notice a problem in latest sources ( branch "default" ) :
SDL/src/render/opengles/SDL_glesfuncs.h:10: error: 'glDrawTexiOES' undeclared (first use in this function)
SDL/src/render/opengles/SDL_glesfuncs.h:10: error: (Each undeclared identifier is reported only once
If it can help you win some time here is the fix, applied to the "Android.mk" file :
LOCAL_CFLAGS += -D GL_GLEXT_PROTOTYPES
I think this fixes the bug. I'm not sure why it would fail, and it may have something to do with the version of OpenGL that we initialize and use by default. Regardless, this should take care of the problem.
Markovtsev Vadim 2011-01-18 22:00:16 PST
SDL_audiocvt.c:
static void SDLCALL
SDL_ConvertStereo(SDL_AudioCVT * cvt, SDL_AudioFormat format):
#define dup_chans_1_to_2(type) \
{ \
const type *src = (const type *) (cvt->buf + cvt->len_cvt); \
type *dst = (type *) (cvt->buf + cvt->len_cvt * 2); \
for (i = cvt->len_cvt / 2; i; --i, --src) { \
const type val = *src; \
dst -= 2; \
dst[0] = dst[1] = val; \
} \
}
Pay attention to cvt->len_cvt / 2. 2 is the sizeof(Uint16), hovewer, below we
see that the conversion function supports Uint8 and Uint32:
switch (SDL_AUDIO_BITSIZE(format)) {
case 8:
dup_chans_1_to_2(Uint8);
break;
case 16:
dup_chans_1_to_2(Uint16);
break;
case 32:
dup_chans_1_to_2(Uint32);
break;
}
If type is Uint32, src will be decreased twice as it should be, memory being
written before the cvt->buf. If type is Uint8, the conversion will not be
complete. I suggest to change that define to
#define dup_chans_1_to_2(type) \
{ \
const type *src = (const type *) (cvt->buf + cvt->len_cvt); \
type *dst = (type *) (cvt->buf + cvt->len_cvt * 2); \
for (i = cvt->len_cvt / sizeof(type); i; --i, --src) { \
const type val = *src; \
dst -= 2; \
dst[0] = dst[1] = val; \
} \
}
I tested that and now it's working fine. I did not consider the similar defines
in functions nearby.
The patch Mark attached looks good and valgrind gives it a clean bill of health:
Mark.Howson@ntu.ac.uk 2010-12-15 07:45:25 PST
Reproducible here under Windows and Linux. Looking at the code for
SDL_Upsample_S16LSB_2c:
const int dstsize = (int) (((double)cvt->len_cvt) * cvt->rate_incr);
Sint16 *dst = ((Sint16 *) (cvt->buf + dstsize)) - 2;
const Sint16 *target = ((const Sint16 *) cvt->buf) - 2;
while (dst > target) {
dst[1] = ((Sint16) SDL_SwapLE16(sample1));
dst[0] = ((Sint16) SDL_SwapLE16(sample0));
dst -= 2;
...
if dstsize is odd (and therefore dst), it'll write to target[1] which is one
byte before the allocated buf.
The attached patch to sdlgenaudiocvt.pl changes dst > target to dst >= target,
and removes the - $channels for the upsample case. The patch is not fully
tested, but seems to work here.
Scott Percival 2012-01-08 04:21:22 PST
I tested the new build on my two ARM machines, and fixed a few bugs:
- if SDL_VIDEO_DRIVER_UIKIT, SDL_VIDEO_DRIVER_ANDROID or
SDL_VIDEO_DRIVER_PANDORA are specified, function pointers are grabbed from the
compile-linked library instead of through SDL_GL_GetProcAddress. (not sure if
this is the best way to go about it)
- removing "/usr/lib/" from all the library names (hey, with multiarch you
can't be too sure anymore)
- added glFinish to glesfuncs.h
- changed the eglGetProcAddress arg type to "const char *" as per the EGL spec
- filled in the stubs for X11_GLES_SetSwapInterval and X11_GLES_GetSwapInterval
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.
Liam 2011-08-23 09:09:18 PDT
Hiya!
Seems like there's no implementation of condition variables included when
building with VS2010, adding the generic SDL_syscond.c file to the project
seems to fix it right up.
Gabriel Jacobo 2011-12-23 12:55:11 PST
The attached files provide some improvement over the current handling of
pause/resume in Android.
- I disabled the exit(status) instruction in SDL_main as that makes the entire
app instead of the SDL thread exit (while not needed for pause/resume it is
needed for Live Wallpapers, an SDLActivity for which I'll upload in a separate
bug).
- Added nativePause and nativeResume which basically just mark the window as
visible/hidden, something that the end user needs to take into consideration
(ideally pausing the event loop).
Also, this arrangement creates a new GL context when needed, which at least in
my test system is every time you go away from the app and come back to it. So,
this means that the textures need to be generated again after resuming (a
problem the end user didn't have before because the app exited completely when
it should've been pausing). I'd like to know if there's a standard way of
letting the user know that the GL context has changed and that he needs to
refresh his textures, or if this is out of the scope of the library and each
user handles it in their own way (I don't know how/if this same thing is
handled in the iPhone backend, but it would be wise to try to imitate that).
Gabriel Jacobo 2011-12-23 12:57:10 PST
Also, in the SDLActivity the EGL handling code is moved up to the Activity from
the Surface code, as I think it is possible (in theory) that the surface is
destroyed temporarily while the context remains alive (though in practice in my
test system this is not the case)
Jens Köhler 2011-09-09 04:47:40 PDT
When calling SDL_CreateWindowFrom with a NSWindow which already contains a
NSView, the window will be duplicated because another NSView is added. I
attached a possible fix that prevents the creation of a second NSView.
