Commit Graph

4012 Commits

Author SHA1 Message Date
Sam Lantinga eb06aba8ae Fixed bug 3742 - minor warning fixes 2017-08-13 21:16:58 -07:00
Sam Lantinga 2da830a909 Fixed bug 3741 - more compatible initializers for arrays
Ozkan Sezer

An array defined like  int xPositions[] = {-1, 0, 1, w-1, w, w+1 };
errors with Open Watcom: it strictly wants constants.  Small patch
like below makes things more compatible.
2017-08-13 21:15:44 -07:00
Sam Lantinga 93a520b385 Fixed bug 3605 - Software renderer no longer renders after Android screen orientation change
Sylvain

This still happens with the current trunk version.  (software renderer of testdrawchessboard.c)

When there is a rotation, the window size changed and the internal surface is marked as "surface_valid == SDL_FALSE".
And all further call fails.

SDL_video.c :

2478 void
2479 SDL_OnWindowResized(SDL_Window * window)
2480 {
2481     window->surface_valid = SDL_FALSE;
2482     SDL_SendWindowEvent(window, SDL_WINDOWEVENT_SIZE_CHANGED, window->w, window->h);
2483 }

some error set to :
2233         return SDL_SetError("Window surface is invalid, please call SDL_GetWindowSurface() to get a new surface");


So, this seems to be the behavior of the API ...


In the loop() function of testdrawchessboard.c, we can recreate the surface/renderer :

 65        if (e.type == SDL_WINDOWEVENT)
 66        {
 67             if (e.window.event == SDL_WINDOWEVENT_SIZE_CHANGED)
 68             {
 69                surface = SDL_GetWindowSurface(window);
 70                renderer = SDL_CreateSoftwareRenderer(surface);
 71             }
 72             /* Clear the rendering surface with the specified color */
 73             SDL_SetRenderDrawColor(renderer, 0xFF, 0xFF, 0xFF, 0xFF);
 74             SDL_RenderClear(renderer);
 75        }

And it displays correctly.
2017-08-13 21:12:14 -07:00
Sam Lantinga 3cae0c38d2 Fixed bug 3746 - remove SDLCALL attribute from SDL_BlitFunc() funcptr
Ozkan Sezer

The attached patch removes SDLCALL attribute from SDL_BlitFunc() funcptr.

As far as I can see, *SDL_BlitFunc() is completely internal to SDL with
no specific calling convention requirements.  The actual functions assigned
to SDL_BlitFunc seem to not have any calling conventions specified. So,
easy solution is simply removing the strict calling convention from the
type.
2017-08-13 21:09:00 -07:00
Sam Lantinga ca5c304814 Fixed bug 3744 - missing SDLCALL in several functions
Ozkan Sezer

The attached patch adds missing SDLCALL to several functions, so that
they properly match the headers as intended.
2017-08-13 21:06:52 -07:00
Sam Lantinga e54eede265 Provide the correct state of the on-screen keyboard to the API (patch from Sylvain) 2017-08-13 21:05:15 -07:00
Sam Lantinga 6ee661398d Fixed bug 3235 - Make the Android window creation similar to iOS' window creation
Sylvain

Here's a patch.
It tries to get the hint first. Resizable will allow any orientation. Otherwise it uses width/height window.

setOrientation method is splitted in static and non-static, so that it can be overloaded in a user subclass.

Some artefact observed :
surfaceChanged() can be called twice at the beginning. When the phone starts in portrait and run a landscape application.
2017-08-13 20:55:59 -07:00
Sam Lantinga 6ef1a25d18 Fixed bug 3751 - DirectFB linux_input disabled by default
Clayton Craft

linux_input module is disabled by default, despite the comments in source code that it is otherwise:

src/video/directfb/SDL_DirectFB_video.c:
    devdata->use_linux_input = readBoolEnv(DFBENV_USE_LINUX_INPUT, 0);       /* default: on */

src/video/directfb/SDL_DirectFB_video.h:
    #define DFBENV_USE_LINUX_INPUT      "SDL_DIRECTFB_LINUX_INPUT"      /* Default: on  */

When using the directfb driver, the linux_input module is suppressed unless the SDL app is started with "SDL_DIRECTFB_LINUX_INPUT=1" set in the environment. I recall seeing at one point that the directfb folks recommended using linux_input over the other input drivers, but I am having trouble locating this recommendation. In any case, I believe that this should really be defaulted to 'on' since it's vastly superior to the other dfb input drivers!
2017-08-13 20:51:08 -07:00
Sam Lantinga ddeaa6016c Fixed bug 3299 - DirectInput: Incorrect joystick mapping when attaching new joysticks
Jimb Esser

Note: This is using DirectInput, I have to disable XInput as that causes all but the first 4 controllers to be completely ignored by SDL (I can find no way to reconcile XInput devices with DirectInput devices, otherwise I would make a patch that accepts the fifth and later controllers with DirectInput...).  XInput does not seem to have the problem below, only DirectInput.

I plug in 3 identical wireless Xbox 360 controllers, call them J1, J2, J3.  Direct Input shows them as having GUIDs G1, G2, G3.  I unplug J1, then J2 and J3 show up as having GUIDs G1 and G2!  Not so "unique"...  I start my SDL app when just J2 and J3 are plugged in, and open J2 and J3.  Then I plug in a new controller, SDL sees that now G3 exists, assigns that a new SDL joystick instance ID, which I request to be opened, but G3 at this point is J3, which I already had opened!  So I end up with two instances of J3 opened, and none of J1.  "Re-"opening G1 would get the actual handle to the newly attached controller, but there's no current way to know this.  This is clearly a bug or poor design in DirectInput or my wireless receiver drivers, but is a showstopping bug for my 8-20 player games (as soon as any one controller runs out of battery or goes to sleep and gets turned back on, suddenly things are busted requiring a restart (or, at least, a reinitialization of all controllers - the game can't go on)).

The solution I found is to use HID paths instead of GUIDs to uniquely identify joysticks.  GUIDs are still needed to open a controller, however I have added code to re-find the GUIDs for all joysticks whenever a new joystick is attached or removed.  This does now require opening of all joysticks (instead of just enumerating them), though if your app, like mine, is opening all of them anyway so that any can press a button to join, that doesn't change much (although perhaps they joysticks should be kept open in this case, instead of closed and re-opened).  If your app only ever opens one joystick, this will do more work at startup than it did previously.
2017-08-13 20:42:41 -07:00
Sam Lantinga ea9bc659f5 Added check for XBOX in addition to Xbox and X-Box 2017-08-13 20:39:00 -07:00
Sam Lantinga 78865effb5 Fixed compiler warning 2017-08-13 20:38:06 -07:00
Sam Lantinga f1829d956f Added SDL_wcscmp() 2017-08-13 20:37:49 -07:00
Sam Lantinga af9ec8f6b5 Fixed copy-paste error, thanks Alen! 2017-08-13 20:13:11 -07:00
Sam Lantinga df2d299447 Fixed bug 2812 - Make libSDL2main.a usable on Android via a dummy symbol
Jonas Kulla

This eliminates the need to manually compile in SDL_main_android.c.
Instead, add "-lSDL2main -Wl,-u,SDL_main_dummy" when linking.

I don't know how the nkd-build process works, but unless it was
for some reason linking libSDL2main.a it should be unaffected.
2017-08-13 18:12:06 -07:00
Sam Lantinga e977225937 Fixed bug 2839 - No way to create pre-built libraries for Android
Mark Callow

README-android says to copy or link the SDL source tree to the jni folder in your Android project. It is not desirable to have to compile SDL with every application; furthermore the Android NDK has support for prebuilt libraries.

Attached is script (to be put in build-scripts) that builds the Android version of the libraries. The script builds both the existing SDL2 module and a new SDL2_main module. This is a static library containing the code from src/main/android/SDL_android_main.c. Also attached is a patch for Android.mk adding this module.

Note that when building an application's native .so using this prebuilt libSDL2main, you must use a link option, such as --whole-archive, that forces inclusion of the code in the .so because the functions in SDL_android_main are called only from Java.
2017-08-13 17:59:59 -07:00
Sam Lantinga c87e1d525c Fixed bug 2841 - Hint to set resource id for window icon
Alexey

Seems to be a missing functionality. I want to set an icon from RC file. I cant pass MAKEINTRESOURCE(X) string to SDL_RegisterApp() cause string returned by MAKEINTRESOURCE string is not actually a string and SDL_strlen will crash. Moreover LoadImage seems to be loading wrong icon size. LoadIcon seems to be fine.
2017-08-13 14:15:52 -07:00
Ryan C. Gordon 18cceb5ce0 x11: Patched to compile. 2017-08-13 01:00:01 -04:00
Ryan C. Gordon 0a1b905b6c x11: Fix message box titles with Unicode chars on some window managers.
Fixes Bugzilla #2971.
2017-08-13 00:58:23 -04:00
Sam Lantinga bfd5a13473 Fixed bug 2931 - Large relative mouse motion jumps when using touch input 2017-08-12 20:25:49 -07:00
Sam Lantinga b2e2bcc203 Added test debug logs for additional event types 2017-08-12 20:21:34 -07:00
Alex Szpakowski 9be597a0d6 iOS: Fix app orientation when creating a landscape fullscreen window with the device currently in portrait orientation. 2017-08-12 22:16:04 -03:00
Sam Lantinga 059d9e4627 Fixed bug 2950 - wrong axes values are set on joystick initialization
Edward Rudd

Device: Logitech Rumble Gamepad F510 in Xinput mode.

Upon opening the joystick the values of the axes are queried via PollAllValues are not actually set on the device all the time.

This can easily be seen in the testjoystick or testgamecontroller test programs,as the testjoystick shows all axes in the center until one 'tickles' the triggers., and the testgamecontroller will show the triggers as 'on' until on 'tickles' the triggers.

Upon further research the culprit is the SDL_HINT_JOYSTICK_ALLOW_BACKGROUND_EVENTS hint. In the default value events are ignored until there is an active window, Thus in cases where the joystick system is initialized and controllers opened before the initial window is created & focuses, the initial values will be incorrect.

Here is my current workaround in the game I'm working on porting..

SDL_SetHint(SDL_HINT_JOYSTICK_ALLOW_BACKGROUND_EVENTS, "1");
SDL_GameController* gamepad = SDL_GameControllerOpen(index);
SDL_SetHint(SDL_HINT_JOYSTICK_ALLOW_BACKGROUND_EVENTS, "0");
2017-08-12 17:41:59 -07:00
Sam Lantinga 7bab2913c2 Fixed Windows build 2017-08-12 17:01:14 -07:00
Sam Lantinga 05facb3d4e Fixed bug 2979 - SDL_ConvertSurface does not convert color keys consistently
Edmund Horner

When a 16-bit "565 format" surface has a colour key set, it will blit with correct transparency.  If, however, it has its colour key set then is converted to a 32-bit ARGB format surface, the colour key in the converted image will not necessarily be the same pixel value as the transparent pixels.  It may not blit correctly, because the colour key does not match the right pixels.

In my case, with an image using 0xB54A for transparency, the colour key was converted to 180,170,82; but the corresponding pixels (with the same original value) were converted to 180,169,82.  Blitting the converted image did not use transparency where expected.

I have attached a test case.  The bug has been replicated on both x86_64 Linux (SDL 2.0.2), and 32-bit MS C++ 2010 on Windows (SDL 2.0.0).
2017-08-12 16:59:00 -07:00
Sam Lantinga d226594fcc Workaround for bug 3049 - SDL_Init(SDL_INIT_VIDEO) - XDM authorization key matches an existing client!
malferit

Hello, I began a little program with SDL2 on Linux in C, and when I call SDL_Init(SDL_INIT_VIDEO) I get an error and this is printed in the console:

XDM authorization key matches an existing client!

I searched through Internet, and found that some people suggest to run 'xhost +' or to specify this in /etc/X11/xdm/xdm-config:

DisplayManager*authName:        MIT-MAGIC-COOKIE-1

I don't think an end user needs to know that...

But what bothered me is that first I started this little program in Pascal using the Freepascal compiler and it works. In freepascal you only use some thin header bindings in Pascal and then it links with the dynamic SDL library, so I don't understood why it worked with Freepascal and not in C.

I run ldd to the two generated applications:

Application in C:

	linux-gate.so.1 (0xffffe000)
	libSDL2-2.0.so.0 => /usr/lib/libSDL2-2.0.so.0 (0xb76ac000)
	libpthread.so.0 => /lib/libpthread.so.0 (0xb766e000)
	libc.so.6 => /lib/libc.so.6 (0xb74e2000)
	libm.so.6 => /lib/libm.so.6 (0xb74a0000)
	libdl.so.2 => /lib/libdl.so.2 (0xb749a000)
	librt.so.1 => /lib/librt.so.1 (0xb7491000)
	/lib/ld-linux.so.2 (0xb77b3000)

Application compiled with Freepascal:

	linux-gate.so.1 (0xffffe000)
	libSDL2-2.0.so.0 => /usr/lib/libSDL2-2.0.so.0 (0xb762a000)
	libX11.so.6 => /usr/lib/libX11.so.6 (0xb74f3000)
	libc.so.6 => /lib/libc.so.6 (0xb7367000)
	libm.so.6 => /lib/libm.so.6 (0xb7325000)
	libdl.so.2 => /lib/libdl.so.2 (0xb731f000)
	libpthread.so.0 => /lib/libpthread.so.0 (0xb7305000)
	librt.so.1 => /lib/librt.so.1 (0xb72fc000)
	libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb72dc000)
	libXau.so.6 => /usr/lib/libXau.so.6 (0xb72d9000)
	libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb72d3000)
	/lib/ld-linux.so.2 (0xb7755000)

It seems that Freepascal is linking with libX11, libxcb, libXau and libXdmcp .

Linking my C application with libxcb solved the problem (linking with libXau and/or libXdmcp without libxcb didn't work). Linking with X11 links all the other libraries and works as well.

So I fill this bug report mainly to let you know about this. I don't know if it is a problem that can be solved on the libSDL side or not, but at least I hope it will help.

Hi, some tests:

1. Disabled XDM. Login in console and running 'startx'. The program works without having to link with X11.

2. Enabled XDM. Added 'DisplayManager*authName: MIT-MAGIC-COOKIE-1' to /etc/X11/xdm/xdm-config.The program works without having to link with X11.

3. Enabled XDM without 'DisplayManager*authName: MIT-MAGIC-COOKIE-1' in /etc/X11/xdm/xdm-config . I get the authentication error unless I link with X11.
2017-08-12 16:48:46 -07:00
Sam Lantinga 45cec28bc4 Fixed bug 3058 - Slight mistake in GetWindowStyle in SDL_windowswindow.c
Coriiander

There's a slight mistake in the function "GetWindowStyle" found in file "SDL_windowswindow.c".

When a window is marked to be resizable, the resizable style is being added regardless of whether the window has a border or not. While for some arcane, hidden semantics this can be ok, it's still inconsistent in this case.
2017-08-12 16:44:00 -07:00
Sam Lantinga e3f3a757f3 Fixed bug 3158 - SDL display window scrambled over VNC
Witek Jachimczyk

I'm using SDL to develop a video viewer for MATLAB.  The window is scrambled while using thightVNC with its default mode of RGB656.

SDL does not correctly recognize the pixel mode.


I found a solution for this problem.  The solution involves modifying
SDL/src/video/SDL_pixels.c

Adding the following "if statement" under case 16: of SDL_MasksToPixelFormatEnum resolves the issue:

        if (Rmask == 0x003F &&
            Gmask == 0x07C0 &&
            Bmask == 0xF800 &&
            Amask == 0x0000) {
            return SDL_PIXELFORMAT_RGB565;
        }

I hope that this helps someone.  I took me a while to figure it out.
2017-08-12 16:02:33 -07:00
Sam Lantinga 4a9c6f0a14 Fixed bug 3173 - SDL_GL_GetAttribute overwrites error code from SDL_GL_GetProcAddress
Yann Dirson

When SDL_GL_GetProcAddress returns in error, the cause of the error is overwritten
in GL_GL_GetAttribute, reporting to the user "Failed getting OpenGL glGetString entry point", whereas the original "OpenGL library not loaded" never makes it
to the user.

Pushed a fix to:
f94cb13708


Note that the "OpenGL library not loaded" error looks like no root cause either,
and I'm still puzzled by the code path used: I'm forcing opengles2 renderer on
the x11 video driver on a rpi2, as in https://bugzilla.libsdl.org/3169, and although I now know that I must force the use of the RPI video driver instead
of the x11 one, I suspect even more accurate info can be given to user.
2017-08-12 15:55:54 -07:00
Sam Lantinga b1ed855d53 Added a note about number key keycodes always being SDLK_0...SDLK_9 even on AZERTY layouts
See bug 3188 for more discussion
2017-08-12 15:45:46 -07:00
Sam Lantinga 3b837a2659 Fixed bug 3188 - AZERTY keyboard support broken and inconsistent
Daniel Gibson

AZERTY keyboard layouts (which are the default layouts in France and Belgium) don't have the number keys (1, 2, ..., 9, 0) in the first row of keys, but ?, &, ?", ', (, -, ?_, ??), = (with small differences between the France and Belgian variants). Numbers are reached via shift.

On Linux and OSX, SDL seems to use the corresponding ISO 8859-1 codes (231 for ?232 for ?tc) as SDL_Keycode (but no SDK_* constants exists for those values!), while on Windows SDL seems to map those keys to SDLK_1, SDLK_2 etc, like you'd get on QWERTY.
I don't know how other platforms behave.

So we have two problems:
1. At least on Linux and OSX invalid/undefined SDL_Keycodes are returned
2. Different platforms behave differently (Windows vs Linux/OSX)

It's unclear what behavior is desired: Should SDL_* constants for those keys be introduced (and Windows behavior changed accordingly)?
Or should all platforms behave like Windows here and use the existing SDLK_1, ..., SDLK_0 keycodes?

This bug on the mailing list:
https://forums.libsdl.org/viewtopic.php?t=11555 (my post about Linux/Windows)
https://forums.libsdl.org/viewtopic.php?t=11573 (Tim Walters discovered the same problem on OSX about 1.5 weeks later).
2017-08-12 15:41:03 -07:00
Sam Lantinga 1a5441451c Fixed bug 3309 - SDL_ConvertSurface adds AlphaMod when input surface has ColorKey
Sylvain

Let's you have a SDL_Surface that has ColorKey, but no Alpha Modulation.
When this surface is duplicated with SDL_ConvertSurface function, the result has ColorKey and Alpha Modulation (BLEND, and Opaque 255).

I think SDL_ConvertSurface should strictly keeps the input format.


example
=======

SDL_Surface *input; // ... Set up a surface with ColorKey and no AlphaMod

SDL_Surface *output = SDL_ConvertSurface(input, input->format, input->flags);

// "output" surface has a ColorKey but *also* AlphaMod (BLEND, and Opaque 255).
2017-08-12 15:21:26 -07:00
Sam Lantinga e4124ff56d Fixed bug 3208 - Minor improvements to the configure script
Rafal Muzylo

"if we're already using libtool, why aren't we using it ?"; they've been inspired by the fact, that at that mark, neither libSDL2_test.a nor libSDL2main.a were being built correctly (not sure if it's fully broken or just because I've tested the out-of-tree build)
2017-08-12 15:00:33 -07:00
Sam Lantinga 2862b1465d Note that texture contents are undefined when the texture is created. 2017-08-12 13:05:26 -07:00
Sam Lantinga 6f843b902d Fixed bug 3243 - SDL_SetRenderDrawColor() behaves wrong with RGBA=0
Simon Hug

The bug is in the GL_ResetState and GLES_ResetState functions which get called after a new GL context is created. These functions set the cached current color to transparent black, but the GL specification says the initial color is opaque white.

The attached patch changes the values to 0xffffffff to reflect the initial state of the current color. Should the ResetState functions get called anywhere else in the future, this probably has to call the GL functions itself to ensure that the colors match.
2017-08-12 12:59:22 -07:00
Sam Lantinga 47c2c7d585 Cleaned up WindowsScanCodeToSDLScanCode() so VKeytoScancode() always takes precedence for the keys it handles and the rest of the logic is easier to read. 2017-08-12 12:56:28 -07:00
ouned 34769abd46 prefer virtual keycodes over scancodes for extended keys 2017-06-03 09:13:08 +02:00
Sam Lantinga 195b8bd8ee Fixed bug 3249 - keysym.mod is incorrect when mod keys are pressed for SDL_KEYDOWN events
Adam M.

The keysym.mod field does not reflect the state of the modified keys when processing key down events for the modifier keys themselves. The documentation says that it returns the current key modifiers, but they are not current for key down events involving modifier keys. I interpret "current" to mean "equal to SDL_GetModState() at the instant the event is processed/enqueued".

For example, if you depress the Shift key you get a key down event with .mod == 0. However, .mod should not be 0 because a shift key is down. If you then release the Shift key, you get a key up event with .mod == 0. Neither event reports the modifier key.

If you press Shift and then A, .mod is incorrect (== 0) when Shift is pressed, but is correct later when A is pressed (== KMOD_LSHIFT).

You might say this behavior is deliberate, i.e. keysym.mod is the value /before/ the event, not the current value as documented, but that explanation is incorrect because only key down events behave that way. Key up events correctly give the current value, not the value before the event.

Not only is it inconsistent with itself, I think it makes keyboard processing harder.

The problem is near line 740 in SDL_keyboard.c:

if (SDL_KEYDOWN == type) {
    modstate = keyboard->modstate; // SHOULD THIS BE MOVED DOWN?
    switch (keycode) {
    case SDLK_NUMLOCKCLEAR:
        keyboard->modstate ^= KMOD_NUM;
        break;
    case SDLK_CAPSLOCK:
        keyboard->modstate ^= KMOD_CAPS;
        break;
    default:
        keyboard->modstate |= modifier;
        break;
    }
} else {
    keyboard->modstate &= ~modifier;
    modstate = keyboard->modstate;
}

In the key down path, modstate (and thus keysym.mod) ends up being the modifier state /before/ the event, but in the key up path modstate ends up being the modifier state /after/ the event. Personally I think the "modstate = keyboard->modstate" line should just be moved after the entire if/else statement, so that keysym.mod always reflects the current state.
2017-08-12 12:34:09 -07:00
Sam Lantinga c086251266 Fixed bug 3128 - Removing all the static variables from android SDLActivity and accompanying JNI calls.
owen

I removed all the static variables from SDLActivity.java

Updated all the SDL_android.c jni calls as well

I added a new function to SDL_android.c/ h
void Android_JNI_SeparateEventsHint(const char* c);

This is called by SDL_androidtouch.c so that this TU doesn't need to call any JNI functions.
2017-08-12 12:24:59 -07:00
Sam Lantinga 0a52db54bd Fixed bug 3191 - haptic system on android?
Patch provided by jintiao and Milan Nikolic, thanks!
2017-08-12 08:15:09 -07:00
Sam Lantinga 78c84e7029 Fixed part of bug 3227 - patch for multiple buttons at the same time not working
Philipp Wiesemann

There is another problem with the current implementation which maybe should be fixed first (to prevent some work). It was written as if it would get the number of a button from the Java side but actually it gets the state of all buttons. That is why it should not work if more than one button is pressed at once.
2017-08-12 08:06:16 -07:00
Sam Lantinga b425050baf Fixed compiler warnings on Visual Studio 2013 2017-08-12 00:04:46 -07:00
Sam Lantinga affab6ade5 More fixes for the SDL_scanf code 2017-08-12 00:01:24 -07:00
Sam Lantinga e27dcd1c3b Fixed Android build 2017-08-11 23:54:06 -07:00
Sam Lantinga 7229397c0c Fixed bug 3258 - SDL_TryLockMutex blocks for pthreads with FAKE_RECURSIVE_MUTEX
Ian Abbott

I just spotted what I think is a bug in "src/thread/pthread/SDL_sysmutex.c" in the SDL_TryLockMutex function when FAKE_RECURSIVE_MUTEX is defined (for an implementation of Pthreads with no recursive mutex support).  It calls pthread_mutex_lock instead of pthread_mutex_trylock, so it will block until the mutex is available instead of returning SDL_MUTEX_TIMEDOUT if it cannot lock the mutex immediately.
2017-08-11 21:47:31 -07:00
Sam Lantinga b5ea3c6d07 Fixed bug 3284 - minor correction for SDL_setenv on _WIN32__ platform
Coriiander

Here is a minor correction for a non-breaking mistake in SDL_setenv for __WIN32__ platform. See below for details.

FILE:
"SDL/src/stdlib/SDL_getenv.c"

FUNCTION: (__WIN32__ platform)
int SDL_setenv(const char *name, const char *value, int overwrite)

CODE:
    if (!overwrite) {
        char ch = 0;
        const size_t len = GetEnvironmentVariableA(name, &ch, sizeof (ch));
        if (len > 0) {
            return 0;  /* asked not to overwrite existing value. */
        }
    }


WHAT'S WRONG:
The 3th argument to GetEnvironmentVariable (being DWORD nSize) must be the number of characters, not the number of bytes. SDL currently passes "the size of 1 char", rather "1". While it is non-breaking (1=1 after all), it is incorrect. Furthermore there is no need to specify the 2nd and 3th arguments at all.

CORRECTION 1: (corrected argument_
    if (!overwrite) {
        char ch = 0;
        const size_t len = GetEnvironmentVariableA(name, &ch, 1);
        if (len > 0) {
            return 0;  /* asked not to overwrite existing value. */
        }
    }

CORRECTION 2: (stripped of unneeded code)
    if (!overwrite) {
        if (GetEnvironmentVariableA(name, NULL, 0) > 0) {
            return 0;  /* asked not to overwrite existing value. */
        }
    }
2017-08-11 21:30:06 -07:00
Sam Lantinga 75d5f34398 Forgot to add function check for fopen64 to CMake build 2017-08-11 21:17:10 -07:00
Sam Lantinga a48c9e6df8 Fixed bug 3292 - SDL_rwops and 64-bit file I/O
Juha Niemim?

On AmigaOS 4 platform with Newlib 'C' library, there is a problem with failing fseeko64. This seemed to be caused by using fopen instead of fopen64.
2017-08-11 21:16:33 -07:00
Sam Lantinga 4c239e55f9 Fixed bug 3297 - Horizontal and Vertical flip swapped on PSP
Littlefighter19

When trying to mirror something on the PSP, I've stumbled upon the problem,
that using SDL_RenderCopyEx with SDL_FLIP_HORIZONTAL flips the image vertically, vise-versa SDL_FLIP_VERTICAL flips the image horizontally.
Proposed patch would be swapping the check in line 944 with the one in line 948 in SDL_render_psp.c
2017-08-11 20:54:06 -07:00
Sam Lantinga 79a846d486 Fixed bug 3334 - SDL_ShowMessageBox uses wrong index and accesses un-allocated memory
romain.lacroix

For the windows implementation of SDL_ShowMessageBox() : ./src/video/windows/SDL_windowsmessagebox.c:345 WIN_ShowMessageBox()

The implementation in 2.0.4 uses "button index" for parameter "id" of function AddDialogButton().

It then expects the value provided in param wParam of function MessageBoxDialogProc() to be a valid index of a button.

It uses this value to index in the array of buttons when DialogBoxIndirect() returns (line 474 : *buttonid = buttons[which].buttonid;)

However, when dismissing this box with Escape, the return value of DialogBoxIndirect will be SDL_MESSAGEBOX_BUTTON_ESCAPEKEY_DEFAULT (=2) which is not always a valid index of array buttons.

When the array buttons has a length less or equal than 2, the memory access is invalid; I can see that the value written to *buttonId is uninitialized memory (random value).

The fix I propose : use value "buttonid" (field of button) for parameter "id" of AddDialogButton(), then copy return value of DialogBoxIndirect() in *buttonid. This way, we will not use an out-of-bounds index in array buttons.
2017-08-11 19:42:39 -07:00
Sam Lantinga 441d9ba2b0 Fixed bug 3341 - SDL_sscanf() problem
e_pluschauskas

Why does SDL_sscanf() always returns the number of format specifiers and doesn't implements standard C library behavior?
2017-08-11 19:36:12 -07:00