Mac users, where are you guys?
Re: MAC users, where are you guys?
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
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
Re: MAC users, where are you guys?
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, 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?
Re: MAC users, where are you guys?
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:
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 **
Re: MAC users, where are you guys?
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.
Re: MAC users, where are you guys?
Ari wrote on the ML, that this is the result of bison being too old.twilight wrote: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 **
Re: MAC users, where are you guys?
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).
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).
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 wrote:That looks like the texture index for the tiles is wrong half a tile in one direction.
-
- Inactive
- Posts: 1695
- Joined: 01 Sep 2006, 19:17
Re: MAC users, where are you guys?
Can you make a screenshot of that, too?Baum wrote: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.
The sky looks like the texture itself is corrupted (or does the corruption move?). Doesn't seem connected to the terrain problem.Baum wrote: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 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 wrote: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?
Re: MAC users, where are you guys?
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
with
in src/texture.c (in the function texLoad()).
To apply the magic number, I replaced the line
Code: Select all
tileTexInfo[k].uOffset = (float)xOffset / (float)xSize;
Code: Select all
tileTexInfo[k].uOffset = (float)xOffset / (float)xSize - 0.0315f;
The corruption is static.cybersphinx wrote: The sky looks like the texture itself is corrupted (or does the corruption move?).
Re: MAC users, where are you guys?
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.
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.
Re: MAC users, where are you guys?
But isn't that a little odd? I mean, I updated to the newest bison, except SVN_Version of bison there is noBuginator wrote:Ari wrote on the ML, that this is the result of bison being too old.
newer one out there I am trying to get the Snapshot-Package to build, but as Baum said, it may not
make a difference.
Re: MAC users, where are you guys?
I just did. Besides that I get that quesoglc-problem again (which I know how to avoid now ) the buildBaum wrote: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.
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.
Re: MAC users, where are you guys?
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.
Re: MAC users, where are you guys?
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?!
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?!
Re: MAC users, where are you guys?
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?).
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?).
Re: MAC users, where are you guys?
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)
EDIT: I created a wiki page with the symlinks at the bottom: http://wiki.wz2100.net/Mac_OS_X_Compile_Guide_(2.1)
Last edited by Baum on 23 Jun 2008, 09:37, edited 1 time in total.