If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

What I pointed out however, is that people had been playing Steam games on Mac through Bootcamp, and because of the poor quality of the Mac port, many of them continue to use Bootcamp rather than the native Mac versions.
They already had the Mac hardware to begin with.

My point was about answering the statement that just because there were now MAC game ports, MAC sells didn't sky rocketed....my point is that even if the ports were of good quality it really doesn't matter because Apple high prices for a limited hardware puts off lot's of users----and the perception that is a very closed "ecosystem" with Apple using a very tight grip on it.

Continuing to answer that statement and at same time answering your point, my answer is based in your....people in MAC don't like the ports because the ports are of bad quality.

Now...who's to blame ? is really alone of who made the ports ? ....or is also because Apple continues to have a tight grip about their systems like the graphic about how the structure is implemented ? VC OEMs are responsible by a part....the other part is programmed by Apple....i doubt that things are really optimized as much as they could be...

When you have bad quality game ports, high prices for the hardware, with a brand that is the only one making the MACs and with a tight grip of what is sold and/or approved to that platform, it's bound to NEVER be more than a product for an Elite.

My point was about answering the statement that just because there were now MAC game ports, MAC sells didn't sky rocketed....my point is that even if the ports were of good quality it really doesn't matter because Apple high prices for a limited hardware puts off lot's of users----and the perception that is a very closed "ecosystem" with Apple using a very tight grip on it.

The whole 'closedness' issue seems to be something that linux users would care about, not Windows users.
Cost... perhaps somewhat, although I know plenty of people who bought a Mac when they could have bought a cheaper Windows/whatever machine to do the same. They just like the Mac better and are willing to pay a bit extra for it.
Where a possible threshold for Mac might be price, I think usability is a threshold for linux. People aren't familiar with using a linux system, and many of their favourite applications may not be available. Macs are slightly closer to Windows, with things like Office, Photoshop, Premiere etc being available for both OSes.

Originally Posted by AJSB

Now...who's to blame ? is really alone of who made the ports ? ....or is also because Apple continues to have a tight grip about their systems like the graphic about how the structure is implemented ? VC OEMs are responsible by a part....the other part is programmed by Apple....i doubt that things are really optimized as much as they could be...

I would fully put the blame on the game developers yes.
I have ported my OpenGL code to OS X and iOS, and in both cases I had absolutely no issues with performance or compatibility (the common layer that Apple implements is only very minor anyway, and mainly used to set up the screen, the grunt rendering work is all done by the GLD).

Originally Posted by AJSB

When you have bad quality game ports, high prices for the hardware, with a brand that is the only one making the MACs and with a tight grip of what is sold and/or approved to that platform, it's bound to NEVER be more than a product for an Elite.

Is there anyone with interest in replacing OpenGL(Linux or not)?? In case there is such a big demand for D3D on Linux they can write a State tracker and be done with it. Can't they??

Well, its doable. All you'd really need is a 1:1 function equivalent for every OGL call. Problem is, so many DX functions rely on various Windows calls, you need to emulate those too to a certain extent. Plus, the overhead cost of running an interpreter.

Also remember its not just the graphics part of the game you need to rip out to make a port, you also need to remove all those windows specific API calls, and I can assure you theres a LOT of them. So making a OGL to DX wrapper won't magically make everything ported to linux.

Durandle says:
Iím interested to read that the rendering is achieved via a D3D > OpenGL abstraction layer, especially as it appears to be faster to do that than native D3D usage, that seems somewhat counter intuitive!

Iíd be interested to know though if your abstraction layer is generic enough that it could be applied with the same success to non-source-engine games, since that would be a nice big door to open, unless thatís something you donít wish to discuss right now! The prospect of an almost no-effort-needed wrapper that achieves native performance is a good one.

Valve Linux team says:
Although the abstraction layer is currently quite powerful donít think of it as an ďalmost no-effort-neededĒ layer. A lot of time and effort was spent to get the layer (and L4D2) to the point it is today and we still arenít finished.

Durandle says:
Is it overly simplistic to think of it as a library that exposes a DirectX API that converts to OpenGL on the fly?
(...) Would it be valid to compare what you are doing to be similar to what Transgamingís Cider does?

Valve Linux team says:
Itís too early to answer those questions as weíre still learning a lot about Linux porting but it is our hope that this work will be useful for porting games besides L4D2.

Well, its doable. All you'd really need is a 1:1 function equivalent for every OGL call. Problem is, so many DX functions rely on various Windows calls, you need to emulate those too to a certain extent. Plus, the overhead cost of running an interpreter.

Also remember its not just the graphics part of the game you need to rip out to make a port, you also need to remove all those windows specific API calls, and I can assure you theres a LOT of them. So making a OGL to DX wrapper won't magically make everything ported to linux.

Given the OS X port, its probably OK to assume those specific Win API calls are going to some sort of abstraction layer. They'll still need to write the functionality, but I imagine its a lot simpler when you're not playing hunt the platform specific code.