Can you 64-bit Build of SVN 755 With GUID, SMP Support, Without SDL?

[silverbak]

Hi,

I've got a brand new installation of Debian x86_64-bit and I'm seeing no trem action.  I normally use my old qkey file and I used to download the 32-bit TJW port for the GUID fun.  Unfortunately TJW doesn't offer a 64-bit build so I'm left with little option but to build it myself, however I have been VERY unsuccessful at this.  It looks like a GCC 4.3 incompatibility and I don't have the prerequisite skills to fix this.

So I throw down the gauntlet!  I challenge thee to build a 64-bit version of SVN 755 with GUID and SMP support, without SDL support.

The reason we don't include SDL is that I believe that SDL isn't SMP enabled (in this context) so lets just compile without it.

The following hints/tools are available to you:
SVN 755 Checkout command for your console:

Code: [Select]

svn co -r 755 svn://svn.icculus.org/tremulous/trunk Tremulous
The SMP Patch ---> https://bugzilla.icculus.org/attachment.cgi?id=1127

TJW's GUID Patch --> http://tremulous.tjw.org/backport/tremulous-svn755.patch

There's more than one way to skin a cat but you will probably want to use this make line:

Code: [Select]

make USE_SDL=0 BUILD_CLIENT=1 BUILD_CLIENT_SMP=1
You can enabled smp in-game (may need a restart though) with your freshly compiled piece of genius by:

Code: [Select]

r_smp=1
I'm really hoping someone could be kind enough to do this as I'm pretty sure that plenty of people would benefit from this!

[Supertanker]

Better batten down your hatches, silverbak; you may soon be the target of a lot of random, ignorant flames.

If I recall correctly, enabling client SMP has almost no effect in performance besides in Mac OSX systems. Could be wrong, though.

I'd personally be willing to do it for you, but I'm on an I386 system. I did manage to compile an SMP client with ease (r1112), but r_smp does not work on my system, which does have a dual-core processor. Go figure.

[kevlarman]

compiling tremulous without sdl is impossible (on non-windows systems, in svn windows requires sdl as well), smp support currently doesn't exist in tremulous (with the exception of a hack on mac os x), and svn 755 has very poor 64 bit performance compared to the 32 bit client. lakitu7's client is built from more recent code that should run fine on x86_64, but it has a few differences (that all clients built from recent svn have) compared to tjw's client.

[Bissig]

Just install the 32bit compat librarys.

[fingered banana]

Just use SDL, SDL is the future

[silverbak]

Hi Guys!

Thank you very much for your feedback, I'm always willing to learn.

I have a 1.8ghz Core 2 Duo and an 8800GT, so SMP performance isn't something I worry about with tremulous as it is pretty much maxed out already!  I just figured that if someone were to recompile it that it would be better off with SMP than not.

BTW I love SDL and have done some elementary C++ programming with OpenGL and think it is a fine system.

So I'm still in need of a 64-bit client with GUID support so I'll check Lakitu7's build (thank you for the link) and fingers crossed it will run ok one my system

Thank you for all your assistance peeps, I'll be glad when 1.2 finally arrives and then I won't have to mess around with this nonsense and will be able to install a stock version from the Debian repos.

--
Silverbak

[silverbak]

Dammit, Lakitu7's build give me the following error:
/usr/lib/tremulous/tremulous: error while loading shared libraries: libopenal.so.0: cannot open shared object file: No such file or directory

This is despite the openal package being installed and the files exist!

I've even tried copying the libopenal* files to the /usr/lib/tremulous directory and the /usr/local/lib directory with not success.

Any suggestions as to why this error is being felt?

[gimhael]

Do you have libopenal.so.1 ? Then you have newer version of OpenAL installed (Debian unstable ?).

[Odin]

You can make a symlink of /usr/lib/libopenal.so.1 to /usr/lib/libopenal.so.0...

[gimhael]

or just apt-get install libopenal0a parallel to libopenal1

[silverbak]

You can make a symlink of /usr/lib/libopenal.so.1 to /usr/lib/libopenal.so.0...

This rapidly solved my problem, thank you

[silverbak]

Ok tremulous works, in that I can actually play it.

It loads all my old settings from my old configuration file and it runs at 1280x1024 etc.

There's just one problem, the graphics look like they are REALLY low resolution.  I even tried moving my cfg file out the way and letting it regenerate in case that was the problem but the issue remains in either case.

Any insight as to why this occurs with this build?  Incidentally, if I use the Debian executable the graphics are just fine.

I've got a feeling I won't be playing trem until verision 1.2 at this rate as it's just becoming an outright hassle.

[kevlarman]

Ok tremulous works, in that I can actually play it.

It loads all my old settings from my old configuration file and it runs at 1280x1024 etc.

There's just one problem, the graphics look like they are REALLY low resolution.  I even tried moving my cfg file out the way and letting it regenerate in case that was the problem but the issue remains in either case.

Any insight as to why this occurs with this build?  Incidentally, if I use the Debian executable the graphics are just fine.

I've got a feeling I won't be playing trem until verision 1.2 at this rate as it's just becoming an outright hassle.

r_width 1280; r_height 1024
the configuration for resolution changed in svn.

[silverbak]

Sweet, it works, yippp1111eeeeee!!!! :DD:D:D:D