Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Cross-Platform Development => Topic started by: RBL_Holmes on January 07, 2010, 01:10:12 am
-
Hi, I'm trying to setup a standalone FS0 server on a headless linux box running a rather old OS (Suse 9.3). I pulled the 3.6.10 final source down and compiled it.
I did have one fatal compile error regarding sound/ds.cpp regarding a const char to ALubyte conversion. I simply commented out line 1974 to get around it (bad hack I know but I do not need sound anyway... or video for that matter):
//AL_play_position = alIsExtensionPresent( "AL_LOKI_play_position" );
After getting a clean build, test running in a X11 vnc environment it seems to get stuck in a loop. It seems to start when reading the default missions. strace yields the following snippet:
open("/usr/local/FreeSpace2/Root_fs2.vp", O_RDONLY) = 5
fstat64(5, {st_mode=S_IFREG|0644, st_size=6404494, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40896000
_llseek(5, 6045696, [6045696], SEEK_SET) = 0
read(5, "ition: 2\r\n\r\n$Mission: sm3-09.fs2"..., 446) = 446
read(5, "$Name: Templar\r\n$Type: multi coo"..., 4096) = 4096
_llseek(5, 6050238, [6050238], SEEK_SET) = 0
close(5) = 0
munmap(0x40896000, 4096) = 0
time(NULL) = 1262847057
select(5, [4], NULL, NULL, {0, 0}) = 0 (Timeout)
select(5, [4], NULL, NULL, {0, 0}) = 0 (Timeout)
select(5, [4], NULL, NULL, {0, 0}) = 0 (Timeout)
time(NULL) = 1262847057
time(NULL) = 1262847057
time(NULL) = 1262847057
time(NULL) = 1262847057
gettimeofday({1262847057, 619135}, NULL) = 0
select(0, NULL, NULL, NULL, {0, 0}) = 0 (Timeout)
select(0, NULL, NULL, NULL, {0, 10000}) = 0 (Timeout)
time(NULL) = 1262847057
select(5, [4], NULL, NULL, {0, 0}) = 0 (Timeout)
select(5, [4], NULL, NULL, {0, 0}) = 0 (Timeout)
select(5, [4], NULL, NULL, {0, 0}) = 0 (Timeout)
time(NULL) = 1262847057
time(NULL) = 1262847057
time(NULL) = 1262847057
gettimeofday({1262847057, 628578}, NULL) = 0
... to infinity.
Any ideas?
-
Does this happen if you make a build using a current svn checkout?
-
I just checked it out and tried it, same issue.
If it helps any I got allot of compiler warnings:
warning: converting to non-pointer type `char' from NULL
and had the same issue with the sound/ds.cpp:
sound/ds.cpp: In function `int ds_init(int, int, unsigned int, short unsigned
int)':
sound/ds.cpp:1460: error: invalid conversion from `const char*' to `const
ALubyte*'
I did the same dirty hack to get it built.
I couple of notes that may or may not help. I copied the game folder from an installed win32 box. File permissions are all set within the game to the same user running the script.
Edit:
It does not seem to be making it past initialization. I cannot get it to draw a window even in debug. (on either version).
Edit2:
It does seem to be at least getting to the point of opening a network socket:
netstat -lnp|grep fs2
udp 0 0 0.0.0.0:7808 0.0.0.0:* 563/fs2_open_svn
3.6.10 exhibits the same
My client fails to connect to either.
Edit3:
gcc is rather old on this machine (3.3.x) I'm going to upgrade it and see if that helps.
-
Right. Bumping this over to cross-platform development, where it rightly belongs.
-
Upgrading gcc certainly helped as I was able to make a debug fso build, however the same issue remains, but now with a debug log. I'll put a small snippet of it here where the gettimeofday looping in the strace starts:
outwnd not initialized yet... STUB: std_destroy_gen_dialog in network/stand_gui-unix.cpp at line 56, thread 17958
outwnd not initialized yet... STUB: std_create_gen_dialog in network/stand_gui-unix.cpp at line 41, thread 17958
outwnd not initialized yet... STUB: std_gen_set_text in network/stand_gui-unix.cpp at line 66, thread 17958
outwnd not initialized yet... STUB: std_gen_set_text in network/stand_gui-unix.cpp at line 66, thread 17958
outwnd not initialized yet... Found required string [$Name:]
outwnd not initialized yet... Stuffed string = [FreeSpace 2 - Part 1]
outwnd not initialized yet... Found required string [$Type:]
outwnd not initialized yet... Stuffed string = [multi coop]
outwnd not initialized yet... Found required string [$Name:]
outwnd not initialized yet... Stuffed string = [FreeSpace 2 - Part 1]
outwnd not initialized yet... Found required string [$Type:]
outwnd not initialized yet... Stuffed string = [multi coop]
outwnd not initialized yet... Stuffed int: 4
outwnd not initialized yet... STUB: std_gen_set_text in network/stand_gui-unix.cpp at line 66, thread 17958
outwnd not initialized yet... Found required string [$Name:]
outwnd not initialized yet... Stuffed string = [FreeSpace 2 - Part 2]
outwnd not initialized yet... Found required string [$Type:]
outwnd not initialized yet... Stuffed string = [multi coop]
outwnd not initialized yet... Found required string [$Name:]
outwnd not initialized yet... Stuffed string = [FreeSpace 2 - Part 2]
outwnd not initialized yet... Found required string [$Type:]
outwnd not initialized yet... Stuffed string = [multi coop]
outwnd not initialized yet... Stuffed int: 4
outwnd not initialized yet... STUB: std_gen_set_text in network/stand_gui-unix.cpp at line 66, thread 17958
outwnd not initialized yet... Found required string [$Name:]
outwnd not initialized yet... Stuffed string = [FreeSpace 2]
outwnd not initialized yet... Found required string [$Type:]
outwnd not initialized yet... Stuffed string = [Single]
outwnd not initialized yet... STUB: std_gen_set_text in network/stand_gui-unix.cpp at line 66, thread 17958
outwnd not initialized yet... Found required string [$Name:]
outwnd not initialized yet... Stuffed string = [Templar]
outwnd not initialized yet... Found required string [$Type:]
outwnd not initialized yet... Stuffed string = [multi coop]
outwnd not initialized yet... Found required string [$Name:]
outwnd not initialized yet... Stuffed string = [Templar]
outwnd not initialized yet... Found required string [$Type:]
outwnd not initialized yet... Stuffed string = [multi coop]
outwnd not initialized yet... Stuffed int: 8
outwnd not initialized yet... STUB: std_destroy_gen_dialog in network/stand_gui-unix.cpp at line 56, thread 17958
outwnd not initialized yet... Tried to unload right_bracket.pcx that has a load count of 121.. not unloading
outwnd not initialized yet... STUB: std_do_gui_frame in network/stand_gui-unix.cpp at line 61, thread 17958
outwnd not initialized yet... STUB: std_do_gui_frame in network/stand_gui-unix.cpp at line 61, thread 17958
outwnd not initialized yet... STUB: std_do_gui_frame in network/stand_gui-unix.cpp at line 61, thread 17958
outwnd not initialized yet... STUB: std_do_gui_frame in network/stand_gui-unix.cpp at line 61, thread 17958
outwnd not initialized yet... STUB: std_do_gui_frame in network/stand_gui-unix.cpp at line 61, thread 17958
outwnd not initialized yet... STUB: std_do_gui_frame in network/stand_gui-unix.cpp at line 61, thread 17958
outwnd not initialized yet... STUB: std_do_gui_frame in network/stand_gui-unix.cpp at line 61, thread 17958
-
Does this box even have a virtual xserver of some sort? The standalone is not command line based, to my knowledge, even on *nix. Also the *nix standalone support is only a few months old, so you're probably in treacherous waters.
-
Does this box even have a virtual xserver of some sort? The standalone is not command line based, to my knowledge, even on *nix. Also the *nix standalone support is only a few months old, so you're probably in treacherous waters.
Yep it's runnin an xorg-x11 inside vncserver with a kde window manager. All other graphical apps (non 3d of course) seem to work fine. It does appear to be hanging at window creation eh? According to ldd it is finding the x11 libs.
I seem to always be in those waters LOL no worries. I can try and help where I can.
-
I've been poking around some more at this. If I run it without the -standalone option, in other words just try and run the game normally I get exactly the same results with one exception of a new frametime output:
outwnd not initialized yet... Frame 0 too long!!: frametime = 521.481 (0.033)
outwnd not initialized yet... STUB: std_do_gui_frame in network/stand_gui-unix.cpp at line 61, thread 28943
Should it be using the stand_gui stuff if standalone is not selected?
I checked my opengl setup, glxgears tested ok... running within VNC I get 404 FPS LOL I'm sure that's nowhere near the true FPS my eyes are seeing heheh but it opened a window and displayed turning gears.
Are all graphical outputs in the game opengl, even the 2d stuff? I'm trying to follow the code but getting my eyes crossed in places heh
Would there be any version dependencies on opengl?
-
The standalone server has never been implemented for anything other than Windows, so that would be the majority of your problem. ;)
-
I'd like to see what a log of the compiling errors/warnings is, please. I have a vested interest in trying to resolve as many of those as possible, but I've lately still been stuck in windows, so I only (currently) see the MSVC ones.
-
The standalone server has never been implemented for anything other than Windows, so that would be the majority of your problem. ;)
heheh so I'm finding out ;D However in my last test the problem I'm seeing seems purely graphics related, so looks like there may be some issues there too :)
I'd like to see what a log of the compiling errors/warnings is, please. I have a vested interest in trying to resolve as many of those as possible, but I've lately still been stuck in windows, so I only (currently) see the MSVC ones.
I'll do another build with gcc3 and attach an output log. I resolved that hack with the sound, my openAL was way out of date, installing the latest allowed me to build without any code hacking.
On another note gcc4.3.4 I cant seem to get a good build again... not sure if it's due to my running gcc4 from a localized install or not (I dont want to overwrite gcc3). I can attach a log up to where it fails also if you want.
-
Here you go Zacam. Attached are two gzipped tarballs each containing a Makefile, config.log, and compiler output from gcc3 and gcc4; using svn 5792. The gcc4 build bombs out, but I dont know if that's due to my build env not being perfected for it yet.
[attachment deleted by admin]
-
The standalone server has never been implemented for anything other than Windows, so that would be the majority of your problem. ;)
Taylor, someone did have a qt gui standalone running on Linux recently, but now I can't recall if that made it into our codebase or not. Was stand_gui-unix.cpp always around and just a stub? I was thinking that was related to it but now I'm not sure.
-
Out of curiosity I loaded up a vmplayer with the latest opensuse on my vista machine. I get the same results just trying to load the game with provided binaries of 3.6.10 final, or my own rolled from svn.
I'm wondering if it has to do with direct rendering at all? The old headless server I've been bangin on of course with the vnc x11 will be software rendering only, and I cannot get direct rendering to engage in this darn vmplayer.
Seems like good constants anyway considering others have made the game work on linux... I'm assuming they also had dri/glx working properly in their x11 setup for 3d gaming to allow direct render.
P.S. Building with gcc4 works fine on the latest opensuse so my build env for gcc4 must be confused on the old machine. :nervous:
-
The standalone does sometimes seem to need certain requirements that don't make sense for a simple windowed application, so that's a distinct possibility.
-
The standalone does sometimes seem to need certain requirements that don't make sense for a simple windowed application, so that's a distinct possibility.
Hi chief, I've been running my latest tests without using the -standalone argument. I've tried no arguments at all and each one individually, all yielding the same result... the outwnd just wont initialize. I did almost get a window in the ddd/gdb debugger with no command arguments, but not sure how or why. I'm not a developer, more of a sysadmin, but I'm having fun poking at it. It has my curiosity heheh
-
The game itself probably does need DRI of some sort, although I thought the non-accelerated stuff on Linux would work ok for getting the game to start. It just wouldn't be playable really.
-
Taylor, someone did have a qt gui standalone running on Linux recently, but now I can't recall if that made it into our codebase or not. Was stand_gui-unix.cpp always around and just a stub? I was thinking that was related to it but now I'm not sure.
Yeah, it was always just a stub. It was stubbed in the icculus.org version originally, which was copied into FSO, and has never been touched since in either code base.
I'm not sure of the status of that WX version, was a patch ever posted for it? Either way it may not be that good of an idea to add it officially anyway, since it means adding a dependency on WXwidgets. I'm still hoping for a good web (or java) based standalone server which isn't simple a copy of the old (crappy) Windows GUI. In other words, a system daemon which can be administered/monitored by an external UI.
I've been running my latest tests without using the -standalone argument. I've tried no arguments at all and each one individually, all yielding the same result... the outwnd just wont initialize.
outwnd doesn't get initialized until a little later in the startup process, so it's possible that it just isn't getting that far. Also make sure that you don't have any cmdline arguments on cmdline_fso.cfg (either in ${HOME}/.fs2_open/data/ or the game data/ directories), since it definitely looks like you still have -standalone specified somewhere.
The game doesn't really need direct rendering to work (on Linux anyway), but will give you 2-3 seconds per frame without it. :) And if glxgears is giving you 404 FPS then FSO wouldn't be anywhere near playable. You would have to get in the 3000-4000 range to be basically playable I think. Still, it would start up and get you through the menus at least.
-
Thanks Taylor, you're a genius! There was indeed a cmdline_fso.cfg in the game data directory... and it had a -standalone in it :eek2:
Removing that file worked, game opens up to a menu now yeay. Solves that mystery heheh
-
Then I guess Wine would still be needed for Linux standalone.
-
Right, it was wx not qt, my bad. It was posted by Spicious here (http://www.hard-light.net/forums/index.php?topic=64174.0), and the diffs have been deleted. The builds are still there, but 6 months old now.
-
.
[attachment deleted by admin]
-
It's working, it's working!
Working great so far on my new VM. It will be awhile on my old machine... wx is old heh
Thanks Spicious!!!
-
Hey Spicious, with this patch can you choose between the wx or the MFC version of standalone on Windows via defines, or does it clobber the old one?
-
The MFC version should be preserved but I haven't tried it (recently).
-
It's not an MFC standalone - it's actually Win32 :)
-
And a huge thank you for the logs RBL_Holmes, it seems I have a good bit more work a head of me still. Many of them are resolvable with the current Warnings Resolution patch, but I will have to make a GCC-Resolution .patch to address the findings here.
-
Ah true, forgot the standalone compiles just fine on express editions :)
Yeah Zacam, depending on the compiler version there's a whole boatload of gcc-only warnings. I can get you a log from the linux nightly box sometime if you want.
-
Pretty please? Thank you!
Any xcode warnings under Mac OS X by any chance?
-
It's not an MFC standalone - it's actually Win32 :)
Oh yes, but it's nothing to be smiling about :p
-
OS X is GCC so it should be about the same as Linux. 99% identical at least.