Quake3World

One thing I've noticed since I've been messing with the icculus.org Quake3 code is that somewhere between build 416 and 456 performance took a huge nose dive. It may be when they disabled the PPC JIT compiler. I have a dual 2.5 G5 and I ran benchmarks with the following settings:

Maxed settings
1024x768
r_smp 0 (the binary I used only supports single proc mode)
demo four
unmodified makefiles. I just ran make.

Here are the results of comparing the two builds mentioned above:

416 275 fps
456 160 fps

That's a pretty big drop in performance for the PPC version.

are you "exterm" in another forum a2daj2?

a2daj2 wrote:One thing I've noticed since I've been messing with the icculus.org Quake3 code is that somewhere between build 416 and 456 performance took a huge nose dive. It may be when they disabled the PPC JIT compiler. I have a dual 2.5 G5 and I ran benchmarks with the following settings:

Maxed settings
1024x768
r_smp 0 (the binary I used only supports single proc mode)
demo four
unmodified makefiles. I just ran make.

Here are the results of comparing the two builds mentioned above:

416 275 fps
456 160 fps

That's a pretty big drop in performance for the PPC version.

Yeah, that's dramatic to say the least. I noticed something commented out in the makefile regarding the quake vm thing.

I'll try the smp version when I get a chance but I'm snowed under at work as I have to make a software release on the 20th and I've had an Apple evangelist over this week which didn't help my schedule.

riddla wrote:id & evenbalance should be notified of your efforts Mike, this is quality

It's just a case of compiling the sources on a PowerPC Mac, copying the results over to an Intel Mac, compiling there and running "lipo" on the two binaries to make a Universal Binary.

The SDL framework has a XCode project so you just need to turn on "i386" in the target to get XCode to do all the work for you. Build the .a and the framework. The .a is used by the q3 makefile and the framework just needs to be put in the application wrapper (Contents/Frameworks).

OpenAL ships on the Mac so I just linked with that. Had to turn audio settings to low to avoid an OpenAL crash.

S@M wrote:are you "exterm" in another forum a2daj2?

Nope. Last time I checked I usually go by a2daj. But I'm waiting for that account to be reactivated on these forums.

NCG_Mike wrote: Yeah, that's dramatic to say the least. I noticed something commented out in the makefile regarding the quake vm thing.

I'll try the smp version when I get a chance but I'm snowed under at work as I have to make a software release on the 20th and I've had an Apple evangelist over this week which didn't help my schedule.

When they finally reimplemented SMP support for Macs after I brought it up (they originally had no plans on supporting SMP for any platform since most ddn't have Macs and didn't know it was the only platform to see performance increases with it enabled) SMP performance wasn't as good as the Mac specific code. It was about 10-15% slower. Not enough to make a big deal about it. After the performance drop, the SMP build was about as fast as the old single proc performance. Apparently, the PPC QVM interpreter eats up a significant amount of CPU time compared to the x86 version. So disabling the JIT compiler really hurts performance.

You brought it up and they implemented it? Can you be persuasive to them to fix the doppler sound bug?

a2daj2 wrote:

NCG_Mike wrote: Yeah, that's dramatic to say the least. I noticed something commented out in the makefile regarding the quake vm thing.

I'll try the smp version when I get a chance but I'm snowed under at work as I have to make a software release on the 20th and I've had an Apple evangelist over this week which didn't help my schedule.

When they finally reimplemented SMP support for Macs after I brought it up (they originally had no plans on supporting SMP for any platform since most ddn't have Macs and didn't know it was the only platform to see performance increases with it enabled) SMP performance wasn't as good as the Mac specific code. It was about 10-15% slower. Not enough to make a big deal about it. After the performance drop, the SMP build was about as fast as the old single proc performance. Apparently, the PPC QVM interpreter eats up a significant amount of CPU time compared to the x86 version. So disabling the JIT compiler really hurts performance.

It'd be interesting to see how the Intel iMac copes with the JIT as it'd follow the i386 source path...

NCG_Mike wrote:We've got an iMac at work and it's much quicker than my dual 2Ghz G5.

If you compiled Q3 and turned on smp, it'd fly.

Do you mean an Intel Imac?

NCG_Mike wrote: Note the Intel based system is quite a bit faster!

Are you using the specifically compiled for G4/G5 Quake 3 patch for Macs?

http://3ddownloads.com/Action/Quake%203 ... D16757C29A

I get the following:

Dual Power Mac G5 2ghz with ATI x800 XT and 4 gigs RAM.

Quake 3, r_smp = 0, timedemo 1, demo = 224 fps

Quake 3, r_smp = 1, timedemo 1, demo = 357 fps

NCG_Mike wrote:I'm pretty sure it'll work on-line, though obviously not on Punk Buster servers. There's also a dedicated server that ships with the sources.

If you contact Tony Ray at EvenBalance I'll bet he'd help you get it working with PB.

damn thats a good idea F1

Iluvmymac wrote:

NCG_Mike wrote: Note the Intel based system is quite a bit faster!

Are you using the specifically compiled for G4/G5 Quake 3 patch for Macs?

http://3ddownloads.com/Action/Quake%203 ... D16757C29A

I get the following:

Dual Power Mac G5 2ghz with ATI x800 XT and 4 gigs RAM.

Quake 3, r_smp = 0, timedemo 1, demo = 224 fps

Quake 3, r_smp = 1, timedemo 1, demo = 357 fps

Look at the screenshots and note the part were it says ioQ3 1.33 macosx-ppc. ioQ3 means icculus.org Quake 3.

I asked Tony Ray to check out this thread.

Can you give him a copy of your compiled binary if they are able to make PB accept it?

Thank you. :icon31:

Iluvmymac wrote:

NCG_Mike wrote:We've got an iMac at work and it's much quicker than my dual 2Ghz G5.

If you compiled Q3 and turned on smp, it'd fly.

Do you mean an Intel Imac?

Yes, it's an Intel iMac 20". Very nice it is too, apart from the mouse of course ;-)

Iluvmymac wrote:I asked Tony Ray to check out this thread.

Can you give him a copy of your compiled binary if they are able to make PB accept it?

Thank you. :icon31:

It would be awesome if Icculus was accepted in punkbuster for windows as well. I doubt the pb guys will do it, but Icculus is made by a bunch of very good and trusted coders in the q3 community. If you where to accept one exe, I think this one would be it.

However, it's pretty hard to accept a uniform exe when the project is open source, like Icculus is. You would only be able to accept the builds made by the Icculus team, since anything created by others could potentially contain cheat mechanisms.

It seems id would have to officially approve a compile and request that PB be included in it.

Who did the original Mac port for Quake 3?

id Software made the OS 9 version of Q3, and the Omni group ported it to OS X. id Software then took up the task and perfected the OS X port to what we have now. They've since released the source code and are no longer supporting Q3, so basically its up to the community now.

There's a universal binary out for Q3 on MacUpdate: http://www.macupdate.com/info.php/id/5991

Here's the developer's site: http://www.sqonk.com.au/quake3.html

Very nice find. Thank you. :icon31:

Does that really work on punkbuster servers canis?

I was just informed by an official source that those binaries should not be trusted.

Tony? :> If they mean they are not made by id, well yes they are not. Those are compiled with the source, by a 3rd party. Usually, if the people behind it are decent (if these guys are) then there shouldn't be a problem with it containing hacks or anything... are the pb-guys just being overly-conscious on this one?