Closed GoogleCodeExporter closed 9 years ago
I used the ioquake3 sys/ files which should be x86_64 bit compatible, but the
makefile and the other parts probably arent (yet)
Original comment by frederik...@gmail.com
on 23 Feb 2011 at 8:32
So is there no way currently to build bzzwolfsp on x86_64? (I have the same
problem)
Original comment by johannes...@gmail.com
on 13 Mar 2011 at 3:52
I'm working on it; a lot of code needs to be fixed but I'm almost there.
Hopefully the owner of this code.google project will accept my changes. If not,
I will start a new one.
Original comment by aschilham@gmail.com
on 14 Mar 2011 at 9:24
sounds good aschilham, once it works, I'll give you svn acces, so you can
commit !
Original comment by frederik...@gmail.com
on 14 Mar 2011 at 9:41
Any progress on this? I'm stuck on a segfault in FS_PathCmp... Any ideas?
Aschilham?
Original comment by vtr...@gmail.com
on 29 Apr 2011 at 8:42
Compilation is fine for me, and the game might be running fine, but I cannot
see it: There is some problem with the lighting/rendering because the scenes
are almost completely dark. I'm stuck with this problem since March.
Original comment by aschilham@gmail.com
on 30 Apr 2011 at 11:27
yeah the game is pretty dark for me too, I've tweaked some r_ cvars to make it
brighter
I havent worked on it lately, didn't have much free time and I'm stuck with the
player animations for now
Original comment by frederik...@gmail.com
on 2 May 2011 at 12:01
Well that's different: in 32 bits the lighting is acceptable, but in my 64 bits
version I literally cannot see anything (apart from the 'slides' in the intro
scene or some special lights like the sparks in the torture chamber). I cannot
figure out if all the colors are wrong and everything is rendered as black, or
if the direction of the light or sight is inverted, or if shadows are rendered
in front of the objects or whatever. Any an all suggestions are welcome.
@vtr: Try if changing the first line of FS_PathCmp from "int c1,c2;" to "char
c1,c2;" solves the problem. If not, the problem is not in FS_PathCmp but
earlier in the filling of the strings.
Original comment by aschilham@gmail.com
on 2 May 2011 at 3:40
Problem not only in FS_PathCmp, but also in paksort function. In arguments to
qsort function you need to replace 4 with sizeof(char*)
Original comment by iSage....@gmail.com
on 22 May 2011 at 10:11
same problem here on archlinux, after adding defines it compiles but segfaults.
data files are in place
[maci@T61 debug-linux-x86_64]$ gdb wolfsp.x86_64
GNU gdb (GDB) 7.3.1
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from
/home/maci/Desktop/bzzwolfsp-read-only/build/debug-linux-x86_64/wolfsp.x86_64...
done.
(gdb) run
Starting program:
/home/maci/Desktop/bzzwolfsp-read-only/build/debug-linux-x86_64/wolfsp.x86_64
[Thread debugging using libthread_db enabled]
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff6db823c in ?? () from /lib/libc.so.6
(gdb) bt
#0 0x00007ffff6db823c in ?? () from /lib/libc.so.6
#1 0x0000000000468305 in Q_strncpyz (dest=0x15ce440 "",
src=0xffffffffffffea8e <Address 0xffffffffffffea8e out of bounds>,
destsize=256) at src/game/q_shared.c:837
#2 0x000000000052ee36 in Sys_SetBinaryPath (
path=0xffffffffffffea8e <Address 0xffffffffffffea8e out of bounds>)
at src/sys/sys_main.c:60
#3 0x000000000052f92d in main (argc=1, argv=0x7fffffffe7e8)
at src/sys/sys_main.c:617
Original comment by maci.s...@gmail.com
on 30 Nov 2011 at 6:06
These last problems are because certain functions don't have prototypes
defined. I've fixed that and ran into issues with memset causing a crash. I
can provide a patch that fixes current SVN up to the point where I'm getting
crashes.
Original comment by sa666...@gmail.com
on 8 Dec 2011 at 10:25
that would be great !
Original comment by frederik...@gmail.com
on 9 Dec 2011 at 7:32
working on it!
Original comment by frederik...@gmail.com
on 17 Jan 2012 at 3:30
the problem is that a 64bit client cannot connect to a 32bit server (and vice
versa) without modifications in the network code, if I understand the problem
correctly, so making the game compile under 64bit isn't a huge deal, but
keeping it compatible with other architectures is
Original comment by frederik...@gmail.com
on 18 Jan 2012 at 5:13
(temporary) workaround: compile it 32 bit.
replace the line "COMPILE_ARCH=$(shell uname -m | sed -e s/i.86/i386/)" in the
makefile by "COMPILE_ARCH=i386". Works for me on Fedora 16 x86_64.
Original comment by r...@rolffokkens.nl
on 5 Feb 2012 at 11:20
thanks for the info ! I'll test it asap on rhel and centos 64bit
Original comment by frederik...@gmail.com
on 5 Feb 2012 at 5:56
When attempting the workaround on a 64bit Fedora 16, I get:
/usr/bin/ld: cannot find -lsupc++
collect2: ld returned 1 exit status
I probably need to install some 32 bit c++ lib package but yum search cant find
it.
Original comment by richard....@gmail.com
on 8 Feb 2012 at 10:13
search for libstdc++-devel-4.1.2-51.el5.i386 (this is an example from a redhat
5 installation)
Original comment by frederik...@gmail.com
on 10 Feb 2012 at 7:53
So if I understand correctly, there are basicly two 64bit issues. Issue 1 is
that the client itself does not support 64 bit's and issue 2 is that a 64bit
client could not connect to a 32bit server and vice versa.
But is there any hope of getting issue 2 fixed untill 1 is complete? Also,
going ahead with issue 1 would make SP players like myself extreemly happy
campers :)
Original comment by richard....@gmail.com
on 18 Feb 2012 at 4:47
So the workaround from rolf doesn't work for you ?
There's always hope ;) When I have time to focus on this issue I hope I'm able
to fix it, but currently there is so much to be done and so less time, so it
will take a while before I get my hands on it.
Original comment by frederik...@gmail.com
on 18 Feb 2012 at 5:10
Yes, I can build and run 32bit binaries just fine. My problem is that I
really dont want to have to install all those 32bit libraries needed for this
to work...
Makes my system more complex than it has to be :)
Original comment by richard....@gmail.com
on 18 Feb 2012 at 6:35
Fixed in latest trunk revision 1331 (Full 64 bit support on all platforms)
Original comment by M4N4T4RMS
on 29 Dec 2013 at 4:19
Original issue reported on code.google.com by
aschilham@gmail.com
on 22 Feb 2011 at 10:03