OpenTomb
OpenTomb copied to clipboard
opentomb
How to handle Bullet?
As we already saw Bullet 2.82 is broken. That effectively makes CMake project broken as well, because nobody ships Bullet 2.83 in known Linux distributions. The question is: should we return Bullet as a submodule?
I guess there's no way around until 2.83+ becomes widely available. Until then, I'd suggest another approach for building bullet: instead of using add_subdirectory, we should use add_custom_target etc. in conjunction with the system commands to simulate a separate build. With this approach, we can be sure to not mess with bullet's internal build config.
How it is possible that buggy Bullet is distributed with Linux at all? :imp: Maybe there's a way for CMake to check Bullet version? And if not, then use a submodule?
If they'd fixed it, there would be different behavior with different releases (patched and unpatched). But as long as we avoid using bullet's conversion functions, there shouldn't be any problem with the system lib, I think.
I actually believe that my bug with rotation is also related to Bullet. It happened one more time, but after full rebuild it gone away... :angry:
I've implemented possibility to optionally compile Bullet as a third party library. Just clone Bullet in 3rdparty/bullet and remove any alternatives. If there is a system library it will be preferred.
About engine build: I was trying GCC_TDM_5.1_x86_x64 (universal compiler version) and GCC_TDM_5.1_x86 only version and rebuild engine for x86 platform. Same code, same compiler and linker flags, both PE are i386 compatible, BUT different Bullet working! GCC_TDM_5.1_x86_x64 produce build with pretty buggy physics. And in all cases was -O2 (-O3 did not increase fps); GCC_TDM_5.1_x86 only produce build with correct bullet behavior.
Right. I only use gcc 4.9.2 and don't even think about upgrading. I usually upgrade once in a two-three years and every time it's a big pain in the butt. I don't want to spend a few weeks just to fix all the brokenness.
gcc 4.9.2 is a good version, 5.1 x86 not bad too. In my case using x64 compiler version was a very big pain in the butt. This time I working in new place (programmer) and study corporate programming techniques :-) Too many experience, but little time + I need more practice. Hope I will find more time for OT project little later. To Cochrane: may be offtop, but I have idea how to complete remove sticks for colored polygons: add manually white texture to the atlas (4x4 or 8x8) as a first unique texture and use special atlas function to assign white texture coordinates for polygons in tr_setupColoredFace(...);
To Cochrane: may be offtop, but I have idea how to complete remove sticks for colored polygons: add manually white texture to the atlas (4x4 or 8x8) as a first unique texture and use special atlas function to assign white texture coordinates for polygons in tr_setupColoredFace(...);
We're already doing that. Ever since the bordered texture atlas was introduced.
At least for my linux distribution (gentoo) bullet 2.83.4 is default stable version and latest unstable is 2.86 so this issue is probably outdated!?
Probably it is. But it might have other issues as well, e.g. Bullet is plagued with performance issues depending on compiler and optimization. Changing horses in midstream is dangerous, at least without wide test coverage.