Open klaussilveira opened 1 year ago
klaussilveira
commented
1 year ago 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.
KyraDigitalGames
commented
1 year ago 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.
klaussilveira
commented
1 year ago 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?
rokups
commented
1 year ago No issues. Note that include of UrhoCommon.cmake is optional too. It is included there only to provide user projects with extra build system functions, but if they are not used then it is enough to just add_subdirectory(../rbfx ...) and link to relevant targets. Fixing urho build system to support this wont be easy though... I basically rewrote 90%+ of build system because old one was just terrible to work with. My old attempt in upstream urho can be found here. Luckily i still have a fork with old branches. 1vanK apparently deleted bulk of branches some of which had really useful even if unfinished stuff. Thanks 1vanK...
Edit: btw, we made a forum backup: https://urho4d.github.io/t/embedding-the-engine-as-a-submodule-and-cmake-module/1636/
SirNate0
commented
1 year ago 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 xvfb-run, which is what the rakefile adds as a wrapper here.
In particular, I am getting a crash at the call to X11_XIGetClientPointer (upstream), because that function pointer is null. For that matter, so is X11_XIWarpPointer a few lines lines later. Essentially, all of the things that are wrapped in #if SDL_VIDEO_DRIVER_X11_XINPUT2.
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 DEBUG_DYNAMIC_X11 prints in SDL_x11dyn.c. These were the results:
In 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:
Fix: Install the 32 bit libxi: sudo apt install libxi-dev:i386
klaussilveira
commented
1 year ago Does it make sense to continue supporting Linux 32-bit? We could merge this into a 2.0 branch instead of 1.9.
SirNate0
commented
1 year ago Does it make sense to continue supporting Linux 32-bit?
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:
script/cmake_* scripts (the rakefile calls them, or they can be used manually).make to actually do the build. Generally it works fine. Unless it doesn't (e.g. recent fixes to the xcode build). But there's not really anything we can do about that except work around bugs.We could merge this into a
2.0branch instead of1.9.
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).
rokups
commented
1 year ago 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.
klaussilveira
commented
1 year ago We use the dockerized-build-environment within the github actions. This is also not that bad - it basically just caches all the dependencies that would need to be installed for us, and the end user can somewhat easily use it themselves. Ideally, we would just set up a container following our installation instructions, and the dockerfile should serve as an example of following the installation instructions.
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 master and see how far it gets us? I think it is OK to temporarily lose platforms on master until the build is stable and regains compatibility.
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.