Hard Light Productions Forums

Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Test Builds => Topic started by: taylor on February 06, 2005, 12:18:52 pm

Title: 20050206 build - *Linux only*
Post by: taylor on February 06, 2005, 12:18:52 pm
Based on current CVS so it's 3.6.5 with newer changes and fixes.  No nice installers, just binaries that may not work for most people and a source tarball.  All of this code is in CVS so if you prefer to get it from there go to http://scp.indiegames.us/e107_plugins/custompages/CVS%20-%20Getting%20Started.php for the basic CVS setup.

To build from the source you will need:
 - an up-to-date OpenGL setup, ie. current MesaGL or NVIDIA drivers
 - SDL version 1.2.6 or higher
 - OpenAL version 0.0.7 or higher (current CVS is good, openal.org)
 - libjpeg, at least version 6b
 - OGG Vorbis, anything after 1.0 should work

Also of note for the source is that GCC 3.4 has a problem with hudparse.cpp.  GCC 3.3 will build fine but if that is not an option then let me know and I will send you a temporary patch.

./autogen.sh  (for starters)
./configure --help (for available options)

Configure options of note:
 --with-static-ogg={DIR}, use static ogg libs (libogg.a, libvorbis.a, libvorbisfile.a) from specified directory.  Without this it dynamically links against them
 --with-static-jpeg={DIR}, same as above
 --enable-scplite, not supported so don't use it
 --enable-inferno, build an Inferno builds with increased limits but no multiplayer
 --enable-speech, not really ready to use yet but you can get speechd and try it out
 --enable-gprof, build with profiling support but this isn't recommended for most people
 --enable-debug, make a debug build

To use my binaries you will need OpenAL libs but that should be about it.  OGG and JPEG support is built in.  These binaries were built under Fedora Core 3 with all errata applied.  Current CVS of OpenAL was used.  Try them if you want but I would recommend building from source if possible since these binaries were not meant to work on that many systems.

All created (user) files go in ${HOME}/.fs2_open.  When using a debug build all of the output will be directed to ${HOME}/.fs2_open/data/fs2_open.log.  Any invalid cmdline option for the binary (such as --help) will print out a quick list of most options.  One useful option that does not show up in that list is -ambient_factor {int} where {int} is a number specifying the ambient light modifier.  A value of 75 to 80 tends to look the best.

OSX and Linux/PPC are still unsupported for the next week but will probably build and run if you try.  For building on AMD64 you don't have to do anything special as it will automatically detect a 64-bit platform and build for it.  Networking, especially FS2NetD, has not been tested so I would like feedback on that.  If there are no big problems then I will release installers for x86 and x86_64 in the middle of the week.  If you have any questions or comments just put them here.

And no, streaming audio still does not work.  That means no briefing voices yet and no music.  No movies either but that will be fixed pretty soon.

NOTE: I recommend using the -novbo option since OpenGL might have a tendency to crash otherwise when using -spec and/or -glow.

Da Code:
http://icculus.org/~taylor/fso/testing/fs2_open-3.6.5-20050206.tar.gz (3.7Meg)

Da Bins:
http://icculus.org/~taylor/fso/testing/fs2_open-3.6.5-20050206-x86.tar.gz (x86 version, 5.9Meg)
http://icculus.org/~taylor/fso/testing/fs2_open-3.6.5-20050206-x86_64.tar.gz (AMD64 version, 6.0Meg)

Added to the website.//redmenace
Title: 20050206 build - *Linux only*
Post by: Bobboau on February 06, 2005, 12:58:19 pm
might be a good idea to mention this somewere that has a higher linux useage.
Title: 20050206 build - *Linux only*
Post by: Mr_Maniac on February 06, 2005, 03:18:33 pm
Quote
hud/hudparse.cpp: In function `void parse_custom_gauge()':
hud/hudparse.cpp:691: error: `Num_custom_gauges' cannot appear in a constant-expression
hud/hudparse.cpp:692: error: `Num_custom_gauges' cannot appear in a constant-expression
hud/hudparse.cpp:693: error: `Num_custom_gauges' cannot appear in a constant-expression
hud/hudparse.cpp:694: error: `Num_custom_gauges' cannot appear in a constant-expression
hud/hudparse.cpp:695: error: `Num_custom_gauges' cannot appear in a constant-expression
hud/hudparse.cpp:696: error: `Num_custom_gauges' cannot appear in a constant-expression
make[1]: *** [hudparse.o] Error 1
make[1]: *** Waiting for unfinished jobs....
hud/hudtarget.cpp: In function `void hud_target_missile(object*, int)':
hud/hudtarget.cpp:1907: warning: unused variable 'Ship_objs'
make[1]: Leaving directory `/home/maniac/fs2code/fs2_open-3.6.5-20050206/code'
make: *** [all-recursive] Error 1


:(

And why can there be a file that's not there?
In my "/usr/include/GL"  the file "glext.h" existed...
But it didn't exist!?!?!?
ls says it's there..
But all other programs didn't...
But that's solved...
I just created a symlink to /usr/lib/opengl/global/include/glext.h

EDIT:
Sorry, I forgot my system:

AMD Athlon Thunderbird 1.333 GHz
512 MB SD-RAM 133 MHz (non DDR)
GeForce 3 graphics card

CFLAGS="-O2 -march=athlon-tbird -pipe -fomit-frame-pointer"

EDIT2:
Now I've commented out the "parse_custom_gauges" function...
Compiles fine so far...

EDIT3:
New problem... Something with libjpeg I think... But libjpeg is allright...

Quote

Making all in code
make[1]: Entering directory `/home/maniac/fs2code/fs2_open-3.6.5-20050206/code'
g++  -O2 -Wall -I/usr/include/SDL -D_REENTRANT -fsigned-char -Wno-deprecated -Wno-unknown-pragmas  -lGL -lGLU -lopenal -L/usr/lib -Wl,-rpath,/usr/lib -lSDL -lpthread -logg -lvorbis -lvorbisfile -o fs2_open_r  freespace.o levelpaging.o  libcode.a/usr/lib/libjpeg.a
libcode.a(jpgutils.o)(.text+0x16): In function `jpg_error_exit(jpeg_common_struct*)':
: undefined reference to `jpeg_destroy(jpeg_common_struct*)'
libcode.a(jpgutils.o)(.text+0x91): In function `jpeg_cfile_src(jpeg_decompress_struct*, CFILE*)':
: undefined reference to `jpeg_resync_to_restart(jpeg_decompress_struct*, int)'
libcode.a(jpgutils.o)(.text+0x134): In function `jpeg_read_header(char*, CFILE*, int*, int*, int*, unsigned char*)':
: undefined reference to `jpeg_std_error(jpeg_error_mgr*)'
libcode.a(jpgutils.o)(.text+0x16b): In function `jpeg_read_header(char*, CFILE*, int*, int*, int*, unsigned char*)':
: undefined reference to `jpeg_CreateDecompress(jpeg_decompress_struct*, int, unsigned int)'
libcode.a(jpgutils.o)(.text+0x190): In function `jpeg_read_header(char*, CFILE*, int*, int*, int*, unsigned char*)':
: undefined reference to `jpeg_read_header(jpeg_decompress_struct*, int)'
libcode.a(jpgutils.o)(.text+0x1c6): In function `jpeg_read_header(char*, CFILE*, int*, int*, int*, unsigned char*)':
: undefined reference to `jpeg_destroy_decompress(jpeg_decompress_struct*)'
libcode.a(jpgutils.o)(.text+0x26d): In function `jpeg_read_bitmap(char*, unsigned char*, unsigned char*, int)':
: undefined reference to `jpeg_std_error(jpeg_error_mgr*)'
libcode.a(jpgutils.o)(.text+0x2d1): In function `jpeg_read_bitmap(char*, unsigned char*, unsigned char*, int)':
: undefined reference to `jpeg_CreateDecompress(jpeg_decompress_struct*, int, unsigned int)'
libcode.a(jpgutils.o)(.text+0x2f9): In function `jpeg_read_bitmap(char*, unsigned char*, unsigned char*, int)':
: undefined reference to `jpeg_read_header(jpeg_decompress_struct*, int)'
libcode.a(jpgutils.o)(.text+0x305): In function `jpeg_read_bitmap(char*, unsigned char*, unsigned char*, int)':
: undefined reference to `jpeg_calc_output_dimensions(jpeg_decompress_struct*)'
libcode.a(jpgutils.o)(.text+0x352): In function `jpeg_read_bitmap(char*, unsigned char*, unsigned char*, int)':
: undefined reference to `jpeg_start_decompress(jpeg_decompress_struct*)'
libcode.a(jpgutils.o)(.text+0x385): In function `jpeg_read_bitmap(char*, unsigned char*, unsigned char*, int)':
: undefined reference to `jpeg_read_scanlines(jpeg_decompress_struct*, unsigned char**, unsigned int)'
libcode.a(jpgutils.o)(.text+0x3b6): In function `jpeg_read_bitmap(char*, unsigned char*, unsigned char*, int)':
: undefined reference to `jpeg_finish_decompress(jpeg_decompress_struct*)'
libcode.a(jpgutils.o)(.text+0x3c2): In function `jpeg_read_bitmap(char*, unsigned char*, unsigned char*, int)':
: undefined reference to `jpeg_destroy_decompress(jpeg_decompress_struct*)'
collect2: ld gab 1 als Ende-Status zurück
make[1]: *** [fs2_open_r] Fehler 1
make[1]: Leaving directory `/home/maniac/fs2code/fs2_open-3.6.5-20050206/code'
make: *** [all-recursive] Fehler 1
Title: 20050206 build - *Linux only*
Post by: WMCoolmon on February 06, 2005, 03:22:27 pm
Comment out the hudparse lines for now, as long as you don't use any custom hud gauges it shouldn't give you any trouble.
Title: 20050206 build - *Linux only*
Post by: Mr_Maniac on February 06, 2005, 04:03:48 pm
Okay... Now I've tried the binarys.
They work okay! But FS2 only uses 640x480 Interface art (ugly)...
For the rest: It even looks better than under Windoze! Good job...
But I need to figure out why I can't compile... (see my last post)

EDIT:
Okay... I had only tried the techroom...
Missions don't work...
I think I'll have to wait till I can compile it myself...

EDIT2:
Okay... I only cannot fly my own missions...
I've just started the training...
Why does FS2 looks better on Linux than on Windoze?
Hmm...
The Thrust-Control on my Joystick doesn't work (But I can assign it in the options)
Will continue testing tomorrow...
Title: 20050206 build - *Linux only*
Post by: WMCoolmon on February 06, 2005, 04:16:11 pm
I'm having the same libjpeg problem on Windows...
Title: 20050206 build - *Linux only*
Post by: taylor on February 06, 2005, 11:53:41 pm
@Mr_Maniac:  Try not using the static libjpeg.  If you don't use the --with-static part for jpeg then it will link dynamically.  See if that helps any.  It doesn't check to make sure that the static lib is actually usable yet.

@WMCoolmon: I still can't get it to compile under Windows.  It did work since I initially tested the new jpeg code under Windows.  I'm hoping somebody more familiar with MSVC will clue me in.  Even with the libs and headers it complains about unresolved symbols.
Title: 20050206 build - *Linux only*
Post by: WMCoolmon on February 06, 2005, 11:58:05 pm
Well, I used the project file I found on this site (http://toonarchive.com/libjpeg_win32/).

I did modify it to try and link statically, by default it'll build DLLs.
Title: 20050206 build - *Linux only*
Post by: Alpha0 on February 07, 2005, 01:23:23 am
Regarding the libjpeg problem, try to recompile the libjpeg library using g++ instead of gcc - which is the default in the makefile. This should allow proper linking with fs2_open.

I am not familiar with MSVC, but I suspect a similar situation there.
Title: 20050206 build - *Linux only*
Post by: taylor on February 07, 2005, 02:07:20 am
@Alpha0:  I never had a problem with it under Linux but that's just me and I'm using the system libs without having compiled my own.  I think that you are right though since if I play with it some in MSVC I can get what is obviously C vs. C++ related errors.
Title: 20050206 build - *Linux only*
Post by: Mr_Maniac on February 07, 2005, 05:18:53 am
Well... I'd allready tried to compile with libjpeg dynamic and static linked....
Both don't work...
I'll try what Alpha0 suggested...
Title: 20050206 build - *Linux only*
Post by: taylor on February 07, 2005, 05:45:57 am
Just put the jpeglib.h header in code/jpegutils/jpegutils.cpp under C, like this:
Code: [Select]
extern "C" {
     #include <jpeglib.h>
}

and that should fix it.  Already made that change in CVS.  The standard headers in FC3 already have it in jpeglib.h which is why it worked for me.
Title: 20050206 build - *Linux only*
Post by: Mr_Maniac on February 07, 2005, 06:09:23 am
Okay... That fixed it... I can compile now...
But my compiled bin doesn't work...
It shows the splash and exits...
I guess I'll try to play around with my C(XX)FLAGS and LDFLAGS... :)

Oh... And what about the Interface art? It's still 640x480 but I run FS2 at 1024x768...

And what options can I use in my fs2_open.ini?

Sorry that I keep you busy ;)
Title: 20050206 build - *Linux only*
Post by: taylor on February 07, 2005, 06:23:35 am
I'm going to assume that you are using the same VPs that you use in Windows but if not then please list them.  Try a debug build and see what ~/.fs2_open/data/fs2_open.log has in it.

To get beyond 640x480 just edit your fs2_open.ini and change the "VideocardFs2open" line from "OGL -(640x480)x32 bit" to "OGL -(1024x768)x32 bit".  If you are using 32-bit color anyway, otherwise change the 32 to 16.  I'm working on a new in-game options screen which will allow you to do this without editing any files but it isn't ready yet.  Any resolution that X supports you can use in game too.  I don't recommend anything lower than 640x480 but using 1280x1024 or even 1600x1200 is possible.  Using those non-standard resolutions will give you the same offsets that you get in Windows so some text and HUD elements won't be in the right place.  That will get fixed though.
Title: 20050206 build - *Linux only*
Post by: Mr_Maniac on February 07, 2005, 06:47:10 am
You misunderstood...
I am already running fs2_open at 1024x768x32...
And it runs in that resolution...
But it loads the 640 interface art and stretches it (looks very blurry)...
Okay... Now I first ran your debug build (bin)

fs2_open.log (http://home.arcor.de/mr_maniac/ANDERES/Linux/fs2_open.log)

You're right: I used the same vps, models and textures than under Windoze (I just copied them from my Win Partition).

Now I continue testing :)

EDIT(again ;) ):
Even without ANY C(XX)FLAGS and LDFLAGS fs2_open won't load...
I'm building a debug build right now...

EDIT 2:
Hmm... That's strange:
fs2_open_r still doesn't work...
But fs2_open_d does...
Both compiled without any flags...

EDIT 3:
Now BOTH builds work...
Don't ask me why...
But it seems that all builds (also the bins) don't like animated glowmaps...
It always crashes when loading a ship with animated glowmaps...

EDIT 4:
Okay... it weren't the glowmaps... (I tested it without -glow now)
But for some reason every ship with animated glowmaps causes a CTD...
In my posted logfile the last few lines are what the debug build says before it crashes...

Oh... And for the interface art:
I'd ran the builds from an extra directory...
Now I've copied those builds to ~/.fs2_open and now it uses the 1024 interface art...

So everything works... except those ships that have an ani-glowmap :confused:
Title: 20050206 build - *Linux only*
Post by: taylor on February 07, 2005, 08:05:01 am
Make sure that you've got sparky_hi.vp and that it's filename is lower case.  I assume that you have it but if it's not lower case then there may be problems finding it.  It may need to be in the same directory as the binary as well.  Oh and if you can see your windows partition from Linux then you can just symlink the VPs to save HD space.  They don't need to be writable.

For the flags it will most likely not use what you set.  It actually depends on the flag as to whether it does or doesn't but to be sure you can set FS2_CFLAGS and FS2_LDFLAGS with what you want and it will get carried over to the proper place.  I did that because extra flags kept getting added on even without being specified (compiler stuff).  I clear some of them to prevent flags getting used that have extra debugging info or stuff like that.

For the crashing are you using the -novbo cmdline option?  There is a problem with -glow (and maybe -spec) with multitexture.  It should work either way in the techroom but load a mission and it will crash without -novbo.  If that's not what you are seeing then load it in gdb and type "r -novbo -nograb -window" plus any other options that you want.  When it crashes type "bt" and post what it spits out.
Title: 20050206 build - *Linux only*
Post by: Mr_Maniac on February 07, 2005, 09:06:31 am
I've already edited my message...
I already found out that I have to have the binary in the same directory...

And for the cmdline: I already use -novbo...
By the way: What IS vbo? Video Buffer Overflow? Vasudan Beer Owner?
;)

I'll test -nograb later
Title: 20050206 build - *Linux only*
Post by: Bobboau on February 07, 2005, 10:40:13 am
Vertex Buffer ... eh... Object
Title: 20050206 build - *Linux only*
Post by: taylor on February 07, 2005, 11:19:06 am
Quote
Originally posted by Mr_Maniac
I'll test -nograb later

-nograb only does something if you run it in a window.  It will not grab (and hold) your mouse/keyboard input so that you can still have access to your desktop.  When you run something in gdb and it crashes you may not be able to get back to the gdb window unless you use -nograb.  I like it because I can be playing and still keep track of other things but it's main purpose is for debugging.
Title: 20050206 build - *Linux only*
Post by: Mr_Maniac on February 07, 2005, 02:04:56 pm
And now a little CVS How-To (The link in the first post is only for Windows):

To obtain the CVS tree you have to do the following things:
First of all you need to log in and set the CVS-root-directory.

Code: [Select]
cvs -d:pserver:[email protected]:/home/fs2source/cvsroot login

EDIT: Forgot the Password: anonymous

If you get an error like this:
Quote
cvs login: warning: failed to open
/home/comrad/.cvspass for reading: No such file or directory

You'll only have to create a ".cvspass" file in your home directory and repeat the first step
Code: [Select]
touch .cvspass

Now to the final step: Downloading of the tree
Code: [Select]
cvs -z3 -d:pserver:[email protected]:/home/fs2source/cvsroot co fs2_open
This downloads the tree... Now you are finished and able to build the source!
Title: 20050206 build - *Linux only*
Post by: castor on February 07, 2005, 03:05:42 pm
Got it to compile successfully, but run to problems when trying to execute:
Code: [Select]
open /dev/[sound/]dsp: No such device
open /dev/[sound/]dsp: No such device
open /dev/[sound/]dsp: No such device
open /dev/[sound/]dsp: No such device
open /dev/[sound/]dsp: No such device
open /dev/[sound/]dsp: No such device
open /dev/[sound/]dsp: No such device
(null): "DirectSound could not be initialized.
If you are running any applications playing sound in the background,
you should stop them before continuing."
open /dev/[sound/]dsp: No such device

ERROR: "The required OpenGL extension 'GL_EXT_draw_range_elements'
is not supported by your graphics card." at graphics/gropenglextension.cpp:192

Don't know about the sound, could be a problem in my setup. It's the OGL part that worries me.

glxinfo says:
Code: [Select]
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.2
server glx extensions:
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
client glx vendor string: SGI
client glx version string: 1.2
client glx extensions:
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context,
     GLX_NV_vertex_array_range, GLX_MESA_agp_offset
GLX extensions:
    GLX_EXT_visual_info, GLX_EXT_visual_rating, GLX_EXT_import_context
OpenGL vendor string: Tungsten Graphics, Inc.
OpenGL renderer string: Mesa DRI R200 20020827 AGP 1x x86/MMX/3DNow!/SSE TCL
OpenGL version string: 1.2 Mesa 4.0.4
OpenGL extensions:
    GL_ARB_imaging, GL_ARB_multitexture, GL_ARB_texture_env_add,
    GL_ARB_texture_env_combine, GL_ARB_texture_env_dot3,
    GL_ARB_transpose_matrix, GL_EXT_abgr, GL_EXT_bgra, GL_EXT_blend_color,
    GL_EXT_blend_logic_op, GL_EXT_blend_minmax, GL_EXT_blend_subtract,
    GL_EXT_clip_volume_hint, GL_EXT_convolution, GL_EXT_compiled_vertex_array,
    GL_EXT_histogram, GL_EXT_packed_pixels, GL_EXT_polygon_offset,
    GL_EXT_rescale_normal, GL_EXT_secondary_color, GL_EXT_stencil_wrap,
    GL_EXT_texture3D, GL_EXT_texture_env_add, GL_EXT_texture_env_combine,
    GL_EXT_texture_env_dot3, GL_EXT_texture_filter_anisotropic,
    GL_EXT_texture_object, GL_EXT_texture_lod_bias, GL_EXT_vertex_array,
    GL_IBM_rasterpos_clip, GL_MESA_pack_invert, GL_MESA_ycbcr_texture,
    GL_MESA_window_pos, GL_NV_texgen_reflection, GL_NV_texture_rectangle,
    GL_SGI_color_matrix, GL_SGI_color_table
glu version: 1.3
glu extensions:
    GLU_EXT_nurbs_tessellator, GLU_EXT_object_space_tess
etc..

No 'GL_EXT_draw_range_elements' there.. I guess my R200 driver isn't suited for this, damn.
Title: 20050206 build - *Linux only*
Post by: taylor on February 07, 2005, 03:23:27 pm
Quote
Originally posted by castor
No 'GL_EXT_draw_range_elements' there.. I guess my R200 driver isn't suited for this, damn.

You'll need a new version of MesaGL.  Version 5 is the minimum requirement.  I usually include a new library with the installers I make but haven't had time to release them yet for this new build.  You can either get MesaGL yourself and rebuild fs2_open or wait for the installer that should come out later this week.  If you get the new Mesa though it should run with your current video card, maybe not run well but it will run.  Head over to www.mesa3d.org to get a newer version or check your distro for updates.
Title: 20050206 build - *Linux only*
Post by: Sesquipedalian on February 08, 2005, 01:42:42 pm
So, um, pardon my ignorance, but does this mean I might be able to run fs2_open on my Mac soon?
Title: 20050206 build - *Linux only*
Post by: taylor on February 08, 2005, 02:27:37 pm
Quote
Originally posted by Sesquipedalian
So, um, pardon my ignorance, but does this mean I might be able to run fs2_open on my Mac soon?

Yep.  A few networking pieces are still missing but are trivial to get in and then multiplayer should work cross-platform.  Just needs a project file setup to make it easier to build.  I think it will need OpenGL libs that came with newer 10.3 releases though.  I'm trying to figure out exactly what's needed and how to get it working fully on 10.2 and newer.  I hope to put out an OSX build this weekend.
Title: 20050206 build - *Linux only*
Post by: Sesquipedalian on February 08, 2005, 04:05:36 pm
Sweet!

Fred2_open as well? :)
Title: 20050206 build - *Linux only*
Post by: taylor on February 08, 2005, 04:40:47 pm
Quote
Originally posted by Sesquipedalian
Fred2_open as well? :)

Well... you can dream!  ;)

Maybe someday, but not anytime soon.  It will be Windows only for the foreseeable future.
Title: 20050206 build - *Linux only*
Post by: WMCoolmon on February 08, 2005, 06:09:43 pm
Everything but the rendered stuff in FRED needs to be replaced before it'll run on anything besides Windows, basically.
Title: 20050206 build - *Linux only*
Post by: Sesquipedalian on February 08, 2005, 08:48:09 pm
Poop.  Oh well.
Title: 20050206 build - *Linux only*
Post by: Bobboau on February 08, 2005, 09:14:20 pm
Kaz was working on that at one point
Title: 20050206 build - *Linux only*
Post by: Mr_Maniac on February 09, 2005, 05:39:04 am
Well... I think FRED2_open may run under Linux with WineX/Cedega... ;)
But maybe, somewhen in the future it will also run native under Linux...
Title: 20050206 build - *Linux only*
Post by: Goober5000 on February 09, 2005, 04:31:24 pm
We're working on it.
Title: 20050206 build - *Linux only*
Post by: Sesquipedalian on March 04, 2005, 12:05:17 am
So, any OS X yet?
Title: 20050206 build - *Linux only*
Post by: taylor on March 04, 2005, 12:17:22 am
Quote
Originally posted by Sesquipedalian
So, any OS X yet?

Nope.  Haven't had the time.  I've got one or two commits to go in this weekend that are OSX specific (just forgot the first time) but not the project files yet.  I've been too busy on post merge bugs to work on it for any length of time.  I'm pulling out the Mac right now though so I'll try and work on it a good bit this weekend.