Is Source on OS X really openGL native?

[jeanlain]

Netkas asserts that he has found libraries in Source games that convert DirectX calls, much like Cider does.

www.netkas.org

I would trust Valve rather than Netkas, but I'm curious to know what these files are.

[RUSBoris]

Interesting

[poopdedoop78]

well, considering the way it runs in OS X, I can believe that it's not native OpenGL.

[jeanlain]

I bet these files are just remnants of Valve's own testings with several emulation methods. They did say they explored emulation.

[vtor67]

There are dll's because the same copy of the game has mac and pc binaries.
it is native openGL

[jeanlain]

They are not dlls; these are mac libraries (.dylib).

[Mangr0v3]

Well, I got a cryptic and strange response on [Macbeta]:

Me: Why is there a client and server DLL in my ~/Documents/Steam\ Content/<username>/Team\ Fortress\ 2/tf/bin ?
Valve: Because that is the game and how it runs.
Me: :confused:

[jeanlain]

Well, I got a cryptic and strange response on [Macbeta]:

Me: Why is there a client and server DLL in my ~/Documents/Steam\ Content/<username>/Team\ Fortress\ 2/tf/bin ?
Valve: Because that is the game and how it runs.
Me: :confused:
Put them to the trash and see if it still works. :D

[GHRobson]

*Talking with no knowledge of what im saying alert*

Maybe its so mods that use Dlls will still work without a special mac version having to be made?

[Mangr0v3]

*Talking with no knowledge of what im saying alert*

Evidently. Mods would still need to be recompiled/ported.

[Mangr0v3]

Put them to the trash and see if it still works. :D

TF2 puts them back when it launches.

[rbarris]

I wrote the native OpenGL module for Source Mac. It presents a DX9 compatible interface to the engine, engine calls me, I call GL, dots appear.

The performance issues being investigated are generally driver level things - below this layering. The layering doesn't exhibit any noticeable overhead in our profiling.

The whole app is compiled with gcc as a native Mach-O binary using the OS X toolchain.

[rbarris]

Oh and the .dll's are not loaded, they are extraneous content. You're welcome to "sudo fs_usage" to prove it..

[orudge]

It's definitely an OpenGL port. when Valve ported Source to the Mac, I guess they just couldn't be bothered to go and add code that says "if Windows, use this filename, if Mac, use that", since it makes no difference technically. Better to keep the codebase simpler, less likelihood of bugs creeping in as a result.

And for those wondering why there's a client.dll and server.dll on the Mac port - well, look at the "portal\portal\bin" directory inside steamapps on Windows - they also have client.dylib and server.dylib. (The same is true for TF2 for me on Windows as well.) Again, for whatever reason, Steam just installs them onto both systems. Nothing really to read into, and no need to jump to conclusions!

EDIT: Ah, confirmation from rbarris himself there, too, while I was writing this post!

[bib fortuna]

dots appear

[sketch7]

I'm a forum newbie - but I do think it's very cool that Valve employees are on here and can talk to us common folk.

[Mangr0v3]

I like those dots. Thanks rbarris.

[DustArma]

Well, since we are speaking about OpenGL here, rbarris, is there any plans to release OpenGL support for the Windows version?

[vtor67]

Well, since we are speaking about OpenGL here, rbarris, is there any plans to release OpenGL support for the Windows version?

he already said no in the mac discussion thread.

[DustArma]

Oh well, it didn't hurt to try

[Fuzz Bucket]

Well, since we are speaking about OpenGL here, rbarris, is there any plans to release OpenGL support for the Windows version?
From another thread:
No, the OpenGL code is only part of the Mac build.

[Tin-Joe]

I know 10.6.4 is supposed to have some graphics updates. Anyone in the beta for that know if the performance has improved (or would that be covered by an NDA)?

[vtor67]

n the beta for that know if the performance has improved (or would that be covered by an NDA)?

I doubt it's covered by an NDA, but I'm pretty sure rbarris has his hands on 10.6.4 already :cool:

[Tin-Joe]

I doubt it's covered by an NDA, but I'm pretty sure rbarris has his hands on 10.6.4 already :cool:

You never know with apple :p

[dirk0gently]

I want to put this out there to the guys at valve. I love that you are coming to the mac platform, problem is I don't like how you are doing it. You say you have an interface "driver" of sorts that communicates between DX and OpenGL. To be honest this has been done before and has not had good results. The best example I can make of this is Halo for mac. The entire game uses a translation buffer of sorts between OpenGL which is what is used to render the game, and the DX which runs the game. Over the years that has been really hard for them to keep going and keep going well. Many issues have cropped up that they either cannot fix or are not willing to take the massive amount of time it would take to fix and debug issues with the game now. Bad frame-rate, incorrectly rendered or poorly rendered shaders plague the latest version of halo if you are on newer hardware.

While I cannot dictate what you should or should not do, I think it would be highly recommended for you to favor a purely OpenGL version of your engine over any sort of translation. Translation is slower and will cause different problems on different hardware based purely off what the graphics card can do. To bring up Halo again, there different are shader rendering issues that happen on Nvidia cards, and ati cards and intel chipsets.

While you might not face these problems now in the early stages, I think it will be much more work for you in the long run to upkeep such code, especially over mac systems and maybe linux systems in the future.

I have two links here that I hope you can take some time to read from an indie development company that works on all three platforms (mac, windows, linux):
http://blog.wolfire.com/2010/01/Why-you-should-use-OpenGL-and-not-DirectX
http://blog.wolfire.com/2010/01/DirectX-vs-OpenGL-revisited

Thanks for your work and time.

[zorinlynx]

I want to put this out there to the guys at valve. I love that you are coming to the mac platform, problem is I don't like how you are doing it. You say you have an interface "driver" of sorts that communicates between DX and OpenGL. To be honest this has been done before and has not had good results. The best example I can make of this is Halo for mac. The entire game uses a translation buffer of sorts between OpenGL which is what is used to render the game, and the DX which runs the game. Over the years that has been really hard for them to keep going and keep going well. Many issues have cropped up that they either cannot fix or are not willing to take the massive amount of time it would take to fix and debug issues with the game now. Bad frame-rate, incorrectly rendered or poorly rendered shaders plague the latest version of halo if you are on newer hardware.

While I cannot dictate what you should or should not do, I think it would be highly recommended for you to favor a purely OpenGL version of your engine over any sort of translation. Translation is slower and will cause different problems on different hardware based purely off what the graphics card can do. To bring up Halo again, there different are shader rendering issues that happen on Nvidia cards, and ati cards and intel chipsets.

While you might not face these problems now in the early stages, I think it will be much more work for you in the long run to upkeep such code, especially over mac systems and maybe linux systems in the future.

I have two links here that I hope you can take some time to read from an indie development company that works on all three platforms (mac, windows, linux):
http://blog.wolfire.com/2010/01/Why-you-should-use-OpenGL-and-not-DirectX
http://blog.wolfire.com/2010/01/DirectX-vs-OpenGL-revisited

Thanks for your work and time.

I agree with you to some extent, but also have this to say:

rbarris wasn't working on Halo. :)

(Okay, so maybe this was an obvious flattery attempt, but on the other hand it's true: Look what he pulled off while working at Blizzard, and how quickly he got Source engine going on OS X. Valve and its people know what they are doing!)

[drunkugly]

have to agree with zorinlynx. blizzard has done really well with their games on mac. and so far (even thought i am one of the ATI card people having an issue with water in portal), the cleaness of the game and the interface say to me that valve knows what they are doing. isn't halo a microsoft game? can't say that i liked their previous work.

[dirk0gently]

I agree with you to some extent, but also have this to say:

rbarris wasn't working on Halo. :)

(Okay, so maybe this was an obvious flattery attempt, but on the other hand it's true: Look what he pulled off while working at Blizzard, and how quickly he got Source engine going on OS X. Valve and its people know what they are doing!)

Thanks for missing the point entirely. This is not about halo this is about half-assing it and not giving full OpenGL support where it needs to be. By introducing a unneeded component, in this case the translator, you WILL get erroneous bugs because of differences in driver support for the card you are using. I am not going to be presumptous and say that "THIS WILL HAPPEN LIKE HALO DID" I am simply explaining what has happened previously. I would honestly prefer to have 100% native games running in OpenGL without having to translate again.

And to answer your statement of "Valve knows what it is doing", if they did know what they were doing then they would not have pushed an update on portal that has caused a lot of problems for people by rendering portals as black. Sorry to be completely blunt about this but that is the very thing I am talking about here. Now, I don't think valve would intentionally push out an update that did this, so I am lead to believe it is caused by something that is variable. The only thing that is variable here is the drivers and driver support for OpenGL on OS X. Different cards have different capabilities and because they are not the same across all system this will cause problems that I have already stated for the translation between OpenGL and DX.

Edit:

halo on mac was done by westlake interactive, macsoft and gearbox. microsoft had no hand in it.

[rbarris]

I can tell you guys haven't actually run a profiler on our stuff to see where the time actually goes each frame. There be dragons in the swamp..

Also please share the names of the Mac GL-based titles any of you have worked on, I am curious!

[RambJoe]

I wrote the native OpenGL module for Source Mac. It presents a DX9 compatible interface to the engine, engine calls me, I call GL, dots appear.

The performance issues being investigated are generally driver level things - below this layering. The layering doesn't exhibit any noticeable overhead in our profiling.

The whole app is compiled with gcc as a native Mach-O binary using the OS X toolchain.

Who's writing the Linux version?

[giselher]

I wrote the native OpenGL module for Source Mac. It presents a DX9 compatible interface to the engine, engine calls me, I call GL, dots appear.

The performance issues being investigated are generally driver level things - below this layering. The layering doesn't exhibit any noticeable overhead in our profiling.

The whole app is compiled with gcc as a native Mach-O binary using the OS X toolchain.

Sounds like ... wine?

I can tell you guys haven't actually run a profiler on our stuff to see where the time actually goes each frame. There be dragons in the swamp..

Also please share the names of the Mac GL-based titles any of you have worked on, I am curious!

Sure, it isn't easy to rewrite an dx engine to gl, don't be angered and keep the good work up. :D

[ModplanMan]

I can tell you guys haven't actually run a profiler on our stuff to see where the time actually goes each frame. There be dragons in the swamp..

Also please share the names of the Mac GL-based titles any of you have worked on, I am curious!

I am curious, why is geforce 7 series cards acceptable on Windows, but not on Mac (upped requirements to geforce 8 series)?

Having used WINE which uses presumably a similar/same method of translating DX calls to openGL, Geforce 7200 GS can run source games pretty respectably in Windows, especially in DX8 mode. However, through WINE on Linux, it's not too good even on DX8, generally leading to a not good enough experience.

So why would Mac need higher system requirements if there wasn't a performance loss from not doing it native (and not native in the sense of WINE)? Indeed, this method sounds exactly like WINE, but simply specific to source.

[mastertheknife]

I can tell you guys haven't actually run a profiler on our stuff to see where the time actually goes each frame. There be dragons in the swamp..

Also please share the names of the Mac GL-based titles any of you have worked on, I am curious!

rbarris,
Its really nice of you to respond to the questions in the forums with great explanations, Keep up the good work!


Awaiting a Linux version,
mastertheknife.

[dirk0gently]

Well I am running a profile right now, and I will be doing so for the next hour or so and I see a library called "GLEngine" calling a function named "convertValues" and it seems to be running at a constant 5-6% in portal as well as a number of calls from shaderapidx9 library in the .1-.9% mark. My point is that using a translation system is slower compared to running native as well as having the potential to cause problems down the road with compatibility. Some of these issues we are already running into for ATI users with the water shaders in portal. I really don't mean to disrespect what you do but there is no point in ignoring something that in the long run is going to be more harm to you than good.

[Neoluxembourg]

Thanks for missing the point entirely. This is not about halo this is about half-assing it and not giving full OpenGL support where it needs to be. By introducing a unneeded component, in this case the translator, you WILL get erroneous bugs because of differences in driver support for the card you are using. I am not going to be presumptous and say that "THIS WILL HAPPEN LIKE HALO DID" I am simply explaining what has happened previously. I would honestly prefer to have 100% native games running in OpenGL without having to translate again.

And to answer your statement of "Valve knows what it is doing", if they did know what they were doing then they would not have pushed an update on portal that has caused a lot of problems for people by rendering portals as black. Sorry to be completely blunt about this but that is the very thing I am talking about here. Now, I don't think valve would intentionally push out an update that did this, so I am lead to believe it is caused by something that is variable. The only thing that is variable here is the drivers and driver support for OpenGL on OS X. Different cards have different capabilities and because they are not the same across all system this will cause problems that I have already stated for the translation between OpenGL and DX.

Edit:

halo on mac was done by westlake interactive, macsoft and gearbox. microsoft had no hand in it.

You don't get it!

There's no driver between opengl and direct3d. The source engine, like all normal engines, don't draw directly to direct3d, it uses a special interface. So, if the engine needs to draw a dot it calls the "drawDot" (only an exemple) methode. This methode then calls the direct3d methode needed to draw this special dot.

If you want to use something other then direct3d, you only need to rewrite the drawDot methode and not the entire engine.

You can place this methodes (drawDot, drawPath, drawRect, etc...) in a .dll for a more simple separation ...

This is something you normaly do when programming in a Object oriented envirenment ...

[rbarris]

Sounds like ... wine?


No. With Wine, a Windows-built .exe is loaded into a UNIX process and then tricks are done to make to able to run.

On Mac Source, all of the source code has been compiled native. Specific modules have been replaced with ones that can drive OS X API's, like graphics and sound. All the OpenGL code lives in a little lib called "shaderapidx9" which is shorthand for "the shading subsystem that can run on dx9-class hardware". That's sort of the grand central station for graphics API traffic coming out of the engine and down into the OS&driver.

[rbarris]

Well I am running a profile right now, and I will be doing so for the next hour or so and I see a library called "GLEngine" calling a function named "convertValues" and it seems to be running at a constant 5-6% in portal as well as a number of calls from shaderapidx9 library in the .1-.9% mark. My point is that using a translation system is slower compared to running native as well as having the potential to cause problems down the road with compatibility. Some of these issues we are already running into for ATI users with the water shaders in portal. I really don't mean to disrespect what you do but there is no point in ignoring something that in the long run is going to be more harm to you than good.

Do you know who authored GLEngine? That's Apple driver code.

The need for an optimized transport for shader parameter arrays is on file as Radar 5281595, filed June 2007. I helped guide the specification of the uniform buffer object extension which will potentially ease the one bottleneck you see there, it's in the GL 3.1 standard.

Next question.

[dirk0gently]

Do you know who authored GLEngine? That's Apple driver code.

The need for an optimized transport for shader parameter arrays is on file as Radar 5281595, filed June 2007. I helped guide the specification of the uniform buffer object extension which will potentially ease the one bottleneck you see there, it's in the GL 3.1 standard.

Next question.

Ok, thanks.

[giselher]

No. With Wine, a Windows-built .exe is loaded into a UNIX process and then tricks are done to make to able to run.

On Mac Source, all of the source code has been compiled native. Specific modules have been replaced with ones that can drive OS X API's, like graphics and sound. All the OpenGL code lives in a little lib called "shaderapidx9" which is shorthand for "the shading subsystem that can run on dx9-class hardware". That's sort of the grand central station for graphics API traffic coming out of the engine and down into the OS&driver.

Thanks for the Informations. I never really asked myself how wine really works.

Does those specific modules also work on windows (or other operating systems), or are these OS X only?

[mastertheknife]

No. With Wine, a Windows-built .exe is loaded into a UNIX process and then tricks are done to make to able to run.

On Mac Source, all of the source code has been compiled native. Specific modules have been replaced with ones that can drive OS X API's, like graphics and sound. All the OpenGL code lives in a little lib called "shaderapidx9" which is shorthand for "the shading subsystem that can run on dx9-class hardware". That's sort of the grand central station for graphics API traffic coming out of the engine and down into the OS&driver.

Hi rbarris,
Thanks again for the explanation.
What OpenGL version is in use by the Source engine for Mac?


Thanks,
mastertheknife.

[deufeufeu]

Hi rbarris, you seem to imply that there is no real problem or overhead by doing a directx->opengl adapter. This claim seems a bit wrong. You need to limit your code to what can be directly adapted from directx to opengl, and so, you might not benefit from some directx-specific optimizations in the way things are done. Reciprocally, you can't easily use a completely different architecture for handling something like reflections which could be seen in a pure opengl application.
But I'd have to say that this is a common pitfall of all multiplatform programs. A graphic engine that runs both on directx and mac OpenGL will be slower and more limited in terms of feature than one focused on either of them. Yet, it's true that having started from a directx engine, performance should be biaised.
About the function call overhead, in a multiplatform engine you need to do an abstract call that get resolve either to a directx call or an opengl call. What is the difference? (in a good system you normally abstract these calls in messages that can be treated by packet, so that the abstraction cost even less)
As a final note, I'd have to confirm that the weakests links are apple drivers. Recently at work we just discovered that some calls in shaders could degrade performance from a 40fps on windows to less than 1fps on mac... And this was just one of many.
I'm glad valve made the jump so that maybe we could have a functional opengl implementation on the mac :)

[rbarris]

Hi rbarris,
Thanks again for the explanation.
What OpenGL version is in use by the Source engine for Mac?


The one that ships in OS X - which is best characterized as GL 2.1 plus nearly all of the GL3 extensions. However we also run on 10.5.8 which has a subset of that, there are fallback code paths to make that go.

[sHaDdow]

I love how the valve staff actually have conversations with there customers. It's nice to see that sort of thing.

Plus i'm sure that DirectX names in the code are just a part of the rendering interface that just so happens to have DirectX names in them because of legacy code. He just did a different implementation of that interface.

[Midnitte1]

dots appear.

New favorite quote.

I cant wait till I get a macbook.... I want to see steam running in my bleveled aluminium computer!

[gavriels]

Do you know who authored GLEngine? That's Apple driver code.

The need for an optimized transport for shader parameter arrays is on file as Radar 5281595, filed June 2007. I helped guide the specification of the uniform buffer object extension which will potentially ease the one bottleneck you see there, it's in the GL 3.1 standard.

Next question.

How come your not using ARB shaders, like the cool kids do? :cool:

[rbarris]

How come your not using ARB shaders, like the cool kids do? :cool:

Hi Gav -

We did initially, but then hit some hurdles which could not be solved in ARB and had to go to GLSL. Once we had that running, we did some more work to optimize as much as possible on the uniform transport stuff. i.e. the observed cycle cost in glUniform4fv used to be a lot higher than what it is now.

[vicegold]

Next question.

Why is the Multicoreoption grayed out? I've got a Core i7, but can't use it!?

[Dakoman]

Im curious to know, how long ago did you start development on the mac port of steam/source? I understand you may not be allowed to answer this...

[Genexi2]

I just hope the new influx of Valve titles will give driver optimizations a jump start on Apple's priority list.

You guys have done them a pretty large indirect favour in bringing Steam over to their hardware.

[Mangr0v3]

Why is the Multicoreoption grayed out? I've got a Core i7, but can't use it!?
I think it's forced on.
Im curious to know, how long ago did you start development on the mac port of steam/source? I understand you may not be allowed to answer this...
Good question, I also want to know this.
I just hope the new influx of Valve titles will give driver optimizations a jump start on Apple's priority list.

You guys have done them a pretty large indirect favour in bringing Steam over to their hardware.
10.6.3 brought driver optimisations, and apparently 10.6.4 has even better drivers.

[jeanlain]

I think 10.6.3 added more features related to openGL and drivers. Apparently some Apps (VMware Fusion, Premiere CS5) can can accelerate stuff they couldn't accelerate before.
10.6.4 will solve bugs and optimize the new features, presumably.

[gryph]

can you answer these question for people following this thread who are clueless?


1) does mac hardware support triple buffered v-sync? (generally)

2) if it does (see #1) why wasn't it implemented on mac?

3) this will theoretically increase the fps in portal correct?


thanks in advance

[ack226]

rbarris, can you comment on how much (if at all) the OpenGL updates in OSX 10.6.4 will improve the performance of Source on Mac? How applicable are they to the source engine?

Thanks so much for what your'e doing to bring top-tier native games to Mac and for taking the time to answer questions and keep us updated. You're really breaking new ground on both counts.

[jeanlain]

I'm interested in the Vsync issue too.
Regarding 10.6.4, RBarris is probably under NDA so don't bother asking. Just wait for Apple to release the update. :)

[Pilotclan9404]

Linux - Please IS ANYONE working on even TRYING to port it? or looking into the IDEA?

[Fuzz Bucket]

Linux - Please IS ANYONE working on even TRYING to port it? or looking into the IDEA?

Is this thread or forum about or for Linux? :P

[dafootballer]

i just read the OP so i dont know whats going on but i can say that with my many, many experiences with Cider, Wine, Crossover that Portal does not use any type of emulation as the many unofficial Cider, Wine, Crossover ports on the net do not have near the performance of this native client.

my 2 cents

[Psyke89]

Off-Topic, but... is there any way to use Source's OpenGL on Windows? or it's just for MacOSX?

[docwhat]

Off-Topic, but... is there any way to use Source's OpenGL on Windows? or it's just for MacOSX?

Already been answered in this thread: "No".

Ciao!

[evilspoons]

Off-Topic, but... is there any way to use Source's OpenGL on Windows? or it's just for MacOSX?

I think halfway through this thread it was mentioned that OpenGL is only implemented in the Mac binaries.


I too will chime in saying it is awesome to see a game developer talking directly with everyone. I haven't tried Portal yet because my Mac laptop isn't exactly the fastest compared to my Windows desktop (Geforce 8600M GT vs GTX 285, haha) but I am very excited to see it show up along with my copies of Peggle, Braid, and Torchlight!

[Seph64]

Linux - Please IS ANYONE working on even TRYING to port it? or looking into the IDEA?

If Valve is indeed working on a Linux port, it's doubtful that they will answer any questions concerning the Linux version until they make an official announcement.

But yes, this is not the thread for these questions.

[fleshweasel]

Why does Valve enable Vsync by default in their games?

[Fuzz Bucket]

Off-Topic, but... is there any way to use Source's OpenGL on Windows? or it's just for MacOSX?

According to rbarris, no.

[spuy767]

It appears to be OpenGL native based on the processes that start when a game is running, but it does seem to be running a little slow. Perhaps Valve and Blizzard should have a sit down because WoW's OpenGL engine for Mac wipes the floor with the PC version of WoW. I get almost double the FPS under Mac OS vs Win 7. And Win 7 is a clean install with only a few games on it. The Mac Disk has all my applications on it and it's a two year old install. If I'm not mistaken, the OpenGL engine that WoW runs is multi-processor optimized.

[wsippel]

Why does Valve enable Vsync by default in their games?
Because tearing sucks.

[dirk0gently]

Because tearing sucks.

You know, I cannot remember the last time I played a native game that didn't have vsync on as default.

[jeanlain]

It appears to be OpenGL native based on the processes that start when a game is running, but it does seem to be running a little slow. Perhaps Valve and Blizzard should have a sit down because WoW's OpenGL engine for Mac wipes the floor with the PC version of WoW. I get almost double the FPS under Mac OS vs Win 7. And Win 7 is a clean install with only a few games on it. The Mac Disk has all my applications on it and it's a two year old install. If I'm not mistaken, the OpenGL engine that WoW runs is multi-processor optimized.
So is Source (which is why multicore rendering is enabled by default in the graphic options). Rob Barris used to work at Blizzard. He knows about multithreaded openGL.
WoW and Source may differ in that Source uses newer openGL functions, some of which were probably implemented in 10.6.3. These functions need optimization.

[RUSBoris]

It appears to be OpenGL native based on the processes that start when a game is running, but it does seem to be running a little slow. Perhaps Valve and Blizzard should have a sit down because WoW's OpenGL engine for Mac wipes the floor with the PC version of WoW. I get almost double the FPS under Mac OS vs Win 7. And Win 7 is a clean install with only a few games on it. The Mac Disk has all my applications on it and it's a two year old install. If I'm not mistaken, the OpenGL engine that WoW runs is multi-processor optimized.

Definitely. WoW's OS X version is awesome. Same graphic details but with higher FPS. sooo stable and great :)

(not sarcasm)

[spuy767]

So is Source (which is why multicore rendering is enabled by default in the graphic options). Rob Barris used to work at Blizzard. He knows about multithreaded openGL.
WoW and Source may differ in that Source uses newer openGL functions, some of which were probably implemented in 10.6.3. These functions need optimization.

I appreciate that, but the fact is that There is at least a 4:1 Difference in performance if you consider that WoW is roughly 2x as fast in OGL on Mac and Source is actually quite a bit less than 1/2 the frame rate. Now I'm not going to bust Valve's balls, I understand that this doesn't happen overnight and that blizz has been developing WoW for the Mac for something like 5 years. What I'm really saying is that I'd hope that performance would reach parity, if not exceed the PC version in time. Of course, I can only state the experience I have with my machine, and other people's mileage may vary, but with the same setting, resolution and effects, WoW for my PC averages between 80-100 FPS, while the Mac Version Averages closer to 200.

[rbarris]

So if we were to continue investigating performance reports from the user base, identifying bottlenecks, filing bugs with Apple, making improvements in our code, and continuing to ship updates to these titles over coming weeks to months to improve them in conjunction with OS/driver updates... would that be a good plan?

[Fuzz Bucket]

So if we were to continue investigating performance reports from the user base, identifying bottlenecks, filing bugs with Apple, making improvements in our code, and continuing to ship updates to these titles over coming weeks to months to improve them in conjunction with OS/driver updates... would that be a good plan?

Of course. :O

[dirk0gently]

So if we were to continue investigating performance reports from the user base, identifying bottlenecks, filing bugs with Apple, making improvements in our code, and continuing to ship updates to these titles over coming weeks to months to improve them in conjunction with OS/driver updates... would that be a good plan?

Absolutely.

[wsippel]

It appears to be OpenGL native based on the processes that start when a game is running, but it does seem to be running a little slow. Perhaps Valve and Blizzard should have a sit down because WoW's OpenGL engine for Mac wipes the floor with the PC version of WoW. I get almost double the FPS under Mac OS vs Win 7. And Win 7 is a clean install with only a few games on it. The Mac Disk has all my applications on it and it's a two year old install. If I'm not mistaken, the OpenGL engine that WoW runs is multi-processor optimized.
rbarris was actually the lead engineer of Blizzards Mac team... ;)

[rbarris]

I'm so glad people like the plan. OK I'll stick with it then.

[Mangr0v3]

I knew it XD

[Fuzz Bucket]

I knew it XD

What? That Burton likes Snickers?

[heatwave21]

So if we were to continue investigating performance reports from the user base, identifying bottlenecks, filing bugs with Apple, making improvements in our code, and continuing to ship updates to these titles over coming weeks to months to improve them in conjunction with OS/driver updates... would that be a good plan?

Hasn't that been the plan all a---

I'm so glad people like the plan. OK I'll stick with it then.

That's what I thought. In conclusion: Everything is under control. Any problems you may be experiencing will be solved in time. If you notice that your problem is still present after a few months, then you can start complaining.

The good people of Valve (like rbarris) have done you all (myself included) a huge favor in bringing Steam to Mac, and it is in their best interest to deliver a good experience to their users.

[bear912]

I'm so glad people like the plan. OK I'll stick with it then.

Please do. Me love plan. :D

[bear912]

I like those dots. Thanks rbarris.

Me too.

I doubt it's covered by an NDA, but I'm pretty sure rbarris has his hands on 10.6.4 already :cool:

Erm, ever used any pre-release software from Apple? :p My guess is that that performance data does fall under the/an NDA. We'll know if performance improves when 10.6.4 ships, and probably not before then.

Edit: Also, just a reminder, rbarris has been writing and maintaining code for Mac games for, what is it? Nine years? I'm guessing he probably has a fairly decent idea of what he's doing. Just a hunch I have.

[AngelGraves13]

Has coding and optimizing for OpenGL and OS X got any performance tweaks down to Windows users, similar to when the Source engine was optimized for the X-Box a couple of years ago?

Also, any idea if the Source engine will get DirectX 11 and OpenGL 4.0 support for hardware tessellation and soft particle edges?

[mitch_mac]

To the kind STEAM Mac devs:
Am i right with the thinking, that even Apple does an perfect overhaul of their OpenGL drivers and Steam does perfect job, an gap of 10%-15% speed difference to DirectX9 will not get closed ?
Due to the different goal/usage of DirectX9 API-more for games+not so accurate to OpenGL API- more universal+more accurate/stable ?
So i think closing the speed gap to PC/Bootcamp(Win) is on Apple : put faster gpus + faster cpus in the Macs (beside overhaul the OpenGL drivers!) Because of Apples ALLINONE focus that may never happen :(
I like STEAM Mac even if has bugs, but i dont have any speed problems with my 8800GTX 768MB (running an hackintosh - Apple hasnt 8800GTX cards, nor GTX260, nor ATI 4890 1GB, ... like hackintoshs ;) )
Many THANKS! that Steam Mac supports+knows all non Apple GPU types (used in hackintoshs) also

Steam Mac Info of 8800GTX (http://www.maclife.de/forum/download/file.php?id=21114&mode=view)

[rbarris]

As you know if you've followed our release schedule, predictions may not turn out the way you'd expect.

The interfaces with GL and D3D are really not so far apart. In fact if you look at the evolution of GL 3.x (3.0, 3.1, 3.2, 3.3) things are getting more and more streamlined at the API level. Apple is sort of in between since they currently have GL 2.1 plus a large set of GL 3.x extensions. There are a couple we're still looking forward to using that can further boost performance.

It's an ongoing process, might take a few revisions to move the needle higher but we are pushing on it.

[mitch_mac]

THANKS !
But for sure: To have fast cpu + gpu helps much to get good FPS also - beside OpenGL speedups in near future.
9400M, GT120 & Co (low hw Speed + less hw features) will never perform really well, i bet.

[Darkjad]

Not gonna lie, some of the stuff in this thread is beyond my knowledge, and that's OK.

Just wanted to let you know rbarris that it's very badass that you're out here in the forums, discussing highly technical issues with your customers. I know we can often get irate and angry and ungrateful (I'm not calling out anyone in specific or anything like that; just how the interwebz are) but I really think it's awesome that you're out here braving the wilds anyways.

Thanks for all your help.

[Stumf]

I agree, this is a fascinating read!

[PaoloM]

I'm not a Mac user, but I have to say that I don't like all this teaching to a professional how to do his work. Some people in this thread make assumptions out of thin air. I am a developer and when people criticize the way I'm coding without knowing what I've coded, this makes me really angry. rbarris, keep up the good work. You are the only one knowing how things work and how things are to be done.

[rbarris]

yikes. au contraire. team effort, I learn new things every day from the experts of the Source engine internals..

[mr1ncr3du10u5]

I'd just like to add my thanks too to rbarris and team behind Mac Source. Portal is running twice as smooth today as it was on release date on my 3-year old Macbook Pro thanks to the constant updates. Fantastic stuff!

[Mangr0v3]

yikes. au contraire. team effort, I learn new things every day from the experts of the Source engine internals..

I just noticed, your rep is the same as TF2's AppID. How appropriate.

[mastertheknife]

As you know if you've followed our release schedule, predictions may not turn out the way you'd expect.

The interfaces with GL and D3D are really not so far apart. In fact if you look at the evolution of GL 3.x (3.0, 3.1, 3.2, 3.3) things are getting more and more streamlined at the API level. Apple is sort of in between since they currently have GL 2.1 plus a large set of GL 3.x extensions. There are a couple we're still looking forward to using that can further boost performance.

It's an ongoing process, might take a few revisions to move the needle higher but we are pushing on it.

Thanks for the information rbarris,
Yeah, OpenGL has come a long way.
Its quite a shame though that Apple is lagging really behind when it comes to OpenGL, When Windows and Linux drivers from Nvidia and AMD already support OpenGL 4.0.

Can we expect in the future another OpenGL renderer that is targetted for newer OpenGL version than 2.1 and perhaps exposes DirectX10 interface to the engine, or perhaps a more internal OpenGL renderer?

Thanks for your time and patience,
mastertheknife.

[NeoRazorX]

Valve should have chosen Linux before Mac ... Linux has OpenGL 4.0 support under NVIDIA/ATI propietary drivers

[FroggySwede]

Valve should have chosen Linux before Mac ... Linux has OpenGL 4.0 support under NVIDIA/ATI propietary drivers
Something tells me they chose to implement the Mac version first for other than technical reasons. ;)

[2befine]

Something tells me they chose to implement the Mac version first for other than technical reasons. ;)

haha, true!

[Peter_J_Georg]

Valve should have chosen Linux before Mac ... Linux has OpenGL 4.0 support under NVIDIA/ATI propietary drivers

Please tell me how much people out there have a PC that can run OpenGL 4.0? 3%?

Linux is a big problem for developers, if there is going to be a Linux release I'm sure they'll only officially support few (~3) distributions.

[wsippel]

Linux is a big problem for developers, if there is going to be a Linux release I'm sure they'll only officially support few (~3) distributions.
It's not that complicated, actually. The main problem in that regard is package management, which is why most developers of commercial applications simply don't use package managers anymore. They either use custom installers or just ship an archive. Especially self contained applications like Steam shouldn't have any issues, as they only rely on very few system components. And if there's some tweaking involved, leave it to the distribution packagers.

Another problem is (or was) the developers mindset and inexperience with the operating system. A few years ago, I managed to install XSI on a 64bit gentoo Linux with NPTL, which was completely unsupported and simply shouldn't work according to Softimage. The only distribution Softimage supported was an old 32bit non-NPTL version of Red Hat. It took me maybe two hours to fix it, completely replacing their terrible Mainwin support and setup scripts. I downloaded a couple of libraries from said Red Hat distribution, wrote a new wrapper that preloaded those libraries, and that's all it took. After some testing I confirmed that the very same setup worked on most, if not all distributions, so I posted in on a XSI user forum, and all of a sudden, XSI supported pretty much all distributions.

[Glacial42]

FFFFFFFFFFFF must resist

[officerd1ck]

rbarris.

How about a Mac OS X hardware survey for Source games, this way you could narrow down the hardware that is having pronblems.

Just pull out the hardware data for the machine, and ask the player the following questions.

Have you run Portal on this machine on Windows through BootCamp?

-Yes
-No
-I do not know.

(if yes) Did you have a better or worse gaming experience in Mac OS X, regarding graphic and sound performance, compared to your windows experience.

-much better
-better
-same
-worse
-much worse
-don't know

[mitch_mac]

I can see so sense for that question about win / os x .

[dirk0gently]

rbarris.

How about a Mac OS X hardware survey for Source games, this way you could narrow down the hardware that is having pronblems.

Just pull out the hardware data for the machine, and ask the player the following questions.

Have you run Portal on this machine on Windows through BootCamp?

-Yes
-No
-I do not know.

(if yes) Did you have a better or worse gaming experience in Mac OS X, regarding graphic and sound performance, compared to your windows experience.

-much better
-better
-same
-worse
-much worse
-don't know
The windows/osx question is not balanced. due to driver differences on windows (what version) and even across platform is not going to be a good judge of performance. Best way to judge would be across OS X platform hardware.

[sebideluxe]

I just read the complete thread and since I am on a late 2006 iMac with an NVIDIA 7600GT and I have around 1-2 fps in the game "torchlight" (no source engine, i know) even on lowest settings: Could that be related? That Torchlight uses one of those extensions not implemented in the GeForce 7 series driver? Is there any workaround since I cannot play that game I just purchased and which runs on GMA950 with full details.

[officerd1ck]

@dirk0gently

It might not be accurate, but it will still be somewhat useful data.

[elmancho02]

Erm, guys, COOLEST thread ever!