-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Required changes to the Torque3D to make it Linux-compatible. #19
Conversation
…can build it on Linux too.
Compiled this in Ubuntu x64 with the packages build-essential, nasm, git, php5-cli, libsdl-dev and libogg-dev. Seems to work fine, though when compiling it ignored some of the ogg headers in the engine which is why libogg-dev was required. I was also able to load a mission with spaces in the filename, e.g.:
Also managed to connect with a windows client using this code with TORQUE_APP_NAME set to "Full" using:
However I was unable to connect to the server using a stock 1.2 MIT client. It seems the changes made to the ShadowMapParams have broken something in the netcode when reading "cookie" in "ShadowMapParams::unpackUpdate". Otherwise great work! |
Yeah, unfortunately it doesn't work with stock MIT client :( ... so the changes should be applied on both - the linux server and windows client. |
Judging by the LightMapType stuff, it seems your code is creating an empty light type the first time you initialise the light types with "LightInfoExType ShadowMapParams::Type( "" );" which appears to screw up the netcode which sends empty strings. If I remove the added module init and change the lines to:
It allows 1.2 clients to connect and still compiles, at least with GCC 4.6.3. |
So, it does start up on Linux? I was getting a crash until I moved setting the type to the MODULE-stuff.
That comment is not directly about LightInfoExType (it was only about engineAPI macro usage), but without that change I was getting crashes on Linux. |
I'm attempting to compile under RedHat Linux 6.3 64bit on an Amazon micro instance (ami-cc5af9a5). I've installed the following packages: "Development Tools" group, php, SDL-devel, SDL-static, libogg-devel, and nasm. Everything seems to go fine until I hit the following error for Debug/Full/platformX86UNIX/x86UNIXRedbook.cpp.o: In file included from /usr/include/SDL/SDL_main.h:26, This is using gcc 4.4.6 and the latest of all the packages I would assume (allowed yum to choose). It doesn't look like I'm missing any SDL packages based on my yum search. Any thoughts from you Linux experts? I may move over to Ubuntu as that is what I usually gravitate to. I just wanted to try out RedHat to be different from what you guys have already tried. |
I've never tried to build it on RedHat. |
@just-bank CentOS would be your best bet. @DavidWyand-GG I would check the paths to see if it is different than Ubuntu but I doubt it. This error should only relate to the distro if it failed to include a file because it does not know uint8_t exists or how much memory to allocate for it. I am at a loss on it being a different distro would effect this unless there was a conditional for an include file. Like it does not think you have the hardware for this library or two different libraries depending on your version. I wish I could be more help. Only our VOIP servers run CentOS and that has been my exposure to RedHat derivatives and we where migrating those to Ubuntu as well. |
I started to set up my Ubuntu server when I realised that I didn't do an update on my RedHat server. That very likely is my issue. Once that update completes I'll try another compile. |
uint8_t is the C99 type for an unsigned 8 bit integer. It is defined in stdint.h. Looking at /usr/include/SDL/SDL_stdinc.h, it apparently assumes that either stdint.h (GNU/Linux) or inttypes.h (MSVC) are present and does not bail out in case neither is. From the error message you get, it seems your SDL_config.h does not define HAVE_STDINT_H (or is never actually included, etc). |
@DavidWyand-GG I've got it compiled/linked on CentOS 6.3 x86_64 (and I had the same error message). All I need to do is to manually install 32-bit devel libs if running 64bit OS: yum install glibc-devel-2.12-1.80.el6_3.5.i686
yum install libstdc++-devel-4.4.6-4.el6.i686
yum install SDL-devel-1.2.14-3.el6.i686 (those are versions I have on my fresh CentOS 6.3 box) make clean before re-building. Actually, any 64-bit Linux requires you to have installed 32-bit versions of libs. P.S. Will also push the fix for GCC 4.7.x (which is used in openSUSE 12.2), but after I test it on a couple of other Linux boxes. |
Pushed the fix for newest GCC (4.7.x). Everything seems to be fine. With the CentOS - it compiles fine and the binary is linked.
|
Maybe a bit off-topic but I have a question: Bank had commented on a ticket for the CE group that a Bullet physics enabled client could not connect to a linux server built with his changes. Is this still the case? If so, what happens with a PhysX enabled client? I ask because it seems from general feeling that this will eventually work it's way into the development branch and I wouldn't want our physics changes (if a pull request is sent) to interfere with this. |
@thecelloman You got it a bit wrong:
|
Another update: installed regular (32-bit) CentOS 6.3 - same crash at the same place. Update: Works on Fedora 17. |
I <3 Linux and would love to see these changes land. |
is this to run dedicated servers? or to run the client on linux? |
@intangir dedicated servers only. |
I'm waiting for this to land in development so as to have a look at what the client needs to run. |
Looks like GCC (4.4.x) on RHEL is built with some optimization flags, which caused crash inside assembler code (when using inline-cast: uint->uchar->uint from GetNzbSubID down to find_maskwidth). Tested this change on 7 different distros, so far - everything seems to be working.
Pushed fix for RHEL-based distros. |
@just-bank Thanks for pointing out what I still needed to do under 64bit. I believe this is the first time I've tried to compile Toque under 64bit given its 32bit nature. And thanks for the additional commit to fix the crash. I'll try out all of your changes here again. |
Good work @just-bank. I've taken everything as-is, but we may want to revisit the light type code you modified as @jamesu pointed out. We don't want to create an empty light type if we can help it. |
I'll play around with LightType-thingy some time during this week. Thanks for the merge btw! :) |
@just-bank That sounds great. I'll create a ticket just to track the issue. I was holding off on posting my latest blog because I wanted to get your changes in. :) |
Hi Just bank. I'm over here from the Torque thread. You referred me here about possibly creating a client for linux. What is missing again that needs to get added to make this work as a client? |
I am also interested in assissting with a linux client |
@weaponx69 and all others: |
Sorry for double posting but I put this in a GG forum post, and thought it might be rewarding to ask here as well... I'm trying to do a dedicated server build on 64 bit ubuntu 12.10, and got almost all the way through, except ran into linker errors apparently related to my 64 bit version of gcc? Or else the wrong version of STL / sdl ? Apologies for my ignorance, but here's the error messages: /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.7/libstdc++.so when searching for -lstdc++ More details about the libraries I installed to get this far in this post: http://www.garagegames.com/community/forums/viewthread/132650 Thanks for all the great work you guys!! Chris Calef |
Fixed specular order in deferred shading material feature types.
I've got Torque 3D MIT (dedicated build only) running on Linux box (OpenSUSE 12.1 x64).
Also, got successfully connected from Windows 7 build (based on same sources) via LAN.
This doesn't change any functionality, so everything will work the same way as a stock version.
Build instructions (assuming my changes are applied to the code base):
Keep in mind, that mission files should not contain spaces in its name.
Also, if you make custom/own projects, I would recommend to store it under Torque3D/Projects folder instead of Torque3D/My Projects so it doesn't contain spaces in folder name. It will save you a lot of headaches.