Upgrade to SDL 2.26.4 #4
Comments
|
I think newer Wayland breaks the current SDL, though it sounds like the newer version fixes it. Or in my case just disabling VIDEO_WAYLAND in CMake, as I use X11. |
|
I started this upgrade to gauge how complex it would be and quickly realized it wouldn't be a walk in the park. I'm considering adding a bounty to it so we can attract outside developers to the project that would be willing to tackle this, preferably with SDL experience. |
|
Its not very hard to get it running on SDL 2.26.5 (Tested on Windows ony). We only have to exclude not needed features to make the build faster. Before we make the push we should decide how to handle dependencies in the future. We should change the dependencies to git submodules and link directly to the needed tag. Also we should not change de CMakeLists.txt of the projects directly and should configure it through an external CMakeLists.txt. This would make version migrations a lot easier. |
|
I like the way rbfx does it: https://github.com/rbfx/sample-project/blob/master/CMakeLists.txt#L40 Discussion that sparked it: https://web.archive.org/web/20221127090414/https://discourse.urho3d.io/t/embedding-the-engine-as-a-submodule-and-cmake-module/1636 @eugeneko @rokups have you guys had any issues with this approach? Would you recommend U3D following those steps? |
|
No issues. Note that include of Edit: btw, we made a forum backup: https://urho4d.github.io/t/embedding-the-engine-as-a-submodule-and-cmake-module/1636/ |
|
Finally had a little bit of time to come back to this. I think I may have tracked down the issue for the 32 bit linux builds. I'm not sure what exactly is the cause, but when I do my own 32 bit linux build with the dockerized build environment, I do get a segmentation fault when running sample 11_Physics, but only when I run it using In particular, I am getting a crash at the call to Basically, I am thinking that xvfb-run is not supporting xinput2, but the build system detected that we have it because the library is installed and would be available in a normal X11 environment. I've not investigated any of that, but it seems plausible. Notes from a little extra debugging. I enabled the Long list of symbols64 bit build without missing symbolsIn contrast, there is no segmentation fault if I run the executable directly in the terminal without using xvfb-run, but I am fairly certain that is because there are no events SDL responds to, so that code with the missing symbol never ends up being called: Backtrace from `xvfb-run gdb -ex=r 11_Physics`Fix: Install the 32 bit libxi: |
|
Does it make sense to continue supporting Linux 32-bit? We could merge this into a |
Since it should be easier to support than the raspberry pi, I am inclined to say yes, we should continue supporting it. I like that Urho is able to target older and lower-powered hardware. Really, I think the problem is more with our github actions setup rather than anything really to do with the Urho library itself. There are several layers of magic that happen in such a build:
Since it's just an semi-minor update to one of the ThirdParty libraries (really it's just the build system part that is all that complicated to the changes), I am inclined to say we still aim for 1.9. I would rather have much more significant changes with 2.0, if we decide we want some of them (different scripting support, additional shader types like compute/geometry, maybe different containers). I'm not committed to that, but it seems to me that getting SDL upgraded and CI working better would be good things to finish out 1.9 (and allow easier maintenance if we want a 1.9.1 with some new features back-ported to it). |
|
Anyone that uses linux for the desktop uses 64bit OS. There is a tiny tiny portion of people who use 32bit linux specifically to make use of their very old hardware. As you can imagine such old hardware has limited capabilities of running games, provided there happens to be a person interested in games made with urho at all. |
I started this branch to try and move away from the dockerized build environment and rake. I think that it adds too much friction and complexity to an already annoying task (building). The biggest challenge on it was the emscripten build: https://github.com/u3d-community/U3D/tree/workflows Should we try and merge that branch into |
|
Solved by #81 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
No description provided.
The text was updated successfully, but these errors were encountered: