Sdl 2.0.4

Hi guys,

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:
hg.libsdl.org/SDL/rev/cf8fab52e33b
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:

https://github.com/urho3d/Urho3D/blob/master/Source/ThirdParty/SDL/src/main/android/SDL_android_main.c

There exists a line:

But in the official SDL file:

https://hg.libsdl.org/SDL/file/d141e7945ddf/src/main/android/SDL_android_main.c

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.

I have a question. It seems to me that the following SDL code path “src/render” is never being used so far. And so does the “src/dynapi”. For the latter I could more or less understand why. But for the former, I could only find an indication that SDL’s renderer is being commented out intentionally (src/video/SDL_video.c), but I could not find any rationale from the commit logs. The question is, should I keep things as they are when I switch to SDL’s original CMakeLists.txt? If we do nothing then it will pull in all the source codes in src/render.

The “render” code is related to when you use SDL as a 2D sprite / blitting engine, using its Surfaces. But we only ever need it for the window and graphics context, so this is just to reduce unnecessary compilation/linking of unused code.

I am just wondering if the migration to SDL 2.0.4 will eventually lead to Windows 10 UWP support out of the box. Is anyone here working in that direction?

Thanks for quick reply. In that case I see whether I can ride along the original CMakeLists.txt’s build option mechanism (SDL_RENDER_DISABLED) to enable/disable 2D-renderer SDL subsystem at will during project configuration time. Will ensure no unused code getting compiled/linked.

The simple answer is no. The upgrade to 2.0.4 will not eventually lead to that. The actual answer depends on whether we have someone willing to step forward to become the uwp maintainer and do the initial porting work.

I think I have successfully integrated the original SDL CMakeLists.txt into our build system. The SDL_config.h header file is now automatically generated on the fly for all the supported platforms. It actually does that for all the platforms that SDL supports and not just those that Urho3D supports, which means it should make the life easier for any new porting work. If every thing goes smoothly with this then I will probably perform a final rebase to put all the bits in place and merge to master branch tomorrow. Call for final feedback if any. Thanks.

A general fix to resolve all the cross-compiling build issues due to bugs in the original SDL CMakeLists.txt and its modules is coming soon. Stay tune.

Sounds excellent! I’m compiling on Emscripten as I’m writing this, I’ll report back and if I have no issues then you have my blessing to push to master.

You may want to hold on testing with cross-compiling build (including Emscripten) until I have committed my bug fix for SDL’s original CMakeLists.txt and its module. As it is, they have major flaws in their detection logic when in cross-compiling mode. I am actually quite surprise no one has reported this to them!

Alternatively, if you want to proceed now then you may have to reset your local repo to HEAD~ (i.e. one commit prior to the last).

Ah, I already committed one workaround to unconditionally include cstdio in FileSystem.cpp; I don’t think that hurts since it’s being included for Windows in any case. After that an Emscripten example compiled successfully, but didn’t manage to create a canvas.

EDIT: the revision before the SDL CMake change works the same. Though I was using an old precompiled SDK (1.35.0); will see later if compiling a later SDK makes a difference.

EDIT 2: same error with the latest Emscripten SDK.

Strange. I will have a look later to see if I can reproduce the problem on my Linux box. Thanks for the incentive to rebuild my Emscripten compiler toolchain .

I actually do not expect breakage on Web platform using Emscripten. If you look at our current implementation then you can see we just “pull” SDL2 pre-built binary from Emscripten repository instead of building the SDL from our 3rd-party library source. So whether we have upgraded to 2.0.4 or not should have no bearing at all. It could be just a regression caused by my other changes. Thanks for the feedback.

Hmm, now that I tested I’m getting the same also in master branch. I’m currently doing the tests on my work machine, which may just have a broken Firefox though.

EDIT: verified that my FF had disabled WebGL due to crashing, so there should be nothing wrong with Urho in this respect.

Used “refresh Firefox” to clear the crashes. SkeletalAnimation Emscripten sample from SDL-2.0.4 branch run successfully.

That’s a good news. I have been thinking that since now we have “almost” a properly working SDL CMakeLists.txt that enables us to build SDL library on all the target platforms SDL supports including Web, we should probably just build the SDL library now ourselves instead of relying on Emscripten’s repository. I will probably head to that direction once I have fixed all the cross-compiling bugs.

Got time to test it on RPI device just now. It also works without any regression issue with our previous manually crafted SDL_config_linux.h header file. With this it means all Urho3D supported target platforms have been verified. Unfortunately though, there are many more bug fixes required than I have originally anticipated in order to fix the detection logic in the original SDL’s CMakeLists.txt. Without those fixes, the generated SDL_config.h for cross-compiling build are utterly rubbish. Hope to wrap up everything by end of this week.

Awesome!

Once this lands, I’ve got some code to push to support OpenGL ES 3.0… And some WIP code for framebuffer fetch & pixel local storage to support deferred shading on mobile efficiently.

I think I needed to patch SDL slightly to expose a certain EGL extension though, need to check again (been busy, moved to Canada) but I’ve got some time coming up to do some dev.

Cheers

[quote=“boberfly”]Awesome!

Once this lands, I’ve got some code to push to support OpenGL ES 3.0… And some WIP code for framebuffer fetch & pixel local storage to support deferred shading on mobile efficiently.

I think I needed to patch SDL slightly to expose a certain EGL extension though, need to check again (been busy, moved to Canada) but I’ve got some time coming up to do some dev.

Cheers[/quote]
Unfortunately, there is a slight change in (my) plan. I forgot that it is still Chinese New Year period and my wife is insisting to honor the relative house-visiting tradition. Feel more like “duty call” than enjoying life.

A quick update. It is getting closer now. There are still two remaining issues:
[ol][li] The new SDL detection logic is very well fine-tuned. So much so that I have concern it will back fire for OSX and iOS platforms where our build system supports Mach-O universal binary build (Xcode only). The detection is only done once using the primary arch and ABI combination. Therefore the generated SDL_config.h is actually not (so) good when Xcode uses it to build SDL for the alternate archs and ABIs. To be verified if my concern is valid or not.[/li]
[li] As commented earlier, I plan to use this new detection mechanism and instruct our build system to build SDL library internally instead of downloading a pre-built version from Emscripten’s repository. However, in order to do so, we need to workaround a known issue in the Emscripten compiler toolchain where it does not work well with CMake’s CheckTypeSize module. Emscripten team has overridden the offending CMake module and keep a modified version in their source code repository. I haven’t really verified it but I am afraid they have modified it so that it works “only” for Emscripten compiler toolchain. So, we should not simply copy their modified module into our own CMake module directory. Of course, we still have the option to keep the current approach to downloading a prebuilt SDL port when there is no better solution to the above issue.[/li][/ol]

Sorry for the delay. I have a few set backs. It likes everywhere I turn I can still see bugs that need fixing. Really hope to get it over with ASAP.

[quote=“boberfly”]Awesome!

Once this lands, I’ve got some code to push to support OpenGL ES 3.0… And some WIP code for framebuffer fetch & pixel local storage to support deferred shading on mobile efficiently.

I think I needed to patch SDL slightly to expose a certain EGL extension though, need to check again (been busy, moved to Canada) but I’ve got some time coming up to do some dev.

Cheers[/quote]
One of the bug fix I have done is to improve the detection of the Vivante header file for embedded device. From what I have learned, this EGL driver provides OpenGLES 3.x implementation. You may want to see the changes when they have been committed.

After upgrading our RPI sysroot to Raspbian Jessie recently, the RPI-CI build is broken. Jessie differs from Wheezy quite substantially. The problem is, I have no problem cross-compiling SDL 2.0.4 on my Linux host machine so I cannot easily find out what went wrong on the CI server. One thing for sure, the detection logic still has bugs. It is clear to me that some of the checks still erroneously only probing the “things” available in the host environment and not on the target sysroot. That’s the only plausible explanation I could find to explain why it works here locally and not on Travis-CI which is by the way still running on much ancient Ubuntu version 12.04 LTS.

It took me longer than expected to rewrite the FindDirectX.cmake module (was FindDirect3D) as it must be verified against both MSVC and MinGW and to work with Win SDK, DirectX SDK, and MinGW search paths. It should work reasonable well now, except the XAudio2 detection. The Win SDK in my Windows 10 clearly has the xaudio2.h and the corresponding library, but somehow it always failed the has XAudio2 component tests and I have tried a number of ways already. Giving up, really hate Microsoft now. If anyone could point me to the right direction, that would be great. The detection logic is basically just performing a compilation of a simple test source file with the xaudio2.h included. Something like:

# include <xaudio2.h> int main.....
I have tried with windows.h or without, to no avail. I need a short snippet on how to include this header file that compiles cleanly. I don’t think we want to miss out XAudio2.

Anyway, I have moved on to start fixing the SDL library build on Web platform. I have solved the CMake CheckTypeSize() problem, but there are other new issues after that. I have really no idea what kind of rabbit whole I went into.

Do none of the options in this article work for this header?

Is it possible to generate the file and then check file size in CMake? You could compile a small file:

#include <xaudio2.h>

and then preprocess that to a file, and check how the file expands.

I don’t think I have made myself clear last night as it was late for me. The detection logic currently does quite similarly to what you just described and even slightly better, well better if it actually works. It attempts to compile and link a small program with that header included. The error I got on my Win10 is at the compile stage. It complains about something being redefined and something about the GUID for XAudio2 interface. I had also attempted to compile a similar short program manually with a same result, so this is not related to my knowledge of CMake but it is my lack of knowledge with XAudio2.

I’m unfamiliar with Xaudio2 as well.

Here seems to be Microsoft’s example of Xaudio2 sound playback, but it isn’t exactly small: code.msdn.microsoft.com/windows … 1926090356

Can we assume Xaudio2 exists if there is a recent enough SDK installed?

Thanks for the link. Will try to re-look into it when I have the time to boot into my Windows partition again.

I have thought about it too. We could for sure just detect the presence of the header file (as it already does) and declare the corresponding component is found without actually checking if it actually builds ourselves, and leave that to the luck of the module user to find that out later. However, that would be a last resort. If my recently upgraded Windows SDK does not cut it then I am not sure what will. Hopefully, this problem is caused by my own mistake and the link above can shed some light.

You shouldn’t need to compile the file, preprocessing should be enough. Even with compiler errors, the #include statement would be replaced and allow you to check the resulting file size.

Another quick update regarding Web platform before I forget. It is now possible to build the SDL library to bitcode using Emscripten compiler toolchain within our build system. With this change, we are no longer depends on the Emscripten/SDL2 port. I think this is the right direction. Some of you may ask why we have to go all the trouble to fine tune our build system just for this instead of simply doing “-s USE_SDL=2” as we had done in the past. Firstly, it is because our SDL2 source code is a fork with our own modification which Emscripten/SDL2 port does not have. Secondly, it is because we can . We have come up with our own solution to make CMake works with Emscripten compiler toolchain to build the library cleanly. Having said that, there is one thing I am not sure yet how I should proceed. You see, Emscripten team has also made their own changes on top of SDL release 2.0.4. See: github.com/emscripten-ports/SDL … 4aa3a9ca93. Out of 12 files that they change, there are 6 changes on the C source files that we may want to merge. Having said that, without those files being merged yet, I can already run all the CTest successfully. My reservation is, 1) their changes are not marked so we could have identification problem later on, 2) it is their changes, so how do we credit them back if/when we merge those changes into ours. I believe at some point Emscripten team will push their changes to upstream SDL and since there is nothing break at the moment, I will not attempt to merge those yet. Any other views?

Next one. Fix the universal build for iOS and probably OSX as well. As I have commented previously, the new detection logic is so well fine tuned that it can back fire as I predicted.

It looks like those emscripten changes they’ve made are bug-fixes. On the one hand if we maintain the old method, we get bug-fixes for free and simplicity, on the other hand we don’t have much control if things go wrong or when sudden big changes occur.

Can we phase it over, have a CMake option to switch between the homebuilt and -s USE_SDL=2 option?

I am not in favor of having another build option for this. We are already stretching ourselves to support the Emscripten platform. I would like to keep it simple for easier maintenance and support in the future. Last night I was a bit cheeky when I said one of the reason for building the SDL libraries internally is simply because we can. There are other technical reasons why we may want to do so.

[ol][li]Why does we only build SDL differently than the rest of the 3rd-party libraries? After all Emscripten team also has made the ports available for Bullet and FreeType. I am sure Emscripten team has also made more changes (including bug fixes) on top of the point releases of these libraries. As far as I am concerned, we have not noticed anything a miss (yet) by building Bullet and FreeType ourselves and in my limited test last night I also have not noticed any differences with SDL.[/li]
[li]Currently in the master branch where we are still using Emscripten/SDL2 port, we are actually installing the SDL headers from our own Urho3D’s SDL source tree. We are making a big assumption that the headers are compatible with Emscripten/SDL2 port, i.e. we are assuming Emscripten and Urho3D will move in tandem in upgrading the SDL2. We could of course just install the SDL headers from Emscripten’s own system include directory instead, however, last time I checked they make a mistake there. The SDL_config.h that they shipped as part of the Emscripten SDK is totally wrong. It is still the case for their latest master 1.36.0.[/li][/ol]
Arguably, we could say SDL is more important than the other of the 3rd-party libraries. So, we want to have the latest bug fixes available. If everyone agree with this then the only viable option I can see is to do three-way merge each time we perform SDL upgrade. Rebase from upstream SDL then merge Emscripten/SDL2 port; or heck, just rebase from Emscripten/SDL2 port directly as their repo is also derived from a clone of spurious/SDL-mirror, which means they should share the same commit SHAs as our SDL clone repo. And if so, there is one remaining question. How should we credit them back? Is it enough just put the credit in the commit log that those bug fixes/changes are coming from Emscripten-port? I think for this case we could leave the changed lines in the source codes unmarked as they are. As the changes are not ours, we let the Emscripten team takes the full responsibility (and also the blame LOL for that).

The role of SDL on Emscripten should actually be quite small, just setting up the context, piping input, playing audio etc. We should be quite easily be able to verify that our compiled SDL works well enough. In that case I’m too in favor of building it ourselves for consistency, and in case we need our modifications also on Emscripten. Should be interesting to diff what the Emscripten changes to SDL are exactly, though.

Ok. Will keep the thing as it is now in the SDL-2.0.4-upgrade branch until someone confirms that those fixes are absolutely critical.

The exact diff can be seen from the link I gave last night. Click on the “File changed” tab then expand the “12 changed files”. Click on individual to see the accumulated diff between release-2.0.4 and their current HEAD. They just did a tag (version_10) last Jan and the HEAD has not moved since then.

Thanks! Indeed there were some things related to mouse and screen config. Possibly these will make their way to the official SDL repo at some point, too.

Just looked at the SDL build issue for iOS platform. The issue is deeper than I originally thought. Originally I thought the issue is only caused by SDL_config.h is detected for ARM arch and then during build time it is referenced by both iphoneOS and iPhoneSimulator (boom). However, after close inspection there is another more troubling issue. The original SDL detection logic does not work at all on iOS platform! Most if not all the detected results are bogus. Basically all the checks that uses the underlying try_compile() command internally failed to work on iOS. Arguably one can say this is a CMake bug instead of SDL. I have encountered similar issue when enhancing the FindUrho3D.cmake module to use try_compile()/try_run() a few months ago. Although I know exactly how to fix this, it is harder this time to apply the fix because those checks modules are standard modules shipped by CMake, not ours. This CMake bug has been reported to CMake team for years, so I don’t expect it will be resolved anytime soon. What to do?

[ol][li]Copy the standard module(s) that we absolutely need to fix to our CMake/Modules and patch the module(s) there. Bad: The standard modules may change from version to version - maintenance nightmare.[/li]
[li]Fallback to use pre-generated SDL_config_iphoneos.h as currently in the master branch. Bad: Not elegant.[/li][/ol]
I need to sleep on it.

Respect for the huge amount of work you’ve put in for this! (Though it’s disheartening how buggy SDL2.0.4 + CMake seem to be when one intends to go the right way and not take hacks / shortcuts) I’d lean toward 2 because exact SDL revision is something we can control, while CMake can have various versions in the wild.

I have another idea, we could have a “pilot” test to check whether CMake has this bug or not on iOS platform. We can provide a script to let user run externally to patch their own CMake’s standard modules. The fix is rather simple in itself. When the buildsystem detects that pilot test that should have been successful but failed then we know the patch has not been applied and give a fatal error with a message or instruction on how to apply the patch or they cannot continue. The message could also give instruction to enable the fallback to use SDL_config_iphones.h if the user choose not to patch his/her CMake. Best of both worlds.

I have another better idea and I have just quickly tested it and now the detection logic works closer to what I expect. The new idea is actually a CMake hack because it relies on internal knowledge of how those standard check modules work (it also a hack because I don’t think even the CMake team would ever expect it to work this way). The hack itself is not just clean but also easy to implement. It is just one liner in our CMake common module! It basically “injects” the fix that I have talked about in my earlier comment at the end of an existing CMake variable that existing standard modules expect, thus no modifications required to the modules themselves. It is similar to SQL-injection hack.

I am very hopeful now that we could get all the supported platforms build successfully again by tonight. In the meantime though, It is time to enjoy life.

I have almost fixed the SDL build on iOS platform. I hit a wall due to a regression issue caused by other changes that I made to the build system which unfortunately only manifests itself with Xcode. The new CheckCompilerToolchain.cmake module does not work well with Xcode because it does not have native concept. Basically Xcode could invoke clang with different -arch compiler option and produces different ‘native’ compiler defines.

I believe the branch is now ready to be merged. It is not yet perfect but I figure that I would never have enough time to make everything perfect. I will put all those remaining in my TODO list in github.com/urho3d/Urho3D/issues/1046 later. Notably changes on iOS platform after having this detection logic working are:

[ol][li]There is now a new option to enable DLOPEN for iOS when the deployment target is 8.0 or higher. The default value of the option is true. In the past the pre-generated SDL_config_ihoneos.h always have this disabled. Let me know should I make this option off by default even when targeting 8.0+.[/li]
[li]The SDL_AUDIO_DRIVER_DISK is also now enabled.[/li][/ol]
Otherwise, there is actually not much gain there. Most of the gain are actually on Linux platform, we have now a number of audio and video drivers to choose from. Personally I also learn a lot from this exercise. Besides targeting tvOS (which is already possible in my other local branch), I feel like we could target more platforms if we really want to. PowerPC or PS3 anyone?

Unfortunately Travis has a major outage at the moment on their OSX build environment. Will have to restart the CI job manually later when Travis is back to normal, but I have verified the iOS build locally. I will do a final rebase before merging to master branch unless I hear any objections.

It is done.

Superb! I’ll make another manual test run through the platforms in near future.

Great work weitjong ! Thanks for putting the effort in to do things the right way

Awesome !

Nice work!

Thank you all for the nice words. But actually the work has just begun. If you read the comment lines found in the code and in the new GitHub issues raised in relation to this work, and if you could also read what in between those comment lines then you know what I mean .

Have anyone tried to build using D3D11 on Windows 10? I have problem with this build configuration either using MSVC (VS2015) or MinGW on my Windows 10. The build is fine but I got an empty window during runtime. No error, just nothing being rendered. I have downloaded the D3D11 snapshot build artifacts from SF.net and I could run the sample apps without any problem. So, it means our latest build system is fine[?], it also means the D3D11 runtime environment in my Windows 10 is fine. So, what went wrong in my system (really feel like a newbie on the dark side)?

I just tried it, seems to work for me.

By the way, really cool to see all those new CMake options !

I actually don’t remember I had problem before with D3D11 on my Win7 and may be also after I upgraded to Win10. I suspect it has something to do with Windows SDK auto-update a few weeks ago. Anyway, thanks for the confirmation. I will try again later.

I think I know why it failed on my system. I upgraded my MinGW installation as well at the time I upgraded my system to Windows 10. In this new MinGW installation, I have also libd3dcompiler_47.a which was not there before in my old MinGW version. If I recall correctly, I only had _46.a, _43.a, etc together with the unversioned libd3dcompiler.a before. In the past our old FindDirect3D.cmake module was hard-wired to use libd3dcompiler.a and assume it is import library of d3dcompiler_46.dll, which is actually wrong because most of the case it is import library of d3dcompiler_43.dll (Anyway that is not the root cause of my problem). In our new FindDirectX.cmake module, it now tries to search for the latest library available in this order: _47.a, _46.a, _43.a, _42.a. Since now my new MinGW has _47.a, it uses that version for both my D3D9 and D3D11 build. And since the module now knows exactly the version of the library, it also know which DLL version to search for. In this case it found d3dcompiler_47.dll on my Windows SDK and copy that next to the target binary. So far so good. Copying d3dcompiler_47.dll is actually redundant now because this DLL is already available in the Windows system path. So where is my problem? I believe it is the libd3dcompiler_47.a itself. This is just my guess of course. After looking closely I actually got an error in the log for D3D11 API, something like “ERROR: Failed to reflect vertex shader’s input signature”. I don’t have problem with D3D9 API and libd3dcompiler_47.a though.

If this is reproducible by someone else using more recent MinGW then probably we will have to exclude _47 for now in our FindDirectX.cmake module.

I remember seeing that error some time ago on MinGW; at the time I just thought that D3D11 couldn’t be reliably used on MinGW and moved on. Can re-test on a Win10 machine this weekend.

The XAudio2 detection problem is now resolved. The ball is now on our court to how best to utilize all the newly detected audio and video drivers.

Not sure what’s going on but suddenly I’m having troubles building with emscripten. I can generate the build files with cmake_emscripten.bat, but while building I get this error:

[code]-- Check for working C compiler: F:/Emscripten/python/2.7.5.3_64bit/python.exe – broken
CMake Error at F:/msys64/mingw64/share/cmake-3.4/Modules/CMakeTestCCompiler.cmake:61 (message):
The C compiler “F:/Emscripten/python/2.7.5.3_64bit/python.exe” is not able
to compile a simple test program.

It fails with the following output:

Change Dir: F:/Urho3D/Master/BuildEmscripten/Source/Urho3D/tolua+±prefix/src/tolua+±build/CMakeFiles/CMakeTmp

Run Build Command:“F:/msys64/mingw64/bin/mingw32-make.exe”
“cmTC_b45c6/fast”

mingw32-make.exe[4]: Entering directory
’F:/Urho3D/Master/BuildEmscripten/Source/Urho3D/tolua+±prefix/src/tolua+±build/CMakeFiles/CMakeTmp’

F:/msys64/mingw64/bin/mingw32-make.exe -f
CMakeFiles\cmTC_b45c6.dir\build.make CMakeFiles/cmTC_b45c6.dir/build

mingw32-make.exe[5]: Entering directory
’F:/Urho3D/Master/BuildEmscripten/Source/Urho3D/tolua+±prefix/src/tolua+±build/CMakeFiles/CMakeTmp’

Building C object CMakeFiles/cmTC_b45c6.dir/testCCompiler.c.obj

F:\Emscripten\python\2.7.5.3_64bit\python.exe
’F:\Emscripten\emscripten\1.35.0\emcc’ -o
CMakeFiles\cmTC_b45c6.dir\testCCompiler.c.obj -c
F:\Urho3D\Master\BuildEmscripten\Source\Urho3D\tolua+±prefix\src\tolua+±build\CMakeFiles\CMakeTmp\testCCompiler.c

Linking C executable cmTC_b45c6.exe

F:\msys64\mingw64\bin\cmake.exe -E cmake_link_script
CMakeFiles\cmTC_b45c6.dir\link.txt --verbose=1

F:\Emscripten\python\2.7.5.3_64bit\python.exe
’F:\Emscripten\emscripten\1.35.0\emcc’
CMakeFiles/cmTC_b45c6.dir/testCCompiler.c.obj -o cmTC_b45c6.exe

F:\Emscripten\python\2.7.5.3_64bit\python.exe: can’t open file
’‘F:\Emscripten\emscripten\1.35.0\emcc’’: [Errno 22] Invalid argument

CMakeFiles\cmTC_b45c6.dir\build.make:96: recipe for target 'cmTC_b45c6.exe’
failed

mingw32-make.exe[5]: *** [cmTC_b45c6.exe] Error 2

mingw32-make.exe[5]: Leaving directory
’F:/Urho3D/Master/BuildEmscripten/Source/Urho3D/tolua+±prefix/src/tolua+±build/CMakeFiles/CMakeTmp’

clang.exe: warningcipe for target ‘cmTC_b45c6/fast’ failed

mingw32-make.exe[4]: *** [cmTC_b45c6/fast] Error 2

mingw32-make.exe[4]: Leaving directory
: 'F:/Urho3D/Master/BuildEmscripten/Source/Urho3D/tolua+±prefix/src/tolua+±build/CMargument unused during compilation: ‘-mno-sse’

CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
CMakeLists.txt:45 (project)
[/code]

If you are using out-of-source build tree then just nuke your build tree and regenerate it again. If you are inclined you can also just nuke the tolua++ build tree generated by the CMake ExternalProjectAdd() macro. Whichever is more convenient to you.

After re-reading your post, I think you might have already done that. If you still get the same build error after regenerating your build tree then culprit might be the out-dated emcripten.toolchain.cmake file in your project source tree. Look out for CMAKE_LINKER variable. It could also be you already have the latest version, however, this variable setup may only work on Linux host system. Let me know if it is the latter. I added this variable just for completeness sake but if it causes problem then we can do without it or bypass it when on Windows host.

One more thing. There are a still few clean up that I want to do on the SDL CMakeLists.txt before I move on. One of them may impact Emscripten build, but it should be in a good way. I have been comparing the generated header between ours and SDL2 port from Emscripten and found a discrepancy in the GCC_ATOMIC/SDL_ATOMIC settings (see github.com/kripken/emscripten/issues/4191). I have tested a tweak in SDL CMakeLists.txt which reenables the GCC_ATOMIC/SDL_ATOMIC again for Emscripten build and so far so good. Will check in that soon.

I’m quite sure now my issue is something on my end as I’ve tested with an older Urho (that I was previously able to build) and with head, both same error. I tried a few things but I couldn’t find a solution, next thing I’ll try is to build from a VM

Edit:

Well what do you know, just a moment after giving up it seems one last effort was successful. It seems that starting a build off with ‘emmake’ may have been the culprit… ?

I supposed so. I have never used emcmake or emmake with our Urho3D build system. From what I understand, those will setup the host environment behind the scene before passing the control to cmake or make, respectively. I believe they are a blessing for those legacy C/C++ projects to make them portable to web platform without changing a thing in their build system. For our case, however, the situation is rather different. Urho3D build system knows how to configure itself to target the web platform using Emscripten compiler toolchain. So, mixing the two together will probably do more harm than good.

Yeah I didn’t need to in the past either. I didn’t expect using it would dirty the build tree

I should have left it alone. The more I look at it, the more bug I find.

Does it mean that Urho now supports Windows10 UWP apps?
BTW, Great job, guys!

This has been asked before elsewhere. The short answer is no. The longer answer is may be, if someone come forward to make it happen later in the future. What I learnt from the recent SDL upgrade work is that, although the “Windows Runtime” code is available in SDL source tree, none of the configure scripts actually use them. This means the newly integrated SDL CMakeLists.txt does not target WinRT at all currently. But that should not stop anyone who really wants it.

Nice, I noticed you allowed Urho3DPlayer to build in emscripten now. I added some code to allow selecting a lua sample from the query string, I’ll submit the PR soon. Surprising how well the lua samples work in browser.

I think I have changed the original SDL’s CMakeLists.txt so much that it is getting more difficult for me just to mark where my changes begin and end.