Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Valve Open Sources Their DirectX To OpenGL Layer

Unknown Lamer posted about 6 months ago | from the please-port-mame-hlsl-shader-to-sdlmame-kthx dept.

Open Source 130

jones_supa writes "A bit surprisingly, Valve Software has uploaded their Direct3D to OpenGL translation layer onto GitHub as open source. It is provided as-is and with no support, under the MIT license allowing you to do pretty much anything with it. Taken directly from the DOTA2 source tree, the translation layer supports limited subset of D3D 9.0c, bytecode-level HLSL to GLSL translator, and some SM3 support. It will require some tinkering to get it to compile, and there is some hardcoded Source-specific stuff included. The project might bring some value to developers who are planning to port their product from Windows to Linux."

cancel ×

130 comments

Sorry! There are no comments related to the filter you selected.

Any replies will be immediately upmodded! (0, Troll)

Anonymous Coward | about 6 months ago | (#46453705)

If you want an instant Karma boost, reply to this post!

Re:Any replies will be immediately upmodded! (5, Interesting)

Anonymous Coward | about 6 months ago | (#46454035)

Boobs

Re:Any replies will be immediately upmodded! (-1, Flamebait)

Anonymous Coward | about 6 months ago | (#46454179)

You'd think people with rep would know the difference between up/down(vote), no wonder this site gets spammed to death.

You want boobs, you got boobs (-1, Offtopic)

Anonymous Coward | about 6 months ago | (#46454487)

Awesome boobs [primecurves.com]

Re:You want boobs, you got boobs (-1)

Anonymous Coward | about 6 months ago | (#46455205)

Yes, those were some awesome asian boobs

yayy flappy birds coming to linux (0)

Anonymous Coward | about 6 months ago | (#46453709)

yayy flappy birds coming to linux

Re:yayy flappy birds coming to linux (0)

Anonymous Coward | about 6 months ago | (#46453875)

Flappy Bird wasn't made using DirectX.

Re:yayy flappy birds coming to linux (0)

kthreadd (1558445) | about 6 months ago | (#46453979)

yayy flappy birds coming to linux

Technically it was, Android/Linux as opposed to GNU/Linux.

Re:yayy flappy birds coming to linux (1)

ArcadeMan (2766669) | about 6 months ago | (#46455549)

In the meantime you can always play FlappyCoin [flappycoin.info] instead.

Winelib (5, Interesting)

Wootery (1087023) | about 6 months ago | (#46453723)

Could this be of use to the Winelib [winehq.org] project?

(As the name implies, it's the compile-time analogue of Wine.)

Re:Winelib (4, Interesting)

Anonymous Coward | about 6 months ago | (#46453743)

Possibly, I havn't looked at the source yet. But the readme says its a subset of the DirectX 9.0c features, making it not only obsolete, but incomplete. Fortunately, its open source so a bit of wrangling could make it swallow dx10 and 11

Re:Winelib (0)

Anonymous Coward | about 6 months ago | (#46453795)

didn't someone already make a dx10 for xp implementation?

Re:Winelib (1)

jones_supa (887896) | about 6 months ago | (#46453911)

There was one in development, but he didn't finish the project.

Re:Winelib (-1)

Anonymous Coward | about 6 months ago | (#46453873)

heh, for some reason I read that as "swallow a dildo". That would be more pleasurable than swallowing dx10 and 11!

Re:Winelib (0)

Anonymous Coward | about 6 months ago | (#46455157)

Hahaha disregard that, I suck cocks.

{to mods - this is a joke in response to the parent post}

Re:Winelib (5, Insightful)

LoRdTAW (99712) | about 6 months ago | (#46454527)

Hold on, The subset of DX9.0c is probably the Xbox360 native API: http://en.wikipedia.org/wiki/Comparison_of_OpenGL_and_Direct3D#Gaming [wikipedia.org]

The original Xbox supported Direct3D 8.1 as its native API while the Xbox 360 supports a modified version of Direct3D 9.0c as its native API.

This could be useful for studios looking to port Xbox360 titles to the Steam Box platform. It makes sense as there are a lot of titles that could see a sort of resurrection on Steam and bring in some more money. It is also possibly the same D3D API subset used for Windows Phone 8.

Re:Winelib (1)

bhcompy (1877290) | about 6 months ago | (#46454631)

Or, it's just for the Source engine, because that was/is DX9

Re:Winelib (3, Insightful)

Anonymous Coward | about 6 months ago | (#46453963)

Could this be of use to the Winelib [winehq.org] project?

(As the name implies, it's the compile-time analogue of Wine.)

Probably not. The wine guys tend to be more or less anti toward anything that they didn't write and thus can assert that it's not infringement on Microsoft's source code. Accepting that much code from Valve sounds very risky for them.

Re:Winelib (4, Insightful)

JDG1980 (2438906) | about 6 months ago | (#46454337)

Probably not. The wine guys tend to be more or less anti toward anything that they didn't write and thus can assert that it's not infringement on Microsoft's source code. Accepting that much code from Valve sounds very risky for them.

Valve isn't some fly-by-night operation. They almost certainly have more exposure to legal liability than the Wine project would.

Re:Winelib (0)

Anonymous Coward | about 6 months ago | (#46455867)

I think they are mainly anti anything reactos, mostly because there was some question that the source might have been contaminated with leaked windows code.

They have to have a strict firewall, which includes no developers that have seen the leaked windows source.

Actually... (0)

Anonymous Coward | about 6 months ago | (#46458949)

ReactOS has the same provision and spent a year doing nothing more than ensuring no possibly contaminated code was in the codebase.

Honestly this whole thing could be solved by making copyright expire when a product was not longer in 'primary commercial circulation'. If somebody has given up on a product as worth selling, that should also end their (formerly limited) monopoly on the redistribution of the copyrighted material.

Re:Winelib (0)

Anonymous Coward | about 6 months ago | (#46456629)

Valve also has a lot more money to hire lawyers. Volunteers can't afford that.

Re:Winelib (4, Informative)

Richard_at_work (517087) | about 6 months ago | (#46454469)

Odd considering their (Wines) last copyright cockup was entirely due to an internal contributor committing decompiles of Microsoft binaries as contributed code...

Re:Winelib (0)

Anonymous Coward | about 6 months ago | (#46455279)

Where do you think this policy came from?

References? (1)

Anonymous Coward | about 6 months ago | (#46456387)

Could you point to some links stating such a cockup happened?

Re:Winelib (1)

BetterThanCaesar (625636) | about 6 months ago | (#46457197)

Odd considering their (Wines) last copyright cockup was entirely due to an internal contributor committing decompiles of Microsoft binaries as contributed code...

The word you are looking for is the opposite of odd.

Unsurprising.

Re:WInelib (0)

Anonymous Coward | about 6 months ago | (#46455481)

It will probably have greater application in other developers porting their games to Linux -- it's not likely that Wine will use it because most of the functionality is redundant between the two.

Re:Winelib (0)

Anonymous Coward | about 6 months ago | (#46457291)

Wine already has a pretty decent DX9 coverage. I've even fixed a bug in it.

Re:Winelib (1)

Kuberz (3568651) | about 6 months ago | (#46458525)

Could this be the year of Linux Desktop?

On the road to replacing DirectX (5, Insightful)

Anonymous Coward | about 6 months ago | (#46453757)

With a big company (in terms of money) like Valve pushing OpenGL there is a real chance DirectX will face serious and permanent competition. We will finally have a serious alternative to the suffocating model of forcing a new operating system down peoples throat through software. It worked great with the browser, now lets hope Valve can make it happen for games.

Re:On the road to replacing DirectX (4, Insightful)

CastrTroy (595695) | about 6 months ago | (#46453899)

I think that only worked so well for the browser because MS let IE stagnate for so long. I don't think they are doing the same with DirectX. DirectX continues to evolve and stay up to date. It's one thing to convince the non-programmer, general computer user to keep using mediocre tools, it's a whole other story to try and get developers to do the same.

Re:On the road to replacing DirectX (3, Insightful)

Anonymous Coward | about 6 months ago | (#46454111)

In light of the fact that OpenGL's more portable to more platforms, it's not as hard a sell as you'd think. Esp. for more casual games. Want to target iOS and Android? You'll be doing OpenGL ES 2.x. The same game will target PS3, PS4, OSX, Linux, and Steam/SteamBox with only a few modifications.

Re:On the road to replacing DirectX (0)

Anonymous Coward | about 6 months ago | (#46454203)

DirectX is a lot more than just what OpenGL provides though. Swapping to OpenGL provides significantly less functionality than DirectX as DirectX isn't just a graphics API. So in the hope of picking up the slim pickings on other systems they have to do more work and hence more expense. For many games/developers the benefits simply aren't there, especially if they are already familiar with DirectX.

Re:On the road to replacing DirectX (1)

Z80a (971949) | about 6 months ago | (#46454335)

SDL is quite a match for DirectX.

Re:On the road to replacing DirectX (5, Interesting)

JDG1980 (2438906) | about 6 months ago | (#46454365)

Swapping to OpenGL provides significantly less functionality than DirectX as DirectX isn't just a graphics API.

Pretty much all aspects of DirectX except for Direct3D have been deprecated by Microsoft. They still work, but aren't recommended for new code, and have been superseded by other APIs.

Re:On the road to replacing DirectX (0)

Anonymous Coward | about 6 months ago | (#46454493)

That's because your trying to compare OpenGL with all of Direct X, which isn't even a proper comparison to make. OpenGL is an alternative to Direct3D (the graphics component of Direct X). The Kronos Group also offers: OpenAL, OpenCL, Collada and several other APIs that not only replace the functionality of Direct X but offer far more functionality as a whole.

I honestly don't remember ever seeing a single project, be it one I worked on or not, which used the entirety of Direct X. At most they tend to use Direct3D, the math stuff and Direct Input. The latter two have faded out over the past several years as there are far better open source alternatives. For awhile XACT was kind of popular for audio, but it has some major limitation (or design flaws) that make it a pretty poor choice for anything more than simple games.

Re:On the road to replacing DirectX (0, Insightful)

Anonymous Coward | about 6 months ago | (#46454681)

They don't offer more functionality, though. DirectX 11 eats OpenCL; XAudio2 eats OpenAL; Collada isn't even an API, it's a file format. Kronos offer more-or-less equivalent functionality to Windows, except there's no common math library, the OpenGL/OpenCL APIs are inherently lower-performance than the Direct3D 11 API, and OpenGL continues to lag behind DirectX 11 on features like surface format aliasing and memory-mapped resources. Also, none of the Kronos APIs handle video mode switching or vsync events or window painting. And if you look at how OGL has evolved over the last 10 years it's obvious they're just copying D3D a generation later. Not once has OGL moved ahead of the curve. Not once. DirectX is and will continue to be the bleeding edge giving the best support for the latest hardware. It's ridiculous to claim the Kronos APIs have more functionality. And with DirectX 12 being announced in a few weeks, Kronos will be busy for a year speccing Open GL 5 to match it.

Re:On the road to replacing DirectX (1)

Anonymous Coward | about 6 months ago | (#46454987)

That would be all true if you completely ignore OpenGL extensions...

Re:On the road to replacing DirectX (0)

Anonymous Coward | about 6 months ago | (#46455041)

Also, none of the Kronos APIs handle video mode switching or vsync events or window painting.

Why would they? Those are external concerns, especially vsync.

Helpful hint: LED display devices theoretically don't need a periodic vsync. You could (in theory) draw to your alternate buffer, perform the buffer swap, which would then initiate the display redraw (basically, vsync on demand as updates are made.)

Re:On the road to replacing DirectX (2)

Jakeula (1427201) | about 6 months ago | (#46455669)

You're correct that it seems like OpenGL is playing catch up with D3D, but to assume that it will *NEVER* get ahead of the curve is quite an assumption. The Linux Kernel took years of playing catch up, and now its just as modern as anything else (as a pure kernel). If Valve is moving to OpenGL and others follow Valve, then it stands to reason that Khronos will likely be able to make strides and eventually close the gap. Right now more graphically driven things are done on Windows (gaming), so of course it has the best tools for the job. However, the tides are slowly changing, and if they change in a quality fashion, I see no reason OGL has to stay in the back seat. I say this as someone with limited experience dealing with both OpenGL and Direct3D.

Re:On the road to replacing DirectX (1)

Anonymous Coward | about 6 months ago | (#46455855)

This seems kind of moot considering that OpenGL mainly looks like it is catching up to D3D if you look at the normal standards and not the extensions. When the video card makers add a feature for D3D, they can and usually do have an OpenGL extension implementing the same feature since the hard part was making it work on the card. There is something to be said for D3D driving them to implement such features, but they also implement other features not part of D3D updates, and release them as OpenGL extensions. Often it is far easier to test new features by creating an OpenGL extension and testing before it gets included in a new version of D3D.

But in some sense, it should be no surprise that OpenGL lags behind if only looking at the main standard, and that is working as intended. The standard pulls in extensions that have been tested and shown to work consistently. There is a whole process of creating vender extension, then ARB extensions that are standardized between venders, then the new version of OpenGL pulling in ARB extensions that have been around already. Even in the early stages, many important and/or straightforward exertions are common enough to be incorporated into production code.

Re:On the road to replacing DirectX (5, Informative)

wertigon (1204486) | about 6 months ago | (#46454621)

If you're going to be nitpicky, then yes, it's SDL+OpenGL.

However, the only DirectX system still relevant in Win8.1 is Direct3D. Everything else has been removed;

DirectDraw - Repaced by Direct2D [microsoft.com]
DirectInput - Replaced by XInput [microsoft.com]
DirectSound - Replaced by XAudio2 [microsoft.com]
DirectMusic - Legacy MIDI format - also replaced by XAudio2
DirectPlay - A complete joke, replaced by Games for Windows Live and XB Live.
DirectX Media/Media Objects: Deprecated and replaced/removed by all of above

That leaves DirectWrite and Direct2D as the only relevant (and minor) DIrectX components left. So yes, DX is more than a graphics API; these days and for gaming though, the only thing being used is D3D in DX.

Re:On the road to replacing DirectX (1)

unixisc (2429386) | about 6 months ago | (#46455031)

What's the equivalent of DirectSound or XAudio2 in OpenGL? Can OpenGL be enhanced to include sound in addition to visualization, just like DirectX already is?

Re:On the road to replacing DirectX (2)

Ardyvee (2447206) | about 6 months ago | (#46455135)

You want OpenAL for audio.

Re:On the road to replacing DirectX (1)

unixisc (2429386) | about 6 months ago | (#46455211)

So does that come as a standard part within either Linux or the BSDs? And if one has it, does one still need ALSA or PulseAudio?

Re:On the road to replacing DirectX (1)

cheesybagel (670288) | about 6 months ago | (#46455363)

OpenAL can run on top of ALSA or PulseAudio.

Re:On the road to replacing DirectX (0)

Anonymous Coward | about 6 months ago | (#46456729)

It does come standard in the main Linux distros. But whether it does is largely irrelevant since it's open source and thus you can easily bundle it with your game.

Re:On the road to replacing DirectX (0)

Anonymous Coward | about 6 months ago | (#46457359)

IIRC, DirectInput isn't quite deprecated, it's just not meant to be used for keyboard/mouse or for XBox360 controllers. Keyboard and mouse are now RawInput - which isn't exactly new - XBox 360 controllers (or compatible joysticks) are XInput and "Legacy" Joysticks are DirectInput.

Re:On the road to replacing DirectX (5, Informative)

DrXym (126579) | about 6 months ago | (#46454949)

OpenGL is definitely more portable than DirectX but that's not to say it's portable with a few modifications. There are various OpenGL and OpenGL ES profiles, and while they are related they can be radically different in important ways. For example OpenGL ES 1.1 and 2.0 are totally incompatible despite what you might think - 1.1. uses a fixed function pipeline and 2.0 expects you to write shaders for basically everything. OpenGL ES 2.x is roughly but not completely a subset of OpenGL 2.1. Every version of OpenGL supports a different selection of extensions.

Aside from the differences on paper, the actual implementations can be broken, buggy or inefficient. e.g. Some older desktop drivers might not offer an ES 2.x profile, or it could be hopelessly crap.

There is no GLU / GLUT either for ES 2.x and every platform implements its own equivalent but proprietary set of APIs. So you may discover a lot of work is required to fix that. Then you may discover that one platform or language's bindings are different from another in subtle but annoying ways, e.g. there are several OpenGL ES 2.x bindings for Java and one might return a handle in an int[] array while another expects you to supply a 1-element sized IntBuffer. Annoyances which add up.

In summary, yes you can port code, and OpenGL is definitely one family of APIs that offers support across a wide selection of devices. But it's not guaranteed to be simple and probably won't be. The best bet is use a good third party library (e.g. libgdx) and let the library hide as much of the work as possible.

Re:On the road to replacing DirectX (0)

Anonymous Coward | about 6 months ago | (#46455523)

I'm not sure how different OGL profiles are any different than dealing with different DX versions. The major card manufacturers -- Nvidia, AMD -- support up to (I believe) OpenGL in their closed drivers, and the open source drivers across the board are up to OpenGL 3.3 -- and I'm not familiar with any game that uses a higher standard than 3.3.

The fact that using DX10/11 requires a certain level of hardware and a minimum version of Windows hasn't stopped games developers from developing for those APIs, so why should OpenGL compliance (or specifically, any lack thereof) stop developers from using OpenGL?

Re:On the road to replacing DirectX (1)

DrXym (126579) | about 6 months ago | (#46457207)

There's nothing to stop you picking an OpenGL profile and using that but obviously if you expect your code to be portable then you're going to have choose very carefully. And if portable includes handheld or mobile devices then the profile has to be ES 2.x or 3.x or you have to write two backends (with all the pain that goes with that). So its not all plain sailing. If you have an existing app then porting it may involve considerable effort.

Re:On the road to replacing DirectX (1)

Vlado (817879) | about 6 months ago | (#46454141)

What happened to the news/rumor that there will not be another DirectX version?

http://tech.slashdot.org/story... [slashdot.org]

Re:On the road to replacing DirectX (3, Informative)

jones_supa (887896) | about 6 months ago | (#46454189)

It was only AMD speculation (which also happened to fit nicely with their Mantle strategy). DirectX 12 is now confirmed [slashdot.org] .

Re:On the road to replacing DirectX (3, Insightful)

bloodhawk (813939) | about 6 months ago | (#46454211)

It was a garbage rumor back then that was only believed by those with a heavy anti MS bias and is even more so now given the next version has been announced.

Re:On the road to replacing DirectX (0)

Anonymous Coward | about 6 months ago | (#46455951)

There's a real big hurdle direct 3D has to get over no matter how good it happens to be.

It only runs on Microsoft platforms.

This means, for all practical intents and purposes, it doesn't exist in the very hot and very important mobile markets. (Don't kid yourself. Microsoft share of the tablet and smart phone market amounts to little more than a statistical error and developers know this)

Re:On the road to replacing DirectX (0)

Anonymous Coward | about 6 months ago | (#46453989)

Newsflash: IE still has >50% market share.

Re:On the road to replacing DirectX (2)

MBGMorden (803437) | about 6 months ago | (#46454053)

Newsflash: IE still has >50% market share.

Um, no. Depending on what site you're looking at it might go up or down, but nobody is ranking IE at over 50% anymore. W3 is actually reporting IE at around 20% these days:

http://www.w3counter.com/globa... [w3counter.com]

Re:On the road to replacing DirectX (2)

TyFoN (12980) | about 6 months ago | (#46454175)

And the reason those 20% still use it is because of company lock-in / legacy web apps.

Even my almost 70 year old mother is on Firefox without me being involved.

Re:On the road to replacing DirectX (1)

Immerman (2627577) | about 6 months ago | (#46454119)

Where are you getting your statistics? Various estimates as listed on Wikipedia show IE having at most almost 25%
Source . . . Chrome IE Firefox Safari Opera Other
StatCounter 46.60% 24.64% 20.37% 5.06% 1.33% 2.00%
W3Counter 34.1% 20.3% 18.3% 17.8% 2.7% 6.8%
Wikimedia 42.69% 18.02% 15.28% 6.06% 2.36% 15.59%

Re:On the road to replacing DirectX (0)

Anonymous Coward | about 6 months ago | (#46454345)

No no source has almost 25% the others have around 20% and 18%.

Re:On the road to replacing DirectX (1)

DrGamez (1134281) | about 6 months ago | (#46456437)

Newsflash: AC posts uninformed and incorrect statement, remains AC.

Re:On the road to replacing DirectX (2, Insightful)

Anonymous Coward | about 6 months ago | (#46454149)

Since OpenGL is the only language to run on mobile, and Mac, and Linux plus it's available on all the consoles it seems kind of crazy to target anything else if your code is expected to survive for any length of time given the decline of the Windows PC market.

Re:On the road to replacing DirectX (4, Insightful)

LoRdTAW (99712) | about 6 months ago | (#46454475)

OpenGL is pretty much used everywhere but Microsoft targeted games (Windows and Xbox). Using DirectX on Windows games allowed them to be portable between PC and the Xbox so more and more games went the D3D route to remain portable between the two.

I believe almost all CAD and 3D modelling software are OpenGL based. Android and iOS use OpenGL ES while any non Windows OS such as Linux and OSX use OpenGL for 3D graphics. With the big push to mobile and Microsoft left in the dust, OpenGL is the dominant player.

The better question is... (0)

Anonymous Coward | about 6 months ago | (#46458979)

Do you really want a company founded by a middle manager from Microsoft, who had previously kept close ties with Microsoft, becoming Microsoft v2.0 by cornering the majority of the digital distribution market, starting with, but not ending with, videogames?

Because that is where the Steam ship is headed. Next stop being an android client and then who knows.

performance? (1)

invictusvoyd (3546069) | about 6 months ago | (#46453775)

Will there be a performance hit ?

Re:performance? (1)

Xest (935314) | about 6 months ago | (#46453825)

There's bound to be some hit, but the hit will be so utterly negligible that it's not enough to care. You shouldn't let it be a concern because it's too small to matter.

Re:performance? (4, Informative)

Creepy (93888) | about 6 months ago | (#46453937)

Yeah, probably minimal, since it is bytecode level (what HLSL and GLSL compile into)

The bad - this is DX 9.0c, which is analogous to OpenGL 2.0 (with extensions - note that ATI drivers didn't support extensions at the time, so more like 2.2+ for them) and in console terms, XBox 360/PS3 tech. OTOH, OpenGL went through a major paradigm shift with OpenGL 3 and 4 that make it work more like HLSL, so I expect shader conversion is much easier. When I ported a DX10 shader to OpenGL 3 it was much easier (but much harder was porting the entire OpenGL 2 project to 3).

Re:performance? (2, Informative)

Anonymous Coward | about 6 months ago | (#46453861)

Valves presentation on the topic http://adrienb.fr/blog/wp-content/uploads/2013/04/PortingSourceToLinux.pdf states better performance using togl for their games (togl starts at slide 18, performance is mentioned on 23).

Makes sense (2)

mwfischer (1919758) | about 6 months ago | (#46453785)

Valve makes money with Steam.

Valve has hammered out a useful content delivery platform for Linux and OS X.

Valve makes it easier to translate DX to OGL.

Collect profit... eventually.

Re:Makes sense (0)

Anonymous Coward | about 6 months ago | (#46453829)

"the translation layer supports limited subset of D3D 9.0c"

So a limited subset of games could be ported with this. Very useful

Re:Makes sense (4, Insightful)

RaceProUK (1137575) | about 6 months ago | (#46453879)

If only it was MIT-licensed so people could club together and add support for the rest of Dx9 (and 10 and 11 while they're at it)...

Re:Makes sense (-1)

Anonymous Coward | about 6 months ago | (#46453987)

Uhm...

It is provided as-is and with no support, under the MIT license allowing you to do pretty much anything with it.

Read much?

Re:Makes sense (1)

Himmy32 (650060) | about 6 months ago | (#46454021)

That's the joke.

Re:Makes sense (0)

Anonymous Coward | about 6 months ago | (#46454153)

If only there was some way to humorously point out an obvious beneficial detail of an article so readers could move their palm rapidly onto their foreheads and utter "of course".

Re:Makes sense (1)

Cley Faye (1123605) | about 6 months ago | (#46454171)

If only there was some word to indicate that one missed a glaringly obvious joke in a parent post, like the sound of a gush of wind or something.

Re:Makes sense (0)

Anonymous Coward | about 6 months ago | (#46454439)

gush of wind

sploosh?

Re:Makes sense (4, Informative)

Carewolf (581105) | about 6 months ago | (#46453881)

A limited subset, as in every PC game that still supports WinXP. Which is practically all of them.

Re:Makes sense (0)

Anonymous Coward | about 6 months ago | (#46454009)

Quite a few newer games do no longer support DirectX 9, it is only relevant for Windows XP which even on steam only has a share of 5% .

Re:Makes sense (0)

Anonymous Coward | about 6 months ago | (#46458527)

Not quite. For Valve, a limited subset probably means the base DirectX 9.0c library. DirectX 9.0c is not just one monolithic library: it is a set of libraries that has had many addons and updates over time. This is why almost every game you install wants to "update/install" DirectX. It is not a matter of updating the library, it is a matter of ensuring all the different dependencies that were compiled into the game are installed on the machine and at the correct versions.

See: https://support.steampowered.com/kb_article.php?ref=9974-PAXN-6252 [steampowered.com]

yes. (1)

Anonymous Coward | about 6 months ago | (#46453901)

As far as I can tell it is.

Here is a professional grade codebase to start from for anyone who wants to complete the compatability.

Re:Makes sense (2, Informative)

Anonymous Coward | about 6 months ago | (#46453975)

The majority of games on Valve's catalogue use D3D9.0c. That could be what they're aiming for - the huge collection of DX9 games already there.

Re:Makes sense (2)

jones_supa (887896) | about 6 months ago | (#46454233)

They probably simply aimed to get the Source engine ported, which happens to be DX9-based. That there are lots of other DX9 games is a nice side effect.

Re:Makes sense (1)

BitZtream (692029) | about 6 months ago | (#46454639)

Still want to know why their 'useful' content delivery platform won't run on my case-sensitive OSX partition ... but Linux users don't seem to have that problem.

And no, I don't give a shit that I can make a case sensitive partition and play symlink hell games to get it to work. Its fucking ridiculous that it doesn't support case sensitive filesystems. /End Rant>

Re:Makes sense (1)

Threni (635302) | about 6 months ago | (#46454921)

Why? Because it affects 1 user who can work around it trivially; I imagine there are other priorities, given that there are limited resources and work has to be prioritized accordingly.

question (0)

Anonymous Coward | about 6 months ago | (#46453815)

Can someone explain why something like ToGL would be a part of Dota 2?

Re:question (0)

Anonymous Coward | about 6 months ago | (#46453865)

Because Dota 2 was created for Windows/DirectX, ToGL is used to port it to Linux/OpenGL

Re:question (0)

Anonymous Coward | about 6 months ago | (#46454015)

I think the question is why make a game in Direct3D and translate it to OpenGL rather than simply making it in OpenGL from the start and saving the effort, especially since they most likely wanted the game to be on Linux the whole time.

My guess it that they were doing a "two birds with one stone" strategy - using this project as an excuse (and test-case) for the translation layer, hoping that some devs would take this opportunity to port their DX9 games to Linux because of it, thereby improving the value of SteamOS.

Re:question (3, Insightful)

Cley Faye (1123605) | about 6 months ago | (#46454201)

My guess it that they were doing a "two birds with one stone" strategy - using this project as an excuse (and test-case) for the translation layer, hoping that some devs would take this opportunity to port their DX9 games to Linux because of it, thereby improving the value of SteamOS.

Another option is that they didn't write DOTA2 from scratch, but reused an existing engine. Which in turn was based on some previous works, and at some point Direct3D was used, and remained there the whole time.

Re:question (-1)

Anonymous Coward | about 6 months ago | (#46454281)

despite what many in the open source community like to claim, DirectX is still currently superior to OpenGL, especially if you use the newer version rather than ancient DirectX 9c. On top of that DirectX handles input controllers and sound making it a far better platform for consistent rapid development in exchange for lack of cross platform support and a closed source model. Most likely the DOTA team were already skilled in DirectX and sacrificing release dates in order to meet ideological goals of moving away from MS, while nice, makes really poor business sense.

Re:question (1)

petermgreen (876956) | about 6 months ago | (#46454423)

I think the question is why make a game in Direct3D and translate it to OpenGL rather than simply making it in OpenGL from the start

Because game developers don't start from scratch with each game, they either buy an engine in or they create and engine and use it for multiple games (and possiblly sell it to third party game developers too). Of course they tweak that engine with each new game but only rarely do they perform a major rewrite.

The initial release game for the source engine was half life 2 and the initial release platforms for that game was windows, closely followed by xbox (original). It's pretty obvious why they would have built their engine on directx.

Re:question (2)

Creepy (93888) | about 6 months ago | (#46454121)

It runs on OSX and Linux, neither of which have native DirectX support because Microsoft keeps their graphics technology under tight wraps. All implementations of it not shipped by Microsoft need to be reverse engineered from the API. OpenGL is licensed to hardware manufacturers (which is how development is paid for) and accessing the API is free for software developers.

Re:question (3, Interesting)

Anonymous Coward | about 6 months ago | (#46454983)

Speaking as someone who's written a native D3D 9.0c implementation from scratch (on the PS3), implementing it is not the issue. I probably implemented the exact same subset as Valve did - only the shader-driven part, no fixed-function emulation - and it took maybe 4 weeks total (160 hrs). My implementation was 10x faster (seriously) than the D3D 9.0c implementation on X360. (That's CPU usage of the API; obviously the GPU ran at comparable rates. The X360 port team on the project I was on hit frame rate just issuing too many D3D calls, while the PS3 port was running the exact same D3D calls using 10% of the CPU. It correctly handled locking, sync, cache flushes, etc. so it gave the exact same guarantees as the real D3D; I guess Microsoft's 9.0c still had a lot of Windows cruft in it's X360 incarnation. Probably doing too many kernel transitions - I had zero except at the end of the frame.)

The reason I never turned this into a product and sold it was because to get the D3D 9.0c headers you have to accept an EULA that says it's all confidential, and my dog simply isn't in that fight. Valve's dog is in that fight now, but they have a much bigger dog than I do. Using their code as a starting point I could in theory release my code now (only to PS3 developers though because of Sony's NDAs ... and that's no click-through EULA, that's a cast iron contract between my company and Sony). A bit late though, who the hell needs D3D 9.0c on PS3 in 2014? Direct3D 12 on PS4, now that might be worth considering ...

Re: question (0)

Anonymous Coward | about 6 months ago | (#46455277)

i did super awsome stuff back in the day but i can't and/or won't show you.

SM3 support (0)

edxwelch (600979) | about 6 months ago | (#46453845)

Spiderman 3 was an awful movie. I wonder why they choose to support that?

Going the other way like Microsoft does... (5, Informative)

tlambert (566799) | about 6 months ago | (#46454823)

Going the other way like Microsoft does is more interesting.

One of the biggest issues with OpenGL is that you can get shaders that won't run in bounded time. You can see this with a number of games in Flash, or natively in OpenGL, when run on a Mac. If the shader doesn't exit, it eats a channel, and there are a limited number of channels, and once they are gone, the renderer, which is also used for the desktop, basically crashes. There are nice system log messages from the video driver about it, but besically everything ends up restarted, which is pretty useless.

FWIW: this accounts for the majority of system instabilities in the card specific portions of both Mac OS X and Linux render pipelines.

DirectX doesn't allow things to run in unbounded time in its OpenGL to DirectX translator; instead, it loop unrolls shaders, and if it can't do that such that they run linearly, and therefore in bounded time, it omits them from the render. So you might not get distance blurring, haze effects, fog effects, rain effect, and so on, but at least the thing doesn't crash, and if the person porting the code to the Windows platform cares about these things, they fix the code so that it'll run using DirectX. Usually, this reduced the perceived "quality" of the final render, but you get at least a crude version of your effect back.

The other thing DirectX does is, in the video driver, keep a reserve channel for sending commands to the video hardware; the common reason for this is in-band signaling to comply with the DirectX 9 requirement that the video hardware be capable of being reset, without rebooting the system, such that a video card hang doesn't necessitate a reboot.

While a DirectX to OpenGL translation layer is a nifty idea (I lobbied very hard for a FreeBSD emulator for Linux, rather than a Linux emulator for FreeBSD so that developers would target FreeBSD rather than Linux as their development platform), I don't think that as long as the OpenGL shader looping issues don't also get addressed at the translation layer that translating from DirectX to OpenGL will be in anyway superior to translating from OpenGL to DirectX.

So basically, it's nice they released this, but the code is of little practical use in the real world, since there are features that will get lost in translation.

Re:Going the other way like Microsoft does... (1)

Megane (129182) | about 6 months ago | (#46455099)

Very interesting. I think that explains why Minecraft can hose OS X so thoroughly. The current version of Minecraft can reliably crash the graphics on OS X 10.6 when you simply try to change the window size. (The official "workaround, won't fix" is to upgrade to OS X 10.9!)

Re:Going the other way like Microsoft does... (2)

Windwraith (932426) | about 6 months ago | (#46458657)

Strange, I use and code plenty of games using shaders like that, and I run KDE4 in Linux, in both GL composite and regular X11 mode, and have never experienced any crash like you describe. Is it because I use Nvidia drivers or something, or maybe because I happened to have had the luck to only play games that do it right, and had the luck to never code any shaders triggering that? Seems rather unlikely, but I am genuinely curious here.

Tools (1)

The Cat (19816) | about 6 months ago | (#46455997)

At the very least this will make it possible for some excellent RAD tools to make their way to Linux much faster. Among them Gamemaker, Stencyl, Unity and Construct.

Then there will be the inevitable FOSS equivalents, which will spinoff their own series of games, making development faster and less buggy on both PCs and mobile devices. The Linux to Android migrations in particular are going to be really exciting.

The next chapter is going to be amazing for Linux.

Keyword: D3D 9.0c (1)

Dunge (922521) | about 6 months ago | (#46456201)

DirectX10 / 11 is still better than OpenGL
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>