Welcome to the MacNN Forums.

SirCastor · Jul 6, 2002, 04:12 AM

Hey guys,

Based on a post I read on another forum, I decided to give WC III a shot in 9 because it was getting difficult in X to move around or just about do anything.

So I boot into 9, and Everything is great! Well, it's not GREAT, but it's much better, and far more playable.

Here's my setup: G4 400(sawtooth. 384mb RAM, Radeon 8500 (64mb)

Any thought? Is Warcraft running better in 9 for you?

Deicide · Jul 6, 2002, 11:55 PM

It is the same for me with my 800mhz iMac. No matter what video settings I try under MacOS X it is choppy and gets really bad when there is a battle.

PipelineStall · Jul 7, 2002, 12:56 AM

I have a TiBook 667 (the first combo drive ones, with the 16 MB Radeon Mobility) with 1 gig of RAM.

Under Mac OS X, it's slow at every resolution (even 640 x 480). It's not terrible, but I'm used to Warcraft II and Starcraft type speeds, so it is annoying.

With Mac OS 9 however, it's great. I can run it at 1152 x 768 and it's much smoother than 640 x 480 on Mac OS X.

Perhaps Jaguar will improve things somewhat.

voice- · Jul 7, 2002, 07:27 AM

Works great in OS X for me (733Mhz Quicksilver, GeForce 2 MX, 768Mb RAM), I haven't even seen a reason to boot into OS 9 and try it out...

meducus · Jul 7, 2002, 04:52 PM

Well this wierd.....after reading this post I load up into OS 9 an try WCIII.

At first I think oh my god they're right - it seemed to run as well in OS 9 at millions of colours as it did in OS X at thousands.

So then I tried it in OS 9 at thousands of colours and it looked way crappier than it did in OS X at thousands. I know this seems wierd but when is OS9 at thousands the picture gets all grainy - but when in thousands of colours in OSX it looks as good as it does at millions of colours in OS 9. (all this tried at 768x1024). Can anyone explain this.

Considering the above I have now dicided that it runs just as well in OSX as long as in thousands of colours (which looks the same as millions in OS9 ?!).

The setup I find best is 764x1024, everything on low but textures to medium.

(ibook 700, 12.1, 384Mb)

Deicide · Jul 7, 2002, 05:21 PM

I also play WC3 on my 500Mhz Celeron PC with an original Geforce sdr32MB, Winxp pro, 512Mb ram. It plays smooth at 1024*768 32bit. On my iMac under MacOS X I can't get it to play as smooth. The game has a slight sluggish feel to it. There are little pauses in the water texture animations like the game is slightly out of sync. The curser gets real jumpy when moving around in a battle. It makes issuing commands very difficult. Under MacOS 9 it is as smooth as my PC with only some quick pauses like when the cd spins up.

Carl Norum · Jul 8, 2002, 12:00 PM

I noticed an immediate visible difference when I first booted my iMac 800 into OS 9 to check it out. I run the game at 1024x768x32 (native resolution is a MUST for LCD users) with all options at high. I would estimate that I get about 25 fps in OS 9 and 15 fps in OS 10... much much better, and definitely noticeable.

::maroma:: · Jul 8, 2002, 02:16 PM

Agreed, OS 9 play is much much better than OS X play. This is both sad and good. Sad because I have to boot into 9 to play at any sort of decent speeds. And good becuase at least we can get it to play at decent speeds. Here's hoping that 10.2 helps us out!

Big Mac · Jul 8, 2002, 11:04 PM

Has anyone tried a really high level of renice on WIII?

vvedge · Jul 9, 2002, 01:18 AM

sadly, this'll be the first reason in a while to start booting into OS9... the people at Blizzard and Apple had better get cracking...

voice- · Jul 9, 2002, 09:16 AM

Am I the only one who not only thought it was acceptable in OS X but even thought of it better there than in OS 9? No kidding, I had it playign beautifully in OS X, OS 9 wasn't all that...

mitchell_pgh · Jul 9, 2002, 10:21 AM

I have a 733 with ATI 7500... At first things were fine, but as I advanced to more intensive levels, things slowed down... BUT playing via Battle.net works much better under X... I don't get it...

I pray for 10.2 (ugh, I'm going to be VERY sad if it isn't at least up to OS 9 speed...

CIA · Jul 9, 2002, 01:17 PM

I don't know the underpinnings of X all that well, but what are the possible reasons for the X slowdown over 9?

xyber233 · Jul 9, 2002, 01:22 PM

Hopefully 10.2 will solve all our problems

.

SirCastor · Jul 9, 2002, 01:52 PM

Well, my guess is that OS X is far more robust than 9, and consequently is doing quite a bit more at a time than 9 is.. For instance, when you've got 9 running, basically all it's doing is running the game. There might be a background process or 2 from the finder, but that's it.

In X however, jump into the terminal, and type 'top' There's a good couple dozen things going on ALL THE TIME... I haven't yet experimented with turning off Apache and what not...

Any other ideas?

-A

xyber233 · Jul 9, 2002, 04:37 PM

Kneissl says that 6c85 shows a dramatic boost in WC3 performance. This is great news

!

<a href="http://forums.macnn.com/cgi-bin/ultimatebb.cgi?ubb=get_topic;f=30;t=002103" target="_blank">http://forums.macnn.com/cgi-bin/ultimatebb.cgi?ubb=get_topic;f=30;t=002103</a>

poulh · Jul 10, 2002, 02:58 PM

I've heard the "drawing" code in osx isn't up to par yet (with os9) and will need the help of the graphics card to get there (enter the jaguar). so i would say we have apple to blame for the slowness, not blizzard.

this is the same reason why that news.com article came out a while ago that reported that windows users thought web browsing was slower on macs than pc's. its not the mac hardware or the browser, its the drawing the picture to the screen.

i don't know if this is also the reason why the mouse movements seem delaysed.

meducus · Jul 10, 2002, 09:03 PM

Anyone else tried comparing thousands of colours in OS 9 versus thousands in OS X. Thousands in OS X looks as good as millions in OS 9.......how is this possible?

pysan · Jul 11, 2002, 10:33 PM

Well, everything has been working very smoothly for me, 867 Quicksilver with 1.5gig ram G force 2 32mb. In very heavy battles it will get a little jumpy, but even then not too bad. My roommate's on 1.8ghz pc's or higher with 32mb or 64mb vid cards have more problems than I do, so I think it's doing well. I've run it all in 10.1.5, without even the thought of trying in 9, but if 10.2 makes it even better, bring it on. Oh, and I have all the textures and eveything turned to max, millions of colors, and 1280x1024.

Jansar · Jul 12, 2002, 02:35 AM

I have an old Cube, so I guess I won't even try it in X for that matter...

Graymalkin · Jul 14, 2002, 07:39 PM

The reason for the performance change is WC3 is a Carbon app. OpenGL under OSX is not exported by the Carbon libraries which can talk only to QuickDraw so WC3 has to talk to OpenGL through QuickDraw which is considerably less efficient than talking directly to it. It is also a PEF binary file instead of a Mach-O binary file which needs to have runtime translation performed on it in order to run under X. When run in OS9 WC3 is running as a native app so it runs much smoother by having direct access to OpenGL and no runtime translation. There are supposed to be updates to Carbon coming in Jaguar that export OpenGL directly to Carbon which ought to make games like Warcraft run MUCH faster under X. I believe the Diablo 2 Carbon patch has the same problem unless you're using software rendering. Hopefully 10.2 will have this problem solved so more publishers release Carbon patches for their Classic games.

Brad Oliver · Jul 14, 2002, 09:58 PM

<blockquote>quote:<hr />Originally posted by Graymalkin:
OpenGL under OSX is not exported by the Carbon libraries which can talk only to QuickDraw so WC3 has to talk to OpenGL through QuickDraw which is considerably less efficient than talking directly to it. It is also a PEF binary file instead of a Mach-O binary file which needs to have runtime translation performed on it in order to run under X.<hr /></blockquote>You're off on both counts there - there are no issues with OpenGL talking to Carbon, and PEF doesn't have any "runtime translation" once launched. In fact, if you look at PEF code generated for long branches vs. MachO, you'll see that PEF has a much more concise runtime model.

Brad

Graymalkin · Jul 14, 2002, 11:33 PM

<blockquote>quote:<hr />Originally posted by Brad Oliver:
 <blockquote>quote:<hr />Originally posted by Graymalkin:
OpenGL under OSX is not exported by the Carbon libraries which can talk only to QuickDraw so WC3 has to talk to OpenGL through QuickDraw which is considerably less efficient than talking directly to it. It is also a PEF binary file instead of a Mach-O binary file which needs to have runtime translation performed on it in order to run under X.<hr /></blockquote>You're off on both counts there - there are no issues with OpenGL talking to Carbon, and PEF doesn't have any "runtime translation" once launched. In fact, if you look at PEF code generated for long branches vs. MachO, you'll see that PEF has a much more concise runtime model.

Brad<hr /></blockquote>Would you kindly read the Carbon developer docs. PEF binaries are treated much differently at runtime than Mach-O files in X at runtime. The PEF binaries are run inside a Mach-O process which translates fragment issues into Mach-O compatible segment issues. There's many docs pertaining to the use of Mach-O binaries over PEF binaries if you don't need to worry about Classic support. It is also a well known issue that CarbonLib does not directly export OpenGL to Carbon apps and they have to go through QuickDraw in order to talk to it. There's a lot of commotion about Jaguar because it fixes this problem in Carbon.

a2daj · Jul 15, 2002, 12:26 AM

<blockquote>quote:<hr />Originally posted by Graymalkin:
 <blockquote>quote:<hr />Originally posted by Brad Oliver:
 <blockquote>quote:<hr />Originally posted by Graymalkin:
OpenGL under OSX is not exported by the Carbon libraries which can talk only to QuickDraw so WC3 has to talk to OpenGL through QuickDraw which is considerably less efficient than talking directly to it. It is also a PEF binary file instead of a Mach-O binary file which needs to have runtime translation performed on it in order to run under X.<hr /></blockquote>You're off on both counts there - there are no issues with OpenGL talking to Carbon, and PEF doesn't have any "runtime translation" once launched. In fact, if you look at PEF code generated for long branches vs. MachO, you'll see that PEF has a much more concise runtime model.

Brad<hr /></blockquote>Would you kindly read the Carbon developer docs. PEF binaries are treated much differently at runtime than Mach-O files in X at runtime. The PEF binaries are run inside a Mach-O process which translates fragment issues into Mach-O compatible segment issues. There's many docs pertaining to the use of Mach-O binaries over PEF binaries if you don't need to worry about Classic support. It is also a well known issue that CarbonLib does not directly export OpenGL to Carbon apps and they have to go through QuickDraw in order to talk to it. There's a lot of commotion about Jaguar because it fixes this problem in Carbon.<hr /></blockquote>How many games has Brad ported to the Mac? A bunch.
And how many games do we know that you have ported to the Mac?

[ 07-15-2002, 01:27 AM: Message edited by: a2daj ]

Graymalkin · Jul 15, 2002, 12:50 AM

There's a good chance he's right and I'm wrong, I'm going by what is in Apple's tech docs. If I am wrong I'd really like to see some documentation with the right answers rather than sarcastic responses. I was hoping for a better discussion of the technical issues of CarbonLib than sarcasm. You want to give a better rundown of why I'm wrong Brad?

Deicide · Jul 15, 2002, 12:38 PM

Brad Oliver:

Do you know why the performance under MacOS X is not as good as it could be? Below is an email reply I got back from Blizzard about the issue.

<blockquote>quote:<hr /> This is something we have seen on some test systems as well. However, there is no solution at this time.

If you have a program like XOptimize, you might optimize your system again. Alternately, if you are comfortable with the command line interface, you might manually change he "dynamic_pager" values in the /./etc/rc file.

With Mac OS X, make sure no applications are running before you start the game.

You should also check the Process Manager application which is in the Utilities folder in the Applications folder.

Make sure there is not a process named "Mouse Distance Measurer" running. If it is, kill it before you start the game.

You should also set the refresh rate for your monitor as close to 75Hz as possible. With side screen, flat panel monitors, make sure you are not using a desktop resolution which is stretched to fit the whole screen.

In game, you should also set the "resolution", "model detail" and "texture detail" video options down a bit. <hr /></blockquote>I'm not pointing fingers at anyone, I just hope it gets fixed.

Jul 19, 2002, 12:58 PM

Running the game on Quicksilver Dual 800 with 1.5 gigs of RAM. To my knowledge, speed is relative to:

1) Where the game runs from

The application is stored in a RAID set which makes graphics and movies run silky.

2) Graphics card

Needless to say, it has to be fast. On basic GeForce2MX the speed is fast enough but doesn�t compare with GeForce4 Ti that ships with current high-end G4 systems.

3) Amount of memory on the system

4) Multiprocessing support on OS X

I�d think that the game runs faster on OS X specially if the hardware is equipped with multiple processors. As we all know, OS X can take full advantage of this feature, unlike OS 9 that has multiprocessing support only on portions of the OS itself and on very few applications.

Brad Oliver · Jul 19, 2002, 04:59 PM

<blockquote>quote:<hr />Originally posted by Graymalkin:
Would you kindly read the Carbon developer docs. PEF binaries are treated much differently at runtime than Mach-O files in X at runtime. The PEF binaries are run inside a Mach-O process which translates fragment issues into Mach-O compatible segment issues.<hr /></blockquote>It's important to note that the bulk of this translation happens at launch time, not run time, because of the differences between CFM and MachO. CFM apps need to know the link points early on, whereas MachO can use a 'lazy' approach and can resolve links when a routine is called during execution.

The best way to show this is via a real example. There are a number of sample apps on the Apple developer web site with Carbon CFM and MachO binaries. One excellent example is the "OpenGL Full Screen" sample app, which contains targets to build both CFM Carbon and MachO Carbon. Run them both and see. On my Mac, they both clock at 941-943 fps.

Another excellent example of the difference between CFM and Mach-O is provided by the CodeWarrior 8 project template code. Create two sample apps - one using the Mach-O C Toolbox stationery and another using the Carbon C toolbox stationery. Compile both apps and look at the resulting PowerPC code in assembler while debugging the app. Pay particular attention to the Carbon system call "InitCursor()" - it happens in the "Initialize()" routine in the sample code. Both the Mach-O and CFM sample apps call glue code to jump into the Carbon framework and then to the QuickDraw InitCursor call - "_InitCursor" in the Mach-O case and "InitCursor" in the CFM case.

You'll note that the glue code for the Mach-O case is larger than the glue code for the CFM case. This in fact has nothing to do with the 'lazy' linking of Mach-O (since the linker issues are handled right when the apps launch) but with the runtime differences between Mach-O and CFM. CFM's runtime model is actually more efficient for cross-segment jumps since it uses the RTOC (r2) register to store vectors. Mach-O has to perform an additional lookup out of memory. So what you're seeing is that CFM is in fact more efficient doing cross-segment jumps at runtime (by a nearly-imperceptible amount) over Mach-O. I should emphasize that this is a very small difference, so you'd be hard-pressed to measure the performance impact in all but the most demanding of cases.

<blockquote>quote:<hr />It is also a well known issue that CarbonLib does not directly export OpenGL to Carbon apps and they have to go through QuickDraw in order to talk to it. There's a lot of commotion about Jaguar because it fixes this problem in Carbon.<hr /></blockquote>I honestly have no idea what you're talking about - a link would be helpful. To get to OpenGL, you either go through AGL, CGL or the NSOpenGL stuff. QuickDraw is not a necessary ingredient for Carbon apps: you can use the AGL (or CGL) fullscreen API to set up a context, or connect an OpenGL drawable directly to a DrawSprocket context in Carbon CFM. THe sample app on Apple's site that I mention above does both of these things.

Since the source for this one is available, you can take a look for yourself at what's going on while it's running. If you have an example with source that illustrates otherwise, I'd be very interested in seeing it.

Brad

Graymalkin · Jul 19, 2002, 11:30 PM

Thanks for the reply Brad, I'll try to find the article I was reading about the whole Carbon/OpenGL problem I mentioned. The article was talking about Carbon code having to weak link to the OGL libraries because OGL wasn't being specifically exported to CarbonLib. I was also under the impression that in order for a Carbon app to get an OpenGL drawable you were required to use DrawSprocket to get context because that is how it was done in Classic and thus how you had to do it in X. That of course further impressed on me that Carbon apps using DrawSprocket under X were seeing a serious performance hit over using OGL to get a full screen context. Am I completely off here or do I only have a slightly jumbled perception of how OpenGL works in Classic? I've only done a small bit of OpenGL stuff in MacOS.

Brad Oliver · Jul 20, 2002, 12:18 AM

<blockquote>quote:<hr />Originally posted by Graymalkin:
Thanks for the reply Brad, I'll try to find the article I was reading about the whole Carbon/OpenGL problem I mentioned. The article was talking about Carbon code having to weak link to the OGL libraries because OGL wasn't being specifically exported to CarbonLib.<hr /></blockquote>I see where you're getting confused. CarbonLib is a CFM stub library that on OSX imports the entry points in Carbon.framework on 10. "OpenGLLibraryStub" is a similar stub library that imports the entry points in OpenGL.framework and AGL.framework. This has nothing to do with one not being accesible to the other, it's more a logical organization of the MacOS system calls into groups that match (more or less) how the libraries are organized on 10. A Cocoa Mach-O app does something similar, although they use the Mach-O frameworks directly - you link to Cocoa.framework and OpenGL.framework in that case. In other words, OpenGL is not part of Cocoa proper either.

<blockquote>quote:<hr />I was also under the impression that in order for a Carbon app to get an OpenGL drawable you were required to use DrawSprocket to get context because that is how it was done in Classic and thus how you had to do it in X. That of course further impressed on me that Carbon apps using DrawSprocket under X were seeing a serious performance hit over using OGL to get a full screen context. Am I completely off here or do I only have a slightly jumbled perception of how OpenGL works in Classic? I've only done a small bit of OpenGL stuff in MacOS.<hr /></blockquote>A hardware-accelerated OpenGL context can be attached to pretty much anything - a window (either through QuickDraw or the Cocoa NSOpenGL stuff), a fullscreen DrawSprocket context, or an AGL/CGL fullscreen context. I'm pretty sure you can also attach them directly to a CoreGraphics context, but I'm not positive. They all distill down to the same thing. You do have to take some care to set the contexts up properly to get maximum performance, but if you use Apple's OpenGL full screen code as a starting point, it's not an issue. You'll get nearly identical performance from hooking GL to DrawSprocket as you would any other route, and the sample app I mentioned before helps illustrate that. You can configure it to use either DrawSprocket or the agl fullscreen calls to acquire a fullscreen context to see for yourself.

Brad