Mac users, where are you guys?

[twilight]

thx EvilGuru, Baum, Per, you guys are really awesome

Anyway, the compile-problem persists, at least on my machine.
Seems to have something to do with the difference of the hand-compiled
and copied bison-version or the fink-one. At least that is the only difference
I see between Baum and me.

Regards,

twilight

[Baum]

I'll see if I can get anywhere with the texture problem.

twilight, I tried building both the current daily trunk snapshot and the latest 2.1 branch using the version of Bison I downloaded from the GNU website and both builds were eventually successful. I had an error from Bison parsing a file the first time I tried building the trunk snapshot but the second attempt (same exact command as the first) completed successfully. Are you still getting the same errors as before?

[twilight]

yes, I am still getting the same error. I tried several times with updating via svn,
and the updates are successful, but building afterwards is not...

Just from today, same error:

Code: Select all

    setenv WRAPPER_SUFFIX .app
    setenv XCODE_APP_SUPPORT_DIR /Developer/Library
    setenv XCODE_VERSION_ACTUAL 0250
    setenv XCODE_VERSION_MAJOR 0200
    setenv YACC /Developer/usr/bin/yacc
    /bin/sh -c cd\ \"${DERIVED_FILES_DIR}\"\ ||\ exit\ 1
bison\ -y\ -d\ -o\"${INPUT_FILE_BASE}\".tab.h\ \"${INPUT_FILE_PATH}\"\ ||\ exit\ 1
bison\ -y\ -d\ -o\"${INPUT_FILE_BASE}\".tab.c\ \"${INPUT_FILE_PATH}\"\ ||\ exit\ 1
/Users/thommy/2.1/macosx/../lib/framework/resource_parser.y:51: unrecognized: %name_prefix
/Users/thommy/2.1/macosx/../lib/framework/resource_parser.y:51:    Skipping to next %
/Users/thommy/2.1/macosx/../lib/framework/resource_parser.y:61: unrecognized: %destructor
/Users/thommy/2.1/macosx/../lib/framework/resource_parser.y:61:    Skipping to next %
** BUILD FAILED **

[Baum]

Have you tried building the trunk snapshot from the download page? I don't know why that would work over the SVN checked-out 2.1 branch but it's worth a try. If you can't figure it out by this weekend I can try to get my hands on a clean install of OS X to try to build the 2.1 branch on to see what I needed to do/install.

[Buginator]

yes, I am still getting the same error. I tried several times with updating via svn,
and the updates are successful, but building afterwards is not...

Just from today, same error:

Code: Select all

/Users/thommy/2.1/macosx/../lib/framework/resource_parser.y:51: unrecognized: %name_prefix
/Users/thommy/2.1/macosx/../lib/framework/resource_parser.y:51:    Skipping to next %
/Users/thommy/2.1/macosx/../lib/framework/resource_parser.y:61: unrecognized: %destructor
/Users/thommy/2.1/macosx/../lib/framework/resource_parser.y:61:    Skipping to next %
** BUILD FAILED **

Ari wrote on the ML, that this is the result of bison being too old.

[Baum]

Update to the texture bug I posted a screenshot about on the last page:

It seems the problem doesn't crop up when using a texture size of 32 (but does with sizes 64 and 128). I've had some success in getting the textures to re-align by subtracting a magic number from the terrain textures' uOffset but I'm pretty sure the problem is deeper than this as a few tiles have a stretched texture from clamping and a weird floating polygon thing appears in the first single player level when the magic number is in use.

I've noticed that the sky background is also having a texture issue (see attached image), which leads me to an uneducated guess that maybe the problem enlies in the texture paging code (if it's common to both terrain and sky textures). I haven't looked into this at all yet.

I have no experience in programming anything with any sort of graphics so any ideas/comments would be appreciated (especially on whether or not I may be heading in the right direction).

That looks like the texture index for the tiles is wrong half a tile in one direction.

I'm not sure what you mean about the texture index. Isn't the index an integer(s)? Or is this the same thing as the u and v texture page offsets?

[cybersphinx]

It seems the problem doesn't crop up when using a texture size of 32 (but does with sizes 64 and 128). I've had some success in getting the textures to re-align by subtracting a magic number from the terrain textures' uOffset but I'm pretty sure the problem is deeper than this as a few tiles have a stretched texture from clamping and a weird floating polygon thing appears in the first single player level when the magic number is in use.

Can you make a screenshot of that, too?

I've noticed that the sky background is also having a texture issue (see attached image), which leads me to an uneducated guess that maybe the problem enlies in the texture paging code (if it's common to both terrain and sky textures). I haven't looked into this at all yet.

The sky looks like the texture itself is corrupted (or does the corruption move?). Doesn't seem connected to the terrain problem.

I'm not sure what you mean about the texture index. Isn't the index an integer(s)? Or is this the same thing as the u and v texture page offsets?

I think we mean the same thing, I just used "index" because it points to one tile in the larger texture. Adding a magic number to the offset is a quick workaround, the real question is why this is necessary on the Mac and not on other systems.

[Baum]

The screenshot of the magic number is attached. The screenshot is of the terrain with a texture size set to 64 but the same effect can be seen with a texture size of 128. When the texture size is set to 32 (and the magic number is in use), the textures are offset in a manner similar to the 64 and 128 textures without the number.

To apply the magic number, I replaced the line

Code: Select all

tileTexInfo[k].uOffset = (float)xOffset / (float)xSize;

with

Code: Select all

tileTexInfo[k].uOffset = (float)xOffset / (float)xSize - 0.0315f;

in src/texture.c (in the function texLoad()).

The sky looks like the texture itself is corrupted (or does the corruption move?).

The corruption is static.

[digt]

Just wanted to say a big THANK YOU to all you guys working on the Mac version!

I had never even heard of this game before and only stumbled upon it while looking at some projects at SourceForge. It may not be polished but it sure is a gem, good luck to all of you guys.

[twilight]

Ari wrote on the ML, that this is the result of bison being too old.

But isn't that a little odd? I mean, I updated to the newest bison, except SVN_Version of bison there is no
newer one out there I am trying to get the Snapshot-Package to build, but as Baum said, it may not
make a difference.

[twilight]

Have you tried building the trunk snapshot from the download page? I don't know why that would work over the SVN checked-out 2.1 branch but it's worth a try. If you can't figure it out by this weekend I can try to get my hands on a clean install of OS X to try to build the 2.1 branch on to see what I needed to do/install.

I just did. Besides that I get that quesoglc-problem again (which I know how to avoid now ) the build
failes with the exact same error than via svn.

one thing I find a little bit weird is that this error seems to be related to bison, which I updated
to 2.3

Code: Select all

bison --version
bison (GNU Bison) 2.3
Written by Robert Corbett and Richard Stallman.

Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Baum]

Twilight, what version of Xcode/dev tools are you using? When I tried building the trunk on a clean OS X system, I got your same errors using Xcode/dev tools 2.5. But when I tried building using dev tools version 2.4.1, the trunk build succeeded. I say "dev tools" only because I installed 2.5 first, ran "uninstall-devtools", and then installed 2.4.1 which, apparently, left Xcode at version 2.5 while the dev tools (whatever those are) were downgraded.

[twilight]

I indeed installed version 2.5. But since I did not have xcode installed on this mac,
I just used the 2.5-version. So I guess no "downgrading", huh?

--- just did the "uninstall-devtools", which leave me with nothing at all.
No gcc, no gdb, no bison, no xcode... So I guess downgrade is not an option?!

[Baum]

Once you uninstall version 2.5, install version 2.4.1. I found 2.4.1 on my OS X install CD but it looks like you can get it from this link as well: https://connect.apple.com/cgi-bin/WebOb ... leID=19681.

Once I got it built, however, I experienced this bug: https://gna.org/bugs/?11619. I'm pretty sure you can get around this by adding symlinks to the dylibs that aren't found as, for example, fontconfig.1.dylib is not found but fontconfig.1.0.dylib exists. `ln -s /usr/X11R6/lib/libfontconfig.1.0.dylib /usr/X11R6/lib/libfontconfig.1.dylib` should fix the first path but you'll probably need to do this for a few more libraries. For some reason these symlinks already existed on my first machine (maybe something to do with having X11 installed?).

[Baum]

Actually, you don't need to install Xcode 2.4.1... The problem with Xcode 2.5 occurs because it uses the version of Bison in /Developer/usr/bin (which is v1.28) and not the one used found by using your PATH variable (which you had updated to version 2.3). If you run `mv /Developer/usr/bin/bison /Developer/usr/bin/bison-1.28 && ln -s /usr/local/bin/bison /Developer/usr/bin/bison`, the problem should go away (you may need to substitute '/usr/local/bin/bison' with the path to your Bison 2.3).

EDIT: I created a wiki page with the symlinks at the bottom: http://wiki.wz2100.net/Mac_OS_X_Compile_Guide_(2.1)