Possibility of a 64-bit binary?

Linux support forum for Eschalon: Book I
Post Reply
Deiz
Pledge
Posts: 1
Joined: January 20th, 2009, 11:18 am

Possibility of a 64-bit binary?

Post by Deiz » January 20th, 2009, 11:22 am

I have the same issue as mentioned here. Same distribution, as well.

I have this issue with several 32-bit games, and it would seem I need to do some tinkering to get 32-bit applications to work well on my system.

In any case, I would love a 64-bit binary. Is it possible to compile Book I for x86_64, and if so, is there sufficient demand to release a 64-bit binary?

Edit: Figured it out. Needed lib32-nvidia-utils instead of lib32-libgl

Janusz11
Apprentice
Posts: 31
Joined: November 30th, 2007, 5:12 pm

Re: Possibility of a 64-bit binary?

Post by Janusz11 » January 25th, 2009, 5:57 am

Deiz wrote: Edit: Figured it out. Needed lib32-nvidia-utils instead of lib32-libgl
Yep, I can confirm that this did the trick. The game is now working on Arch Linux 64bit.

:-)

User avatar
BasiliskWrangler
Site Admin
Posts: 3805
Joined: July 6th, 2006, 10:31 am
Location: The Grid
Contact:

Re: Possibility of a 64-bit binary?

Post by BasiliskWrangler » January 25th, 2009, 10:26 am

A 64-bit binary is not possible until/unless the developer of our programming language makes a 64-bit compiler. Absolutely nothing has been said about this, so I highly doubt we will see anything anytime soon.
See my ramblings and keep up with the latest news on Twitter & Facebook.

The Noid
Fellowcraft Apprentice
Posts: 53
Joined: September 11th, 2008, 6:54 am

Re: Possibility of a 64-bit binary?

Post by The Noid » January 26th, 2009, 10:43 am

Besides that, I doubt Eschalon will ever need more then 4Gb of memory, so there's not much advantage to having a 64 bit version... :)

What would help is a general list of packages to check for when you run into problems on a 64 bit system.

User avatar
Getharn
Marshall
Posts: 108
Joined: October 8th, 2008, 8:37 am
Location: Cambridge, UK
Contact:

Re: Possibility of a 64-bit binary?

Post by Getharn » January 26th, 2009, 4:59 pm

The Noid wrote:Besides that, I doubt Eschalon will ever need more then 4Gb of memory, so there's not much advantage to having a 64 bit version...
The issue is more not having the hassle of having to set up a duplicate environment on a 64-bit system to allow all those 32-bit applications to run.

The move to 64-bit is like the move to multi-threading - it'll be slow and painful, but it'll happen eventually.

Janusz11
Apprentice
Posts: 31
Joined: November 30th, 2007, 5:12 pm

Re: Possibility of a 64-bit binary?

Post by Janusz11 » January 27th, 2009, 4:01 pm

Getharn wrote:
The Noid wrote:Besides that, I doubt Eschalon will ever need more then 4Gb of memory, so there's not much advantage to having a 64 bit version...
The issue is more not having the hassle of having to set up a duplicate environment on a 64-bit system to allow all those 32-bit applications to run.

The move to 64-bit is like the move to multi-threading - it'll be slow and painful, but it'll happen eventually.
Absolutely! The hardware is there- why note make use of it?

But as BasiliskWrangler has pointed out already, this has something to do with the Blitz software and not with the game. And as long as the guys from Blitz Research Ltd stick to the 32bit structure, there is nothing Basilisk can do.

User avatar
Getharn
Marshall
Posts: 108
Joined: October 8th, 2008, 8:37 am
Location: Cambridge, UK
Contact:

Re: Possibility of a 64-bit binary?

Post by Getharn » January 27th, 2009, 4:52 pm

Janusz11 wrote:Absolutely! The hardware is there- why note make use of it?
Well, it's not quite as simple as that, sadly... What in this life ever is? ;-)

To play devil's advocate for a moment, it's a matter of time and effort. You'll notice that the open source projects have tended to embrace 64-bit far more readily than most commercial software houses, and that's mainly because it requires effort to change.

If you're really lucky, you can just go and recompile your software for 64-bit and it'll Just Work(tm). This still involves the effort of acquiring 64-bit hardware and a suitable build environment, then compiling, then passing through another QA phase to pick up any subtle bugs that have been introduced either by the new execution environment or simply the new build environment. Then you've got all the hassle of distributing the resultant software to people.

If you're less lucky, you'll have to go and change some bits of code which were implicitly relying on 32-bit values. Arguably, well-written code doesn't do this, but it's very hard to insulate yourself from it entirely in languages like C/C++. It's somewhat akin to writing network code which is IPv6 compliant - in a perfect world it's a simple transition, but there's bound to be some function somewhere that assumes 32-bit IP addresses.

I'm relatively familiar with these problems, having had to convert some old (and fairly poorly written) C and C++ code to run on both a 64-bit platform and with IPv6 support. It wasn't all that fun. More recently, however, everything I've written has been exclusively for use on 64-bit platforms. Lucky, really, as recently we needed to fit 32GB RAM to a machine to cope with some... Ah... Sub-optimal code that I inherited. Fortunately I've just finished some extensive changes which take its memory usage down by a factor of 10... :-)

So, even if no explicit code changes are required, there's still work involved. For older bits of software, companies are far happier just leaving it along and making money out of it - bringing out a 64-bit version will, in general, not bring in any extra revenue, so why pay the cost?

However, as 64-bit platforms slowly permeate, and as people increasingly start to stick more than 4GB of RAM in their machines, I think that 64-bit will gradually start to become a standard enough platform that software vendors will have to support it.

Also, they might start to view 64-bit support as a great way to kick people to pay for upgrading to the next version.
Janusz11 wrote:But as BasiliskWrangler has pointed out already, this has something to do with the Blitz software and not with the game. And as long as the guys from Blitz Research Ltd stick to the 32bit structure, there is nothing Basilisk can do.
Oh, certainly - there isn't a lot that users of languages can do until their compiler / interpreter has had 64-bit support added. Unfortunately, there probably isn't much incentive for the authors of languages like BlitzMax to do it until 64-bit Windows becomes more mainstream.

C'est la vie.

Janusz11
Apprentice
Posts: 31
Joined: November 30th, 2007, 5:12 pm

Re: Possibility of a 64-bit binary?

Post by Janusz11 » February 1st, 2009, 6:24 am

Getharn wrote: Well, it's not quite as simple as that, sadly... What in this life ever is? ;-)
I didn't mean to say that it is easy to make all software available for 64bit systems as well, or that you can switch "just like that". But seeing that a lot of the hardware available nowadays in the consumer market is making use of the 64bit technology, I think the software developers should make use of it. Its a process that takes time for sure. But I think its way worth going.

Janusz11
Apprentice
Posts: 31
Joined: November 30th, 2007, 5:12 pm

Re: Possibility of a 64-bit binary?

Post by Janusz11 » February 14th, 2009, 9:39 am

Sorry to bring this topic up again. But what I was somehow missing when I tried to get Eschalon: Book I running on my 64-bit system was a notice which 32-bit libraries exactly are needed to make it work. Since I was in a similar situation for another program I tinkered around a little and though I might as well share my experience for potential future gamers who might face the same situation.

I'm using Arch Linux 64-bit (and a nVidia graphics card) and the following libraries are needed to make Eschalon: Book I work on this system:
* lib32-glibc
* lib32-mesa
* lib32-nvidia-utils
* lib32-libxxf86vm

So all that is needed was the following command:
pacman -S lib32-glibc lib32-mesa lib32-nvidia-utils lib32-libxxf86vm

Hope that helps.

Post Reply

Who is online

Users browsing this forum: No registered users and 3 guests