Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 128370

Summary: tremulous-1.1.0.ebuild (New Package)
Product: Gentoo Linux Reporter: Paul Bredbury <brebs>
Component: [OLD] GamesAssignee: Gentoo Games <games>
Status: VERIFIED FIXED    
Severity: enhancement CC: ansla80, avuton, gent_bz, keletmaster, lefti, mathy, mikkel, radek, ruud, toto, tristan
Priority: High Keywords: EBUILD
Version: 2005.1   
Hardware: All   
OS: Linux   
URL: http://tremulous.net/
Whiteboard:
Package list:
Runtime testing required: ---
Attachments: tremulous-1.1.0.ebuild
tremulous-1.1.0.ebuild
tremulous-1.1.0.ebuild
tremulous-1.1.0.ebuild
tremulous-1.1.0.ebuild
tremulous-1.1.0.ebuild
tremulous-1.1.0.ebuild
tremulous-1.1.0.ebuild
tremulous-1.1.0.ebuild
tremulous-1.1.0.ebuild
tremulous-bin-1.1.0.ebuild
tremulous-1.1.0.ebuild
tremulous-1.1.0.ebuild
tremulous-1.1.0.ebuild

Description Paul Bredbury 2006-04-01 04:44:43 UTC
Hi, here is an ebuild for Tremulous, which is now standalone from Quake 3 as a FPS with aliens vs humans.

The executables only work if in the same base directory as the data, which confused me for a while :)
Comment 1 Paul Bredbury 2006-04-01 04:46:16 UTC
Created attachment 83609 [details]
tremulous-1.1.0.ebuild
Comment 2 Greg Coit 2006-04-01 13:53:32 UTC
worked great for me - no errors on the ebuild and the game runs fine!  Thanks!
Comment 3 Paul Archer 2006-04-03 02:58:26 UTC
This ebuild works great for amd64 with a few modifications.

For 1 openal is a required dependancy to compile.
and next in the src_install() function, the line

        newexe build/release-linux-x86/${PN}.x86 ${PN} \
must be replaced with
        newexe build/release-linux-amd64/${PN}.amd64 ${PN} \

I am not sure the proper way to do these modifications, but if someone could do this, feel free to add ~amd64 to the keywords
Comment 4 Paul Bredbury 2006-04-03 08:25:03 UTC
Created attachment 83815 [details]
tremulous-1.1.0.ebuild

I confirm that openal is required for compilation, so I've added it to the deps. I've added ~amd64, using the nifty ${ARCH} variable.

The ebuild now uses src_compile() based on the quake3 ebuild.
Comment 5 hubert farnsworth 2006-04-05 05:09:14 UTC
Works great for me too on x86.
Thanks!!
Comment 6 Jarrod Cary 2006-04-05 13:56:45 UTC
The ebuild works for me on amd64, but the preformance of the game sucks. I tryed the binary .run installer, and it works flawlessly, 90fps constant. Whereas the version from the ebuild would slowdown and stutter from 15-50 fps.
Comment 7 Paul Bredbury 2006-04-05 21:45:54 UTC
Created attachment 84050 [details]
tremulous-1.1.0.ebuild

Aha, further reading of the Makefile has revealed that openal and sdl are actually optional, so I've updated the ebuild.

In my tests, the performance has always been great.
Comment 8 Mr. Bones. (RETIRED) gentoo-dev 2006-04-05 21:58:51 UTC
why nomirror?
Comment 9 Paul Bredbury 2006-04-05 22:01:08 UTC
It's a 100mb file - would Gentoo mirror a game that large?
Comment 10 Mr. Bones. (RETIRED) gentoo-dev 2006-04-05 22:05:42 UTC
nomirror is for things we *can't* mirror for legal or other reasons.  It doesn't have anything to do with size.
Comment 11 Jarrod Cary 2006-04-06 01:31:56 UTC
(In reply to comment #7)
> Created an attachment (id=84050) [edit]
> tremulous-1.1.0.ebuild
> 
> Aha, further reading of the Makefile has revealed that openal and sdl are
> actually optional, so I've updated the ebuild.
> 
> In my tests, the performance has always been great.
> 
I tryed the new ebuild, it won't compile with openal in my USE flags, just gives me errors about 'src/client/qal.h' and 'src/client/snd_openal.c'

It also fails if I take out sdl from my USE flags on '/usr/include/linux/joystick.h', which leads me to beleave that this should have a joystick USE flag, but I don't really know much about that, just know that some of my other games have it because I use a joystick for some of em.

Again, this is on amd64, the .bin installer works flawlessly.
Comment 12 Paul Bredbury 2006-04-06 02:23:30 UTC
(In reply to comment #11)
> I tryed the new ebuild, it won't compile with openal in my USE flags

I added USE_OPENAL_DLOPEN=1 and USE_LOCAL_HEADERS=0, which work fine for me on x86. Although, *all* the combinations work fine for me :)

Looking at qal.h, I suspect openal on your PC is broken. It worked in comment #3 with openal on amd64.

Does the compiled ebuild work OK for you with sdl and -openal?
Comment 13 Jarrod Cary 2006-04-06 14:22:40 UTC
> Does the compiled ebuild work OK for you with sdl and -openal?
> 

Yes, it works OK for me. It runs at more than playable framerates, but It just bugs me that the framerate is slower than the binary version from the installer.

I tryed recompiling openal but it did nothing. But if I compile tremulous without openal it works.
Comment 14 Jarrod Cary 2006-04-06 20:52:44 UTC
Just thought I'd say this. I set com_maxfps to 1000 and in the ebuild version, it never went above 85 unless I was staring at a wall, in which case it might go up to slightly over 100fps.

I tryed the binary installer again, did the same thing, and my framerate never dropped below 250.

I can't figure out why it's acting so strangley. I tryed compiling with CFLAGS="-march=k8 -O0" and also with insane optimization flags, it's the same every time.

Is anyone else on amd64 having problems with low framerates? I'd like to know that I'm not alone and not being a huge idiot.
Comment 15 Mathy Vanvoorden 2006-04-12 11:59:44 UTC
WFM.

The OpenAL-issue can be solved by installing the latest (hardmasked) version of OpenAL in portage: 20051024. After that it builds just fine.
Comment 16 Paul Bredbury 2006-04-12 12:46:09 UTC
Created attachment 84523 [details]
tremulous-1.1.0.ebuild

Changed nomirror to primaryuri, and versioned the optional dependency on openal.
Comment 17 Tristan Heaven (RETIRED) gentoo-dev 2006-04-18 13:54:00 UTC
Created attachment 84920 [details]
tremulous-1.1.0.ebuild

Replaced the use of tar with unpack
Added OPTIMIZE= to clear out unwanted cflags
Comment 18 toto 2006-04-18 14:51:32 UTC
*** Bug 130404 has been marked as a duplicate of this bug. ***
Comment 19 Paul Bredbury 2006-04-24 09:53:42 UTC
Created attachment 85367 [details]
tremulous-1.1.0.ebuild

Added "custom-cflags" USE flag.

Removed versioning on openal dependency, due to the new openal-0.0.8 changing the versioning scheme. Replaced it with a check in pkg_setup().
Comment 20 Tristan Heaven (RETIRED) gentoo-dev 2006-04-26 05:10:01 UTC
Shouldn't that be "use openal && has_version", if it's optional?
Comment 21 Paul Bredbury 2006-04-26 08:30:50 UTC
Created attachment 85544 [details]
tremulous-1.1.0.ebuild

(In reply to comment #20)
> Shouldn't that be "use openal && has_version", if it's optional?

Yes, here it is.
Comment 22 GNUtoo 2006-06-16 20:18:56 UTC
when will it be in portage?
Comment 23 Kyle Hunter 2006-07-10 17:20:28 UTC
I can tell you why this is slow on x86_64.

When you run the game, it either chooses to JIT compile bytecode, or interpret it. There are no JIT compilers for x86_64. It uses interpretation which is buggy, and slow.

You have to download the x86-binary version, or compile it purely 32-bit (Not recommended).

I really hope someone could make an ebuild for the binary version, thanks.

Jarrod Carey, your not alone. I spent a couple of hours messing with it..
Comment 24 Kyle Hunter 2006-07-10 17:21:21 UTC
I can tell you why this is slow on x86_64.

When you run the game, it either chooses to JIT compile bytecode, or interpret it. There are no JIT compilers for x86_64. It uses interpretation which is buggy, and slow.

You have to download the x86-binary version, or compile it purely 32-bit (Not recommended).

I really hope someone could make an ebuild for the binary version, thanks.

Jarrod Carey, your not alone. I spent a couple of hours messing with it..(In reply to comment #14)
> Just thought I'd say this. I set com_maxfps to 1000 and in the ebuild version,
> it never went above 85 unless I was staring at a wall, in which case it might
> go up to slightly over 100fps.
> 
> I tryed the binary installer again, did the same thing, and my framerate never
> dropped below 250.
> 
> I can't figure out why it's acting so strangley. I tryed compiling with
> CFLAGS="-march=k8 -O0" and also with insane optimization flags, it's the same
> every time.
> 
> Is anyone else on amd64 having problems with low framerates? I'd like to know
> that I'm not alone and not being a huge idiot.
> 

Comment 25 Kyle Hunter 2006-07-10 17:29:18 UTC
Oh, and I forgot to note.. You have to have all vm_* variables (Variables that begin with vm) set to 2, for it to run correct, fast, etc.
Comment 26 Paul Bredbury 2006-07-10 21:42:49 UTC
(In reply to comment #24)
> I really hope someone could make an ebuild for the binary version, thanks.

That's the easiest ebuild to create, and was done in comment #1.
Comment 27 Kyle Hunter 2006-07-10 22:50:22 UTC
Comment #1 ebuild compiles the source for me...
Comment 28 Paul Bredbury 2006-07-10 23:32:18 UTC
(In reply to comment #27)
> Comment #1 ebuild compiles the source for me...

Oops, that's true - but it looks like you only need to change ${S} to point to one level up, and change the newins instructions to install the precompiled binaries.
Comment 29 Matthias Langer 2006-07-13 16:36:57 UTC
i've just tried tremulous-1.1.0  USE="openal opengl sdl vorbis -custom-cflags -dedicated" on x86 and it looked quite good !
Comment 30 Michael Boone 2006-07-15 14:56:47 UTC
I would also like to request a tremulous-bin-1.1.0.ebuild to be added to portage when it is for the amd64 users out there.
Comment 31 Kyle Hunter 2006-07-15 22:37:45 UTC
Actually, according to Icculus.org you can use GNU assembler to JIT compile the bytecode. The game is not detecting it but I'm working on it.

I hope we can use x86_64 compiled versions soon :)
Comment 32 Kyle Hunter 2006-07-15 23:05:10 UTC
I got the GNU Assembler to work with Tremulous, making it perfectly viable to compile it from source on x86_64. I will try to make my own ebuild for it, will submit it.

Thanks.
Comment 33 Kyle Hunter 2006-07-16 00:06:35 UTC
Created attachment 91854 [details]
tremulous-1.1.0.ebuild
Comment 34 Kyle Hunter 2006-07-16 02:57:04 UTC
PaulBredbury is fixing the ebuild, so if your on x86_64 it will get the binary.

Quake 3 doesn't like x86_64, and the performance is noticably lower on x86_64. It's not worth trying..
Comment 35 Paul Bredbury 2006-07-16 03:38:51 UTC
Created attachment 91876 [details]
tremulous-1.1.0.ebuild

This ebuild works on amd64 and x86. It only compiles for x86, otherwise it uses the pre-compiled x86 binaries, because that's the only way to get good performance on amd64. Thanks to Phenax for testing.
Comment 36 Michael Boone 2006-07-16 04:21:14 UTC
just tested latest ebuild on amd_64 machine, dunn if this is helpfull because it's a bin, but it worked perfectly. :)
Comment 37 Mr. Bones. (RETIRED) gentoo-dev 2006-07-24 08:32:10 UTC
*** Bug 141559 has been marked as a duplicate of this bug. ***
Comment 38 igch 2006-07-26 20:32:20 UTC
(In reply to comment #35)
> Created an attachment (id=91876) [edit]
> tremulous-1.1.0.ebuild
> 
> This ebuild works on amd64 and x86. It only compiles for x86, otherwise it uses
> the pre-compiled x86 binaries, because that's the only way to get good
> performance on amd64. Thanks to Phenax for testing.
> 

On x86 here.  I had to install OpenAL (20050504-r1) in order to compile successfully, otherwise it would fail complaining, "cannot find -lopenal"; the 2006-07-16 03:38 PST ebuild does not mention OpenAL at all, but I see that the 00:06 PST one just before it does.  USE flags were "sdl -dedicated".
Comment 39 Paul Bredbury 2006-07-27 09:23:55 UTC
Created attachment 92865 [details]
tremulous-1.1.0.ebuild

The "combined" ebuild was incomplete. Here's the build-from-source ebuild. A separate tremulous-ded ebuild is required for top amd64 performance, to keep the USE flags clean, based on the ebuild in comment #35.

This ebuild needs the sdl USE flag to prevent a joystick compilation conflict with vanilla-sources-2.6.16.26.
Comment 40 Paul Bredbury 2006-07-28 06:29:44 UTC
Created attachment 92923 [details]
tremulous-bin-1.1.0.ebuild

tremulous-bin, for amd64 performance.
Comment 41 Paul Bredbury 2006-08-11 09:52:29 UTC
Created attachment 94002 [details]
tremulous-1.1.0.ebuild

Removed debug/release directory name ambiguity.
Comment 42 Tristan Heaven (RETIRED) gentoo-dev 2006-08-11 10:00:22 UTC
OpenAL version isn't a problem now.
Comment 43 Paul Bredbury 2006-08-11 10:14:01 UTC
(In reply to comment #42)
> OpenAL version isn't a problem now.

That will be true in about 6 months, not now. There needs to be a *reasonable* "It's not our fault if your versions are hopelessly out of date" argument.

Comment 44 Chris Gianelloni (RETIRED) gentoo-dev 2006-08-11 13:23:21 UTC
Why do we have the custom-cflags USE flag and not just always permit custom CFLAGS?  Is the package known to break on certain CFLAGS combinations?
Comment 45 Paul Bredbury 2006-08-11 15:13:16 UTC
(In reply to comment #44)
> Why do we have the custom-cflags USE flag and not just always permit custom
> CFLAGS?

If someone has found better CFLAGS, then they belong in the *ebuild* so that we all can benefit.

> Is the package known to break on certain CFLAGS combinations?

Not AFAIK. I'm gonna sit back and trust the author's Makefile, containing: "-O3 -march=i586 -fomit-frame-pointer -ffast-math -falign-loops=2 -funroll-loops -falign-jumps=2 -falign-functions=2 -fstrength-reduce".
Comment 46 Bernd Buschinski 2006-08-16 07:56:27 UTC
tremulous-bin-1.1.0.ebuild
works great =)
please put it in portage
Comment 47 Tristan Heaven (RETIRED) gentoo-dev 2006-08-28 19:47:07 UTC
Created attachment 95338 [details]
tremulous-1.1.0.ebuild

Less cryptic ebuild.
Comment 48 Tristan Heaven (RETIRED) gentoo-dev 2006-08-29 12:49:15 UTC
Created attachment 95410 [details]
tremulous-1.1.0.ebuild

Blocker should be in RDEPEND.
Comment 49 Chris Gianelloni (RETIRED) gentoo-dev 2006-09-06 15:19:44 UTC
(finally) in CVS...
Comment 50 Paul Bredbury 2006-09-06 16:35:37 UTC
(In reply to comment #47)
> Less cryptic ebuild.

I don't get it - how is it *better* to throw away the custom-cflags USE flag and the Makefile's default optimizations (fast-math, etc.)? Who knows of better CFLAGS for this game than that?
Comment 51 Tristan Heaven (RETIRED) gentoo-dev 2006-09-06 19:59:20 UTC
That's what every other ebuild does.
Comment 52 gent_bz 2006-09-06 20:27:47 UTC
(In reply to comment #50)
> (In reply to comment #47)
> > Less cryptic ebuild.
> 
> I don't get it - how is it *better* to throw away the custom-cflags USE flag
> and the Makefile's default optimizations (fast-math, etc.)? Who knows of 
> better CFLAGS for this game than that?

(comment #45)
> -O3 -march=i586 -fomit-frame-pointer -ffast-math -falign-loops=2 
> -funroll-loops -falign-jumps=2 -falign-functions=2 -fstrength-reduce

What if you have an arch superior to i586?  Or how about that -fstrength-reduce is implied by -O3 and -funroll-loops.  

The hard-wired misuse of these flags does not instill me with confidence regarding the others. 

I'm happy being able to use my own choice of CFLAGS.  And you can choose to use what you would like to use.
Comment 53 Paul Bredbury 2006-09-06 23:24:19 UTC
Er, "because other ebuilds do it" is *not* an answer. I asked for a reason, for logic. *Why* do they override the CFLAGS in the Makefile with the user's less-optimized CFLAGS?

The default arch can be changed, that's not a problem - an example is the darkplaces ebuild in Portage, using sed on the Makefile.

This sure seems stupid to me. I'd prefer, as the default, to use the CFLAGS that the game developer used, especially fast-math, since it must be safe in this game, for it to be in the Makefile, even though it's unstable normally.

The custom-cflags USE flag allows anyone who disagrees with the Makefile's CFLAGS to use their own CFLAGS. So everyone's happy, surely?

Portage doesn't even *support* per-package CFLAGS right now, without nasty, unofficial hacks!
Comment 54 Chris Gianelloni (RETIRED) gentoo-dev 2006-09-07 12:06:48 UTC
It's really just because it is Gentoo policy to use the user's CFLAGS in all situations except for ones where the package is known to only work with a specific set.

Anyway, the ebuild is in portage, so this bug is CLOSED.