SDL 2.0.1

[urho3d]

SDL 2.0.1

[cadaver]

I can do the initial update in a separate branch and backport the necessary hacks (usually less of them are necessary with each SDL update, which is good) from Win/Linux/OSX/Android/iOS, but what should we do about Raspberry Pi? @weitjong Is it OK if I replace your raspi code with SDL's and you then investigate what needs to be fixed/backported?

[weitjong]

Sure. I will do that.

[cadaver]

Initial investigation was not pleasant: they have moved Android OpenGL initialization to C code (which also requires bumping the Android API level), but it's crashing to the surface recreation when you use the home button, then return to the Urho application.

Currently I don't feel like spending several hours debugging SDL's code, so I have pushed the crashing code to a sdl-update branch so that someone else can take a look.

Some nice things like iOS 7 status bar hiding will be safe to take from 2.0.1 though.

[cadaver]

With a trivial change (do not try to free GPU objects or the OpenGL context when the focus is taken away) the crash could be removed, however I didn't seem to be able to properly restore the context either.

[cadaver]

Ok, things are looking a bit brighter, rewrote the GL context restore logic and now it should work for both desktop & Android.

[cadaver]

I should now be finished with my work for the sdl-update branch. Windows, Linux, OSX, iOS, Android all seem to work. Practically the only thing that gave trouble was Android, everything else worked out of the box while keeping those SDL modifications that were still necessary.

I guess everyone is OK with requiring Android API level 9 (which is OS version 2.3+) instead of the previous 8?

[weitjong]

Raspi build is OK but all the executable cannot run. Error: Could not open window. I will look into it.

[cadaver]

Quick guess: the SDL define for the Raspi video system is now SDL_VIDEO_DRIVER_RPI and we don't define it due to using our own CMake build instead of the official.

[weitjong]

Yes, I spotted that as well and made the necessary change. I want to go through the code before making another attempt.

[weitjong]

The open window error is already solved now. However, the Urho3D/SDL now does not receive any input events (WIP).

[weitjong]

It is able to to get the input events now but I have to add another Linux software package, namely libudev-dev (on raspbian) or (systemd-devel on Pidora). I have not pushed the changes yet because mouse motion event produces a wild spin with the new code. My old raspi code does not have this problem, so I will try to merge them. Keyboard event is OK.

[cadaver]

Spinning in NinjaSnowWar is usually a result of either

• both touch & mouse being handled from same input device
• the "warp cursor back to center" function for endless mouse move is not working properly. It may be the centering itself producing mouse motion

[Canardian]

Also make sure you set the mouse dx and dy values (which are the difference values from last position to center position) to 0 before the main loop.

[weitjong]

I believe I am looking at the similar spinning problem in other platforms that I reported in the past when Lasse upgraded SDL. So, I may be barking up the wrong tree to solve this issue (even replacing the SDL_rpievents with my SDL_raspievents does not solve the issue).

I will first push whatever changes I have to enable the input events (still with Ninja spinning issue). Lasse, what exactly did you do last time to solve the spinning issue on the other platform?

[cadaver]

In the past, I remember disabling OSX input code sending touch events from the touchpad, and disabling Android & iOS emulated mouse events from touch. Both of these would potentially cause spinning or the cursor jumping erratically (NinjaSnowWar reads both the mouse & touch input for camera control)

The code for the relative mouse motion is quite simple, it relies on being able to read the mouse cursor position, and to set it. Constant spinning would result if for some reason the cursor would not be in the center when idle. Actual SDL mouse move events are not being used for the relative motion at all.

(from Input.cpp)

    IntVector2 mousePosition = GetMousePosition();
    mouseMove_ = mousePosition - lastMousePosition_;

    // Recenter the mouse cursor manually
    IntVector2 center(graphics_->GetWidth() / 2, graphics_->GetHeight() / 2);
    if (mousePosition != center)
    {
        SetMousePosition(center);
        lastMousePosition_ = center;
    }

[weitjong]

Thanks for the hint. It is very useful. The fix is easier than I thought and in the end I just keep all the raspi original mouse and events code from SDL.

[cadaver]

@weitjong Do you think this would be OK to merge to master?

[friesencr]

out of curiosity was there a net gain from the upgrade?

[cadaver]

At least the iOS 7 status bar fix should be beneficial for people running that, and there are a lot of nice smaller fixes. On OSX I'm still sometimes getting stuck on fullscreen like before, but that may be just my system, otherwise I don't notice critical differences on the devices I'm running on. As a result of the Android GL context destroy/restore mechanism changes the Urho code regarding that is more solid now, as before it potentially performed GL calls on a nonexisting context.

[friesencr]

I have gotten burned by the fullscreen thing quite a few times. I write some crappy code and it blows up and i can't shell out. If you mash the reboot button a bunch of times you can usually get out.

https://bugzilla.libsdl.org/show_bug.cgi?id=1908

It's not really a bug in SDL's code - it's just the way the old OS X display capture method works. You should probably either always use SDL_WINDOW_FULLSCREEN_DESKTOP or detect command-M, command-H, and command-tab keypresses and un-fullscreen the window manually (Awesomenauts does this and it works ok.)

With well over half of the mac users upgrading to mavericks already hopefully later versions of sdl can target the newer versions.

[cadaver]

Tested SDL_WINDOW_FULLSCREEN_DESKTOP briefly and the switching to/from Urho (either with cmd-tab or by clicking the miniaturized window) was very unreliable. Cannot move to that at least in SDL's current state.

[weitjong]

@cadaver Yes, Lasse. I have completed testing on the Raspberry Pi platform. Both Raspbian and Pidora work as before.
@friesencr We have now less code to maintain ourselves on RPI side. The added UDEV layer brings hot plugging of USB input devices on RPI.