Sun, 13 Aug 2017 21:15:44 -0700Fixed bug 3741 - more compatible initializers for arrays
Sam Lantinga [Sun, 13 Aug 2017 21:15:44 -0700] rev 11275
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.

Sun, 13 Aug 2017 21:12:14 -0700Fixed bug 3605 - Software renderer no longer renders after Android screen orientation change
Sam Lantinga [Sun, 13 Aug 2017 21:12:14 -0700] rev 11274
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.

Sun, 13 Aug 2017 21:09:00 -0700Fixed bug 3746 - remove SDLCALL attribute from SDL_BlitFunc() funcptr
Sam Lantinga [Sun, 13 Aug 2017 21:09:00 -0700] rev 11273
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.

Sun, 13 Aug 2017 21:06:52 -0700Fixed bug 3744 - missing SDLCALL in several functions
Sam Lantinga [Sun, 13 Aug 2017 21:06:52 -0700] rev 11272
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.

Sun, 13 Aug 2017 21:05:15 -0700Provide the correct state of the on-screen keyboard to the API (patch from Sylvain)
Sam Lantinga [Sun, 13 Aug 2017 21:05:15 -0700] rev 11271
Provide the correct state of the on-screen keyboard to the API (patch from Sylvain)

Sun, 13 Aug 2017 20:55:59 -0700Fixed bug 3235 - Make the Android window creation similar to iOS' window creation
Sam Lantinga [Sun, 13 Aug 2017 20:55:59 -0700] rev 11270
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.

Sun, 13 Aug 2017 20:51:08 -0700Fixed bug 3751 - DirectFB linux_input disabled by default
Sam Lantinga [Sun, 13 Aug 2017 20:51:08 -0700] rev 11269
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!

Sun, 13 Aug 2017 20:42:41 -0700Fixed bug 3299 - DirectInput: Incorrect joystick mapping when attaching new joysticks
Sam Lantinga [Sun, 13 Aug 2017 20:42:41 -0700] rev 11268
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.

Sun, 13 Aug 2017 20:39:00 -0700Added check for XBOX in addition to Xbox and X-Box
Sam Lantinga [Sun, 13 Aug 2017 20:39:00 -0700] rev 11267
Added check for XBOX in addition to Xbox and X-Box

Sun, 13 Aug 2017 20:38:06 -0700Fixed compiler warning
Sam Lantinga [Sun, 13 Aug 2017 20:38:06 -0700] rev 11266
Fixed compiler warning