As SDL 2.0.4 is pending release are there any plans for updating it in Urho3d. There are many improvements for IOS 8.2 and many bug fixes.
Here are some of the changes that worth mentioning for IOS:
Also note that SDL_WINDOW_ALLOW_HIGHDPI is now mandatory for any retina display both on OSX and IOS .
Yes, when it’s out, we will eventually update, along with re-applying our custom modifications. Usually some things always break in the process but at least so far we have always managed to restore a working state.
Great news , thanks a lot
I am actually interested in making Urho3D work with SDL 2.0.4. SDL 2.0.4 is already out ( libsdl.org/download-2.0.php ). Where are the patches that must be applied on top of SDL 2.0.4 source code in order to make it work with Urho3D?
My effort to get Urho3D to use SDL 2.0.4: github.com/urho3d/Urho3D/pull/1172 .
Also, I see that there is already a similar effort under way: github.com/urho3d/Urho3D/pull/1123 .
I did a quick diff between Urho3D SDL 2.0.3 and Official SDL 2.0.3. You can check it out here: github.com/valera-rozuvan/SDL_203/pull/1 (under Files changed).
Finally finished with applying Urho3D custom patches on top of SDL 2.0.4. It’s not THAT MUCH of work, but I’d rather automatize it… I am definitely not looking forward to doing the same work for the next release of SDL.
Maybe we can take the work I did github.com/valera-rozuvan/Urho3 … e216ae9af3 , and create some kind of a smart patch to apply to the next release of SDL? I suggest that we use some tool similar to this:
The Diff Match and Patch libraries code.google.com/archive/p/googl … tch-patch/ .
What do you think?
Exactly! This is the problem we want to address by using git subtree. If you have tracking development in the master branch then you should see that we are “slowly” moving into that direction. LuaJIT and nanodbc are now (git) subtrees instead of (plain old) subdirectories already. Since the result has been very good so far, we have decided to proceed with other 3rd-party libraries as well whenever it is possible, i.e. when we could find an official GitHub repo or even an unofficial one but automated git mirror repo on GitHub of the 3rd-party project. And SDL is our next contender. Some of you may have already noticed that we have ‘SDL-mirror’ repo forked into our GitHub ‘urho3d’ org one week ago. This step is a prerequisite for the git substree approach.
[quote=“valera_rozuvan”]Maybe we can take the work I did github.com/valera-rozuvan/Urho3 … e216ae9af3 , and create some kind of a smart patch to apply to the next release of SDL? I suggest that we use some tool similar to this:
The Diff Match and Patch libraries code.google.com/archive/p/googl … tch-patch/ .
What do you think?[/quote]
Personally I am not in favor of automating the patching as you have suggested. That could only work when the “diff” itself remains constant, which is not. When doing an upgrade, more often than not we have to modify our local changes accordingly. So, we cannot safely just reapply the same set of diffs blindly on top each time we upgrade. Using git subtree approach as I mentioned above does not remove a human factor out of the equation. The subtree approach facilitates us to pull in the changes from upstream but still we have to manually resolve any conflicts that may arise. And this needs domain knowledge that an automated diff-match-patch could not hope to acchieve. Well, unless the google-diff-match-patch project is powered by AlphaGo at the backend (I am joking, of course).
Is the GitHub repository hg.libsdl.org/SDL ? If so, then if you really intend to use it as a submodule, you will have to apply a patch every time you try to build Urho3D using that submodule. For example, in the file:
There exists a line:
But in the official SDL file:
The line is different:
So, do you plan to create custom crafted patches which will be applied during the initial pull & build of the SDL submodule?
First of all, it is “git subtree”, not “git submodule”. These are two different things. No custom patches are needed in order to roll forward. When done correctly the git subtree already has all the local changes that we have made so far, including the one you just shown. We could “simply” rebase the subtree from one version to a newer one when pulling changes from upstream. It could be a commit SHA, a branch, or a tag. I am over simplifying things of course because the rebase command usually comes with conflicts that one need to resolve.
Ahh! Of course. Sorry - didn’t pay attention. This is the right way to go about it. Keep on pushing = )
The SDL 2.0.4 upstream changes have been merged into our SDL subtree. You can checkout the code in the “SDL-2.0.4-upgrade” branch to test it out yourself and also to help us to root out any regression issues. The SDL_WINDOW_ALLOW_HIGHDPI flag needs to be set for iOS platform to get back what we used to have with SDL 2.0.3 on iOS platform. We have not set this flag for OS X platform yet as sabotage3d has suggested. Let’s know if it really needs it as well. I don’t have Retina display monitor to verify that.
Overall there are lesser local changes needed to the SDL original source codes with 2.0.4, which means some of our local bug fixes have made it to the upstream in one form or another. Most notably full screen app on OS X platform can use Spaces without any issue now, so it has been enabled back.
There are still work left to be done. So the “base” might get rebased again. You are advised not to making further commits on top this branch yet locally. You will have problem to sync the branch if you do so and indeed it has been rebased again (unless you know how to do “git rebase --onto stuff” yourself).
weitjong - great work! Will be playing with your branch today.
The power of git rebase should not be underestimated.
And yes, I am aware of how to pull a rebased branch on top of local commits = ) For those of you who are not aware, please see the great resource on “pull with rebase” at gitready.com/advanced/2009/02/11 … ebase.html .
No feedback so far. It is either the upgrade does not cause any regression issue or no one has tested it yet. I have tested it myself on Linux, Android, iOS, and OSX. Haven’t tested it on RPI yet. I actually get a little side track while I am on my Mac. After realizing that SDL/AppleTV experimental branch can be applied cleanly on top of our upgraded 2.0.4 SDL code base, my curiosity got the better of me and I just have to see what it takes to port Urho3D to AppleTV platform myself. And I just did that. It is almost a trivial work if not for a few changes on the AppleTV SDK itself (e.g. system() and fork() are not available) and the fact that CMake actually does not support AppleTV platform yet (fortunately it can be hacked to workaround the problem). I only have 2nd generation AppleTV at home so I cannot test the Urho3D samples on the actual device, but a few of the samples that I have tested so far seem to work pretty well on the AppleTV simulator, including NinjaSnowWar which means AngelScript works. Lua also works but not yet with LuaJIT. Although after tweaking LuaJIT universal binary library could be built already on AppleTV, somehow the 22_LuaIntegration sample app only displays the cube without any spinning motion which indicates LuaJIT is not working properly. Other things that still do not work as expected is the App’s icon in the home screen. I haven’t got time to test the interaction with AppleTV remote yet. As this initial porting work is based on the yet to be merged “SDL-2.0.4-upgrade” branch and that it relies on a few black magic hacks on the CMake side, I will probably hold on to push my experiment branch out at this time.
I did a quick test compiling with Visual Studio 2015 community, seems like everything worked smoothly
In general those changes seem solid, nice work !
+1 for git subtrees and passing fixes upstream. This should simplify life for everyone.
I was very busy finishing my Commodore64 game. Will start testing this on different platforms shortly.
Take your time. I am taking a break myself for the past few days. It is CNY!
Have tested Windows, Linux, OSX, Android, iOS. All worked (including switching away from app on Android / iOS, and mixed touch+mouse on Windows), excellent work! I believe this can go to master, if not immediately then very soon. Can still give a spin to Emscripten.
Thanks for the positive feedback. Yes, I agree that we should probably give Emscripten a spin. However, since my recent upgrade to Fedora 23, I haven’t got time to rebuild my Emscripten toolchain from source yet so I will not probably do this investigation myself. I also recall there is still one pending Emscripten issue reported by jj regarding our mouse handling while in fullscreen mode or something like that. It will be great if someone with more expertise with mouse input to have a look at this again to see what 2.0.4 brings for Emscripten platform. As for myself, since now I am back to my Linux box, I will probably concentrate on integrating with SDL original CMakeLists.txt (and while doing that hopefully it brings IME and also wayland support to Urho3D). BTW, I have just did a rebase so that the current SDL-2.0.4-upgrade branch is up to speed with latest master branch.
Yes, the mouse modes are bit of a mess on Emscripten. In part this is because normally the examples operate in the “absolute” mouse mode, and toggle mouse visibility as required (e.g. when showing console). However, the pointer lock support for Emscripten is only written for the “relative” mode. I believe the issue is solvable by Urho Input class changes; Emscripten itself should already have everything needed.