[macintologist]

I have the new g4 imac top configuration. I installed Quake 2 and downloaded the OSX patch. Gameplay is REALLY slugish compared to OS 9. What can I do to make it smooth like on OS 9 or is this bad code?

[seanyepez]

It's bad code. Nothing else could explain it.

[The Dude]

A quick look at VersionTracker's message board shows that many people have reported very good performance with this port.

Take a look for your self (you too yepez) http://www.versiontracker.com/morein...gs=&db=mac

This is either something going on with your OS X install that is causing this...or something with your Q2 install. May I ask, have you updated Q2 to the latest version before using the OS X port?

[Brad Oliver]

Originally posted by The Dude:
<STRONG>A quick look at VersionTracker's message board shows that many people have reported very good performance with this port.</STRONG>

I'm one of those who also has really bad performance on my DP800 w/GeForce 3. I looked at the code a while back and I think I understand why - it uses an event system that plays badly with OSX, and ends up getting "punished" by the OSX scheduler. The "fruitz" guys need to hook up the event loop to an NSTimer and have it control the frame timing rather than the "while" loop they're currently using.

Brad

[Sarc]

Originally posted by Brad Oliver:
<STRONG>

I'm one of those who also has really bad performance on my DP800 w/GeForce 3. I looked at the code a while back and I think I understand why - it uses an event system that plays badly with OSX, and ends up getting "punished" by the OSX scheduler. The "fruitz" guys need to hook up the event loop to an NSTimer and have it control the frame timing rather than the "while" loop they're currently using.

Brad</STRONG>

If not toooooo busy, can you explain him that in a short email or something ?

Thx
Sarc

[mikerally]

Guys, guys, guys.

Have a look at the read me file for once.

You need to edit one of the config files, and turn off one of the filter options, I can't remember which off hand, but I can come back and tell you.

All of a sudden it will work like magic again.

[seanyepez]

Nice. Most ports to OS X of antiquated games run terribly.

A small notice to all of you experiencing bad performance: Please read the "Performance - Important" file coming with Quake II. The bad performance you are experiencing is caused by the OpenGL multi-texture extension.

The MacOS 9 version doesn't use the multi-texture extension, altough it will set the config variable for multi-texturing to enabled. I decided to include the option to use the multi-texture extension with the MacOS X version, since one option more is better than one option less. However this has the drawback that you'll have to disable the multitexture extension by deleting or editing old config.cfg files.

Another thing to keep in mind is that the OpenGL drivers for MacOS X don't take full advantage of Altivec [because this caused Kernel Panics, NVidia and ATI had to remove it/decrease the amount of Altivec optimization] like the MacOS 9 drivers and tho aren't as fast...

Brad: I don't see how a NSTimer could improve performance. A NSTimer based event loop would be called from the same runloop as my while() loop and it should introduce a slightly increased amount of overhead.

Anyways, enough tech stuff, since this isn't a developer forum...

Regards,
awe

[Brad Oliver]

Originally posted by &lt;awe&gt;:
<STRONG>Brad: I don't see how a NSTimer could improve performance. A NSTimer based event loop would be called from the same runloop as my while() loop and it should introduce a slightly increased amount of overhead.</STRONG>

It is in fact the exact opposite - try it before dismissing it.

Your current while() loop hogs the processor and gets slapped down by the OS because the game doesn't have an efficient way to yield. You need to eliminate that entire routine and hook a high-frequency NSTimer up directly to the frame processing. You will see a roughly 10-15% speed increase since the OS will schedule each frame more frequently without triggering the punisher, since it sees that you're attempting to yield frequently. Since it sees you yielding, and that it knows when you want time back (because of the NSTimer), the scheduler marks you as "playing nice" and obliges moreso than it does without that.

Brad

Okay, I did a comparison with a NSTimer based model [try all variants before insisting on your own ].

I modified my current event loop and hooked the event loop up to a high-frequency NSTimer. The result was as I expected earlier: The performance of the game dropped on average to about 95%. Herewith I can not confirm that using a NSTimer does improve game performance.

Anyways, the game performs really good as long as the multi-texture extension is disabled. Maybe I'll remove support for the multi-texture extension with the next version because some users don't seem to be able to read a simple ReadMe file or a file called "Performance - Important".

awe

[Brad Oliver]

Originally posted by &lt;awe&gt;:
<STRONG>I modified my current event loop and hooked the event loop up to a high-frequency NSTimer.</STRONG>

What event loop are you referring to? I was speaking specifically of hooking Qcommon_Frame() up to the timer - nothing more or less.

Brad

Originally posted by Brad Oliver:
<STRONG>

What event loop are you referring to? I was speaking specifically of hooking Qcommon_Frame() up to the timer - nothing more or less.

Brad</STRONG>

Brad "Carbon Programmer" Oliver giving Cocoa lessons. I've seen it all.

well, here we go again...let's play a little game called 'think before you post, guy'. i.e PLEASE TRY NOT TO PISS OFF YET ANOTHER PROGRAMMER.

you said you knew that you made an ass of yourself quite often on these boards...well, an ounce of prevention is worth a pound of cure.

thanks for listening!

[Brad Oliver]

Originally posted by &lt;Guy Incognito&gt;:
<STRONG>Brad "Carbon Programmer" Oliver giving Cocoa lessons. I've seen it all.</STRONG>

If you believe Apple hype, Cocoa only takes a day or three to learn...

Anyway, as I've recently discovered firsthand, for games a lot of the core routines are the same. In fact, if you debug a Cocoa app in ProjectBuilder, you'll see scary things in the stack frame, like calls to Carbon event routines in the runtime framework. Since Apple hasn't included that code as part of Darwin, it's hard to tell exactly what's in the Cocoa runtime, but it seems that a lot of the event and window handling is based on shared code between the two, which makes sense. One thing which is fundamental to all OSX apps is the need to not poll the system, and instead wait for it to send you events in order to play along well.

Anyhoo, don't freak out on me here Guy, but the Civ3 Editor (which I'm working on right now) is a Cocoa app. And the Apple hype is mostly right - it doesn't take too long to get up to speed in Cocoa. The only slowdown I've had is learning the godawful syntax (and poor C++ integration) of Objective-C.

Brad

First: Please keep this thread clean and stop those comments without sense. Thanks.

Brad: This is how my timer function looked [reconstructed]:

- (void) timedFrame: (NSTimer *) theTimer
{
int myTime, myNewTime;

// get the new delta T and skip if the delta is smaller than 1ms:
myNewTime = Sys_Milliseconds ();
myTime = myNewTime - gSysOldTime;
if (myTime &lt; 1)
return;
gSysOldTime = myNewTime;

// do one frame
Qcommon_Frame (myTime);
}

I used a timer intervall smaller than one millsecond [if I remember right: 1000000.0f Hz], to get some kind of infinite small timer intervall.

awe