That'll translate to checking each commit on somebody with a win 7 box from Commits on May 19, 2019 to probably around Commits on May 24, 2019.When launching T3D 4.0 Test 2 (May 25 2019) this error appears. Did not occur with prior Test 1 (May 20 2019).
Good spots on all this, I'll make sure to get this rolled in.Hey, I've been attempting to compile the Pre-Release in Linux and so far have some case-sensitive problems. In customShaderFeature.cpp - line 23, it was CustomShaderFeature.h but was supposed to be customShaderFeature.h.
Damn case-sensitivity.
In meshREnderSystem.h, I changed, #include "core/util/SystemInterfaceList.h" to #include "core/util/systemInterfaceList.h"
There were some others too.
In renderProbeMgr.h, I had to change
Code: Select all
inline bool ProbeRenderInst::operator ==(const ProbeRenderInst& b) const
toCode: Select all
inline bool operator ==(const ProbeRenderInst& b) const
I got it to compile without errors and the executable would only run from command line.
I used
Code: Select all
CMAKE_EXE_LINKER_FLAGS -no-pie
re-compiled and the executable would run with a double click. I don't really know what -nopie means but I read it isn't the best practice.Code: Select all
CMAKE_EXE_LINKER_FLAGS_RELEASE -no-pie
When I enter a level, there are a ton of errors that I believe may stem from case-sensitivity in Linux.
I will check more into it.
Thanks
Had you been keeping up with the development fork from time to time, or would this be a prior master to these forks as far as checking in goes? We shifted the backend to openal-soft a few months ago, so it may be something tripping there...Going to dig into this today (likely an issue on my end based on the feedback so far) but all of the builds fail to run on my system. They show the Torque3D splash screen and then immediately close. Console log seems normal, last line is 'sfxStartup...' but that's not particularly helpful.
This is on a Win10 machine with a 1060 3GB card.
Fix is here , this also enables using the t3d supplied openal-soft version for linux as well, so all 3 platforms will now use the same openal-soft build. Should give @ practicing01 credit for the EFX fix, his original can be found hereShould note the OpenAL end of things on mac was a bit of a hack that cost us the new reverb stuff on that platform. At some point we'll need to revisit that to sort out how to properly use the git-included library instead of the os framework to leverage the AL_ALEXT_PROTOTYPES extended functionality.
Thanks Jeff, I admit that I haven't had to much time to look into the actual script errors but I uploaded the "working" Linux friendly source if anyone wants to compile it.Good spots on all this, I'll make sure to get this rolled in.Hey, I've been attempting to compile the Pre-Release in Linux and so far have some case-sensitive problems. In customShaderFeature.cpp - line 23, it was CustomShaderFeature.h but was supposed to be customShaderFeature.h.
Damn case-sensitivity.
In meshREnderSystem.h, I changed, #include "core/util/SystemInterfaceList.h" to #include "core/util/systemInterfaceList.h"
There were some others too.
In renderProbeMgr.h, I had to change
Code: Select all
inline bool ProbeRenderInst::operator ==(const ProbeRenderInst& b) const
toCode: Select all
inline bool operator ==(const ProbeRenderInst& b) const
I got it to compile without errors and the executable would only run from command line.
I used
Code: Select all
CMAKE_EXE_LINKER_FLAGS -no-pie
re-compiled and the executable would run with a double click. I don't really know what -nopie means but I read it isn't the best practice.Code: Select all
CMAKE_EXE_LINKER_FLAGS_RELEASE -no-pie
When I enter a level, there are a ton of errors that I believe may stem from case-sensitivity in Linux.
I will check more into it.
Thanks
On the no-pie thing, I did some reading and it seems like it's more just a "it's less secure this way because it doesn't get punted into random memory", but since it actually lets the thing run without any hoop-jumping, then unless something else crops up for why it's bad to use, I'm sorta inclined to have it be the default.
We could probably have that be an option in cmake so if someone wants that added security and is willing to juggle the extra headache of the security measures messing with stuff, they can.
Thanks Jeff, I admit that I haven't had to much time to look into the actual script errors but I uploaded the "working" Linux friendly source if anyone wants to compile it.
Good spots on all this, I'll make sure to get this rolled in.
On the no-pie thing, I did some reading and it seems like it's more just a "it's less secure this way because it doesn't get punted into random memory", but since it actually lets the thing run without any hoop-jumping, then unless something else crops up for why it's bad to use, I'm sorta inclined to have it be the default.
We could probably have that be an option in cmake so if someone wants that added security and is willing to juggle the extra headache of the security measures messing with stuff, they can.