Vega Strike Forums

So I've been following Vega Strike for a while now, but am compiling from SVN for the first time. This isn't the first program I've compiled and I've also been a linux user for a while. The wiki cautioned that this would be considered difficult but I had no idea what I would be up against.

I checked out version 12760 source and data and followed the instructions here: http://vegastrike.sourceforge.net/wiki/ ... ile_on_OSX

- I already had SDL installed via MacPorts
- My OS is 10.5.8 and comes with OpenAL via apple

I soon discovered that the built-in GCC was not up to the task (giving errors with the templates in units.cpp).I Upgraded GCC and G++ to 4.4 via macports. This took a while. When this was done I next discovered a errors in the aldrv/ files. After some research I discovered that this was because Apple's OpenAL header is broken (so is the one from MacPorts) and will not work with C++. The fix is to edit the header (yikes) and replace all occurances after the first of "ALCvoid" wth "void". That done, I corrected a few more mistakes with my configuration and vegastrike compiled and linked successfully. The program now runs but segfaults early on with an error reading units.csv, and now I'm stumped. Any suggestions?

./vegastrike
In path /Users/danwaldron/vegastrike-dev/vegastrike
Vega Strike
See http://www.gnu.org/copyleft/gpl.html for license details.

GOT SUBDIR ARG =
Found data in /Users/danwaldron/vegastrike-dev/vegastrike/../data
Using /Users/danwaldron/vegastrike-dev/data as data directory
Using .vegastrike as the home directory
Found MODDIR = /Users/danwaldron/vegastrike-dev/data/mods
USING HOMEDIR : /Users/danwaldron/.vegastrike As the home directory
CONFIGFILE - No config found in home : /Users/danwaldron/.vegastrike/vegastrike.config
CONFIGFILE - No home config file found, using datadir config file : /Users/danwaldron/vegastrike-dev/data/vegastrike.config
DATADIR - No datadir specified in config file, using ; /Users/danwaldron/vegastrike-dev/data
SIMULATION_ATOM: 0.05
MISSION_NAME is empty using : main_menu.mission
Attempt to call ReadFull on a bad file units.csv units /Users/danwaldron/vegastrike-dev/data
Segmentation fault


- I have uploaded config.log as an attachment.

- The command used to run configure (from the file intel-mac-conf.sh) is this (may be of value to other mac users):
./configure CC=/opt/local/bin/gcc-mp-4.4 \
CPP=/opt/local/bin/cpp-mp-4.4 \
LDFLAGS=-L/opt/local/lib \
CPPFLAGS=-I/opt/local/include \
--with-expat-libs=/opt/local/lib --with-expat-inc=/opt/local/include \
--with-png-libs=/opt/local/lib --with-png-inc=/opt/local/include \
--with-jpeg-inc=/opt/local/include --with-jpeg-libs=/opt/local/lib \
--with-ogg-inc=/opt/local/include --with-ogg-libs=/opt/local/lib \
--with-vorbis-inc=/opt/local/include --with-vorbis-libs=/opt/local/lib \
--with-python-inc=/opt/local/include/python-2.5 --with-python-libs=/opt/local/lib/python2.5 \
--enable-macosx-bundle

- I also edited part of the configure script to help find the right libraries. I had some trouble because this part of the script was overriding arguments I passed by hand.

f test "x$is_macosx" = "xyes" ; then
CXXFLAGS="$CXXFLAGS -I/Developer/SDKs/MacOSX10.4.u.sdk/System/Library/Frameworks/Carbon.framework/Libraries/CIncludes -DHAVE_PYTHON=1 -I$with_python_inc -I/System/Library/Frameworks/OpenAL.framework/Headers"
CPPFLAGS="$CPPFLAGS -Wno-long-double"
# VS_LIBS="$VS_LIBS -F/Developer/SDKs/MacOSX10.4.u.sdk/System/Library/Frameworks -framework OpenGL -framework GLUT -framework CoreAudio -framework OpenAL"
VS_LIBS="$VS_LIBS -F/System/Library/Frameworks -framework OpenGL -framework GLUT -framework CoreAudio -framework OpenAL"
with_gl_inc=/Developer/SDKs/MacOSX10.4.u.sdk/System/Library/Frameworks/Carbon.framework/Libraries/CIncludes
with_gl_libs=/Developer/SDKs/MacOSX10.4.u.sdk/System/Library/Frameworks/OpenGL.framework/Libraries
with_al_inc="/System/Library/Frameworks/OpenAL.framework/Headers"
with_al_libs="/System/Library/Frameworks/OpenAL.framework"
# with_al_inc="/opt/local/include/openal"
# with_openal_libs="opt/local/lib"

# PYTHON_LDOPTS="-L/System/Library/Frameworks/Python.framework"
# with_python_inc="/System/Library/Frameworks/Python.framework/Headers"
VS_LIBS="$VS_LIBS -lobjc -L$with_python_libs"
fi

Please recompile with debugging symbols (if you didn't build with debugging symbols), and run vegastrike through gdb.

When it segfaults, and shows the gdb prompt (gdb), type "bt" and attach the resulting output - it will help a lot in figuring out what the problem is.

Here it is. End of the file is pasted in, full GDB output is the attachment.

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x16d00000
0xffff08c2 in ___memcpy () at /System/Library/Frameworks/System.framework/PrivateHeaders/i386/cpu_capabilities.h:246
246 /System/Library/Frameworks/System.framework/PrivateHeaders/i386/cpu_capabilities.h: No such file or directory.
in /System/Library/Frameworks/System.framework/PrivateHeaders/i386/cpu_capabilities.h
(gdb) bt
#0 0xffff08c2 in ___memcpy () at /System/Library/Frameworks/System.framework/PrivateHeaders/i386/cpu_capabilities.h:246
#1 0x91c933ad in fread ()
#2 0x0031c7cd in VSFileSystem::VSFile::ReadFull (this=0xbfffc948) at src/vsfilesystem.cpp:1720
#3 0x00097167 in CSVTable (this=0x24a4530, f=@0xbfffc948, root={static npos = 4294967295, _M_dataplus = {<std::allocator<char>> = {<__gnu_cxx::new_allocator<char>> = {<No data fields>}, <No data fields>}, _M_p = 0xbfffc9b0 "l?F\002\001"}}) at src/cmd/csv.cpp:146
#4 0x00302d33 in InitUnitTables () at src/universe_generic.cpp:368
#5 0x007449c5 in SDL_main (argc=1, argv=0x2437d60) at src/main.cpp:263
#6 0x007a802c in -[SDLMain applicationDidFinishLaunching:] ()
#7 0x976f742a in _nsnote_callback ()
#8 0x9299e47a in __CFXNotificationPost ()
#9 0x9299e753 in _CFXNotificationPostNotification ()
#10 0x976f4680 in -[NSNotificationCenter postNotificationName:object:userInfo:] ()
#11 0x976fded8 in -[NSNotificationCenter postNotificationName:object:] ()
#12 0x96629df2 in -[NSApplication _postDidFinishNotification] ()
#13 0x96629d01 in -[NSApplication _sendFinishLaunchingNotification] ()
#14 0x965a381b in -[NSApplication(NSAppleEventHandling) _handleAEOpen:] ()
#15 0x965a3014 in -[NSApplication(NSAppleEventHandling) _handleCoreEvent:withReplyEvent:] ()
#16 0x9771ca9f in -[NSAppleEventManager dispatchRawAppleEvent:withRawReply:handlerRefCon:] ()
#17 0x9771c7af in _NSAppleEventManagerGenericHandler ()
#18 0x91b09648 in aeDispatchAppleEvent ()
#19 0x91b0957e in dispatchEventAndSendReply ()
#20 0x91b09425 in aeProcessAppleEvent ()
#21 0x92dda981 in AEProcessAppleEvent ()
#22 0x965a08e9 in _DPSNextEvent ()
#23 0x9659ff88 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#24 0x96598f9f in -[NSApplication run] ()
#25 0x007a87c0 in main ()
Current language: auto; currently asm

Santo Buffer Underflow!

That code is evil to unimaginable levels!

Whenever I have the repo at hand (in a writable fashion) I'll correct, commit and post. Thanks for the backtrace

(I bet this is the same bug that has been hauting windows testers of the newest binary - thing is, getting a backtrace in windows is a lot harder )

Attempt to call ReadFull on a bad file units.csv

Yes, I've seen this on Windows and Linux as well, but it doesn't segfault there.

shenle wrote:

Attempt to call ReadFull on a bad file units.csv

Yes, I've seen this on Windows and Linux as well, but it doesn't segfault there.

Some people have complained of crashing binaries - not sure which version.

@macghost: Anyway, I committed a fix yesterday (or was it the day before?) - so if you want to try again you may

The fix works. My first test immediately crashed, which is a fault of what I did to get it to compile but indicitave of another problem. I un-defined NV_CUBE_MAP - which must be defined or causes assert(false); in gl_state.cpp at line 71.

With NV_CUBE_MAP restored it won't compile in gl_state.cpp because on the mac OpenGL GL_TEXTURE_CUBE_MAP_EXT doesn't exist. You have to use GL_TEXTURE_CUBE_MAP instead.

To get it to compile I had to go into the source and remove " _EXT" from following:

GL_TEXTURE_CUBE_MAP_EXT
GL_TEXTURE_CUBE_MAP_POSITIVE_X_EXT
GL_TEXTURE_CUBE_MAP_NEGATIVE_X_EXT
GL_TEXTURE_CUBE_MAP_POSITIVE_Y_EXT
GL_TEXTURE_CUBE_MAP_NEGATIVE_Y_EXT

There was a crash when the program tried to load a file called mac.technique. I had a look at some of the techniques files and duplicated default.technique as mac.technique. This may be a configuration program. I haven't compiled vssetup and my hand-editing of the config file is likely to be problematic.

I have a working main menu!
Launched a new campaign... seems to be working. And I have an in-station view with blinking lights! But it looks like my ship didn't render right. On clicking launch it's very slow when anything is on the screen, and the planet is very messed up. This is probably due to my shit macbook intel graphics. But it runs.

WOW! Congratulations!
This is really good news! I thought it was going to take a lot more work to get svn head to compile for MACs.
Could you summarize the needed changes formally?
Klauss, are you on it?, or should I try to commit these changes?

The new vsfilesystem.cpp in r12763 gives the following: in stderr, instead of now I get just
These are on Windows and Linux BTW; the older stderr output is from r12742

I have no experience with autoconf on UNIX. I had to hand-edit the configure file but I will see what I can do.

in the OpenGL headers, is the change from GL_TEXTURE_CUBE_MAP_EXT to GL_TEXTURE_CUBE_MAP something that will work on other systems' versions of GL? Or is it something we would have to check for?

Dan

macghost wrote:I have no experience with autoconf on UNIX. I had to hand-edit the configure file but I will see what I can do.

in the OpenGL headers, is the change from GL_TEXTURE_CUBE_MAP_EXT to GL_TEXTURE_CUBE_MAP something that will work on other systems' versions of GL? Or is it something we would have to check for?

Probably something that will work universally; my guess; as "_EXT" stands for "extension" and probably dates back to prehistoric times, when cube-maps were something so new that there was no official support for them in openGL. But I'll let Klauss do the final pronouncements.

@Klauss: Don't miss shenle's post.

macghost wrote:I have no experience with autoconf on UNIX. I had to hand-edit the configure file but I will see what I can do.

in the OpenGL headers, is the change from GL_TEXTURE_CUBE_MAP_EXT to GL_TEXTURE_CUBE_MAP something that will work on other systems' versions of GL? Or is it something we would have to check for?

Dan

I'll make the relevant headers check for existence of GL_TEXTURE_CUBE_MAP first, that would work on all platforms and be self-adaptable, so we don't have to tinker with configure and the likes.

About the slowness, that's why there was a mac.technique, macs have weird sweet spots, even though they supposedly use NVidia GPUs. Thing is, without a dev (a graphics dev) able to write the shader variants for the macs, I'm not sure how to handle the issue.

You might try using one of the lower-end techniques for mac.technique instead - say... fixed.technique (or fixedgl.technique). That will be a serious hit on graphics quality, but at least it will be usable.

I swapped in fixedgl and the planet is now playable. Ships render correctly now also. There's a massive framerate hit (like from over 60 to less than 10) as soon as the mining base is visible. Haven't tested it more than that. My macbook is one of the older ones with intel graphics so it basically can't do shaders.

fixedgl is no shaders.

You could try fixed, which uses shaders (but does nothing fancy). If it works (I'm not sure how much shader support your intel board has), it's faster because it's a single pass technique (compared with fixedgl which has to do many passes to get the same results).

fixed doesn't need a lot - a GeForce3 could handle it. Technically speaking, it doesn't use shaders, it uses "register combiners" - so give it a try.

fixed5 is like fixed but supports less lights (so it's faster).