I finally got shell at x86_64 box =:-).
Thanks D-Kure for it

Well i did some hacks with Makefile, then build all needed libs and then ezQ.
I'm not sure will it work or not.

Here are download link:
http://ezquake.sourceforge.net/test/ezquake-linux-x86_64.tar.gz

Report here is it OK or fails for you =:-)

Does not work for me because of 64 bit issues with libpng. On startup I get:

libpng error: Invalid image width
Received signal 11, exiting...

However I do have a fix:

edit pngconf.h and replace
typedef unsigned long png_uint_32;
typedef long png_int_32;

with

typedef unsigned int png_uint_32;
typedef int png_int_32;

then recompile libpng and ezquake.

OR

recompile ezquake without -DWITH_PNG, but this will require some small modifcation to hud_common.c since its blindly makes use of png.h without checking if WITH_PNG is defined.

It segfaults randomly for me

You're a fake! Acre doesn't exist!!!

--//--

Segfauts! Your are really complicated Elluan!

I think it will take even more effort to port this to x86_64, given that there are MANY places where the code assumes data sizes. Lordhavoc has done a wonderful work on this for Darkplaces, but Darkplaces isn't Quake anymore. It has been practicaly rewritten from scratch.


Hello, vegetous

I also get libpng bs:

phil@agro quake $ ./ezquake-gl.glx
libpng error: Invalid image width
Received signal 11, exiting...


-nolibpng didnt work either (I'm not sure if thats even the right parameter)


updating libpng (gentoo) to 1.2.7 didnt help



note: my fuhquake works fine with nolibpng:

phil@agro quake $ ./fuhquake-gl.glx -nolibpng
phil@agro quake $


note:
ezquake.x11 works (even without -nolibpng!), but i cant get it fullscreen, and i am used to GL, so I would really like to get GL to work....

disconnect, help!!!!!!!!!!!!111111111

get a new libpng

that should do the trick!

http://roz.bookieroz.com/temp/libpng.dll

download that one

sassa: he's using Linux

DarkPlaces is actually having this same problem (except the error is not causing a crash , the problem is that my code is using unsigned int where it should be using unsigned long to match libpng1.2 - it seems (from googling) that unsigned long is indeed the standard in pngconf.h on all platforms and Linux distros, so I think we can assume unsigned long...

I also came across discussion (and a cvs commit) of changing it to unsigned int in libpng1.4, so this problem will go away whever the (incompatible) libpng1.4 library comes out.

Here is the patch for those interested:
http://cvs.icculus.org/cvs/twilight/darkplaces/image_png.c?r1=1.10&r2=1.11

Is there any advantage in using a 64-bit ezQuake binary over a 32bit one?

Yes, with 64bit ezquake binary you wouldn't need to run it in emulated state(through wow64, converts 32bit to 64bit) on 64bit windows. I guess it's same thing with linux and everything which is natively 64bit.

In linux there are less system calls in the first place, and the system calls that there are are fairly cpu-neutral anyway.
Quake simply doesn't generate many system calls anyway, so its fairly negligable in windows too.

Using a 64bit binary, you get twice as many registers (on amd64 anyway), and your memcpys can run using half as many instructions. The additional registers mean that there is less storing variables on the stack (so less instructions - especially memory references), and the bigger sizes are particuarly useful to graphics/sound libraries. Compilers can generate worse code though if they feel they need to preserve more registers.
64bit pointers are useless except for databases (amd64 compatible cpus only support between 40 and 48bits of address space anyway. usually just 40. windows supports 48. I want a computer with that much ram).

The more practical advantage of a 64bit build is that you don't need to get the 32bit libraries that ezquake depends upon.

I also had the same problem with libpng with fte on 64bit linux. The library safely reports bad format and rejects gracefully. Note that this libpng bug shouldn't affect any win64 builds as long==int there.

In short: if you built your system 64bit, why would you use 32bit stuff? (well unless there's none available).

64bit app -> 64bit system -> perform operations

vs

23bit app -> 64bit system -> kernel 32bit app emulation -> different way of memory handling -> perform operations

So, 2 more steps, 2 more failure points, redundant stuff that could be easily avoided.

CONCLUSION: THANKS DISCONNECT FOR x86_64 IMPLEMENTATION! \o/

There is no file to download.

Is there any progress on a x86_64 build?
I think that most people these days has a 64bit system or atleast thinking about buying one

edit: what I really want is to at least play ezQ on my Ubuntu 64bit box

edit2: Spelling errors