linux gaming on horizont

This looks like the opossite to Scitech GLdirect that was translating OpenGL to DirectX in Windows.

I suppose this is specifically for dota2 linux port .... wonder if it could be used to port all those games that are already xbox 360 ports :laugh: wonder how a bad port of a bad port would be like

with this and the crytek engine available on linux it looks like easy rhino was right 5 years ago. please bow down.

valve is working to make soruce 2 linux capable and then port all source 2 based games to linux

I don't know if this will affect much. Cedega is more mature, has been around since like forever and I can only think of one game that has used it.

How about we all stop calling each other trolls or whatever name it is at the time and move on!
This is a polite warning to everyone, move along, nothing to see here!

I never cease to be surprised that so much ignorance can fall upon one thread like flys around s**t, a warning was issued a while back, it has been ignored, so sadly pain is a coming, any more crap in here and we wont be talking modest 45 day holidays....... Thank You.

Does this add even more CPU overhead?

damricDoes this add even more CPU overhead?

Any compatibility layer is going to add some level of overhead. I'm curious if it's going to perform well.

AquinusAny compatibility layer is going to add some level of overhead. I'm curious if it's going to perform well.

Cedega 6.0 was reporting >90% native speed on some titles (Enemy Territory, WoW, etc.) but that was 4 years ago, not to mention that these translators support up to DX9c.

damricDoes this add even more CPU overhead?

in this day of 7 year old core i7 cpus being capable of running modern games at 60fps, I doubt that the cpu overhead of a program like this would really make any kind of sizable impact on any halfway modern gaming system.

TheinsanegamerNin this day of 7 year old core i7 cpus being capable of running modern games at 60fps, I doubt that the cpu overhead of a program like this would really make any kind of sizable impact on any halfway modern gaming system.

7 year old??

yep... they're getting that old now. though 6 yrs not 7.

xBruce88xyep... they're getting that old now. though 6 yrs not 7.

well..guess I should leave the counting to the i7 as well. It's amazing how long those things have been around and they still can run just about anything.

This is so going in the wrong direction. Instead of using direct HW acceleration through metal API's, they are now doing rendering through several extra layers of API's. How stupid is that, all with excuse they don't have to make double work. That's how console ports are born and i don't have to say it twice, they are all rubbish. I miss the days when games had engines designed from ground up to run on both Direct3D and OpenGL from day one. Remember all the Unreal Engine based games from 1999-2003 or so?

RejZoRThis is so going in the wrong direction. Instead of using direct HW acceleration through metal API's, they are now doing rendering through several extra layers of API's. How stupid is that, all with excuse they don't have to make double work. That's how console ports are born and i don't have to say it twice, they are all rubbish. I miss the days when games had engines designed from ground up to run on both Direct3D and OpenGL from day one. Remember all the Unreal Engine based games from 1999-2003 or so?

I disagree, if they can get close with minimal overhead, that save a lot of programming hours porting an engine from one 3D API to another. While it might be slower, it's a step in the right direction. It also create a framework for how to port DX applications to OpenGL since there is a library that does the translation for you.

The real question we have to ask (before we start bashing it,) is what kind of performance will we see out of this compatibility layer. Until our questions are answered we shouldn't judge it. Additionally, it's a lot more than double work to port a game from one API to another. Consider for a moment how many bugs and incompatibilities you come across between the two APIs then remember that they need to thoroughly test it once they even get it working.

This makes sense for games that were coded for DX and only DX to run in OpenGL. I don't see the problem with that. It's giving you an option where you wouldn't otherwise have one.

Don't like it? Make your own damn 3d engine. :p

Sure, Direct3D also had "minimal" overhead which now turned into a massive one...

RejZoRSure, Direct3D also had "minimal" overhead which now turned into a massive one...

Please start citing your sources if you're going to make claims like that. DX interfaces with hardware-level APIs so overhead will be minimal anyways in most cases, so I'm reluctant to believe that. Any API call is going to have some overhead and take some time to call it, but taking time to call an API doesn't mean that it has a lot of overhead. Some API calls are just simply costly.

As far as I understand from a short look in the source, this wrapper is used at compile-time.
This means that there is no overhead for redirected calls at runtime, but you need the source of a game to make use of it.
I'd still expect a slight performance hit compared to native OGl though. Some API-calls are normally avoided/used less in OGl due to bad performance and others from DX which are normally eluded with some effort would perform well when their OGl counterpart is used.

olstyleAs far as I understand from a short look in the source, this wrapper is used at compile-time.
This means that there is no overhead for redirected calls at runtime, but you need the source of a game to make use of it.
I'd still expect a slight performance hit compared to native OGl though. Some API-calls are normally avoided/used less in OGl due to bad performance and others from DX which are normally eluded with some effort would perform well when their OGl counterpart is used.

I saw translated calls and not a whole lot of pre-prossessor directives. I don't think it's done at compile time, but it doesn't do much more than add another reference frame to the call stack as most of those translated calls are pretty simple (direct one-to-one translations with one line of code,), but any extra calls take time to do and I'm sure there are things that DX does faster than OpenGL and things that OpenGL does faster than DX.

Even a stupid compiler will inline most of those calls and get rid of the added reference, but they are not strictly preprocessor, that's right.