Windows and portablility don't really go together, unfortunately. It's funny how the most widely used OS is the one that's the least-compatible with what other OSes consider to be "standards".
wrote:It's funny how the most widely used OS is the one that's the least-compatible with what other OSes consider to be "standards".
Because it doesn't have to be.
wrote:Windows and portablility don't really go together, unfortunately. It's funny how the most widely used OS is the one that's the least-compatible with what other OSes consider to be "standards".
Actually, Microsoft is better than anyone else I've seen at maintaining backwards compatibility, mainly because they have to keep their corporate customers happy. They have compatibility modes, Application Compatibility Toolkit, and even "Windows XP mode" (a stripped down Virtual PC install with an embedded copy of Windows XP, which is basically accessed via Remote Desktop) in higher-tier versions of Windows 7. You can still run a large number of 32-bit Win9x apps from almost two decades ago, which is pretty crazy.
Apple, on the other hand, makes significant compatibility sacrifices with each major MacOSX version release, apparently figuring that their customers will (or have already) gleefully toss out their old stuff and pay over again for new shiny replacements. Since they market to zealous end-users much more than skittish corporations, they don't feel as constrained into preserving backwards compatibility.
Linux doesn't escape the compatibility issue realm, either, as many different people are continuously working to evolve it, and people may not always take backwards compatibility into account. It helps that a high proportion of software is open-source, but sometimes library APIs change in a way that breaks compatibility with even the source code of an older application.
Honestly, I can think of only 3 noteworthy compatibility losses without trivial workarounds that happened with Vista and/or 64-bit Windows that affect people wanting to play old Windows games:
wrote:Honestly, I can think of only 3 noteworthy compatibility losses without trivial workarounds that happened with Vista and/or 64-bit Windows that affect people wanting to play old Windows games:
- Loss of support for 16-bit applications on 64-bit systems (in my experience this is mostly an issue with 16-bit installers for 32-bit Win9x games).
That's not really Microsoft's fault but AMD's when they designed the AMD64/x64 architecture. Of course MS could have used virtualization to support 16-bit applications (which is exactly how XP mode is able to run those).
wrote:wrote:Honestly, I can think of only 3 noteworthy compatibility losses without trivial workarounds that happened with Vista and/or 64-bit Windows that affect people wanting to play old Windows games:
- Loss of support for 16-bit applications on 64-bit systems (in my experience this is mostly an issue with 16-bit installers for 32-bit Win9x games).
That's not really Microsoft's fault but AMD's when they designed the AMD64/x64 architecture. Of course MS could have used virtualization to support 16-bit applications (which is exactly how XP mode is able to run those).
Microsoft created a whole DOS emulator (NTVDM) for 32-bit Windows NT/2K/XP. It can't be that much harder to create a 16-bit emulation layer (for Win9x apps if not DOS ones).
Ironically, I think Wine is able to run 16-bit Windows apps on 64-bit Linux.
wrote:Windows and portablility don't really go together, unfortunately. It's funny how the most widely used OS is the one that's the least-compatible with what other OSes consider to be "standards".
Or... it's funny how these other OSes seem to ignore the biggest standards in the OS-world.
Even John Carmack has said that for Linux gaming to take off, it would be best to invest in Wine-like technologies, rather than trying to change the world to adopt the immature, inferior standards of the Linux world.
wrote:wrote:Windows and portablility don't really go together, unfortunately. It's funny how the most widely used OS is the one that's the least-compatible with what other OSes consider to be "standards".
Or... it's funny how these other OSes seem to ignore the biggest standards in the OS-world.
Even John Carmack has said that for Linux gaming to take off, it would be best to invest in Wine-like technologies, rather than trying to change the world to adopt the immature, inferior standards of the Linux world.
Except that would create a catch-22 that discourages people from trying to mature those Linux standards.
SteamOS has been a great boon to Linux gaming, as it has incentivized a lot of key players to mature their technologies that support Linux gaming.
I booted my gaming laptop to Linux over 3 months ago and haven't booted back to Windows yet. There are tons of games in my Steam library with Linux support, and a lot of old DOS games to run in DOSBox.
I haven't used Wine much lately because there is plenty of other stuff to do.
wrote:Except that would create a catch-22 that discourages people from trying to mature those Linux standards.
That is exactly the point. There is no need for separate Linux and Windows standards. The Windows standards are already there, and they work fine. Just make a good implementation of these on Linux and you're done.
No need to rewrite the whole game code just to support a different OS, because it refuses to support the de-facto standard APIs in PC gaming.
wrote:SteamOS has been a great boon to Linux gaming, as it has incentivized a lot of key players to mature their technologies that support Linux gaming.
Which has gotten us exactly nowhere so far. Yes, there are inferior SteamOS ports of some outdated DX9 games... who cares? (Despite Valve's claims, the Linux ports run slower than the Windows versions: http://rootgamer.com/2737/rootgamer/windows-l … ource-benchmark).
SteamOS still hasn't gotten anywhere nearer the goal of proper Linux gaming, where AAA-titles are available on Linux and work just as well as their Windows-counterparts.
Carmack is onto something.
wrote:wrote:Except that would create a catch-22 that discourages people from trying to mature those Linux standards.
That is exactly the point. There is no need for separate Linux and Windows standards. The Windows standards are already there, and they work fine. Just make a good implementation of these on Linux and you're done.
No need to rewrite the whole game code just to support a different OS, because it refuses to support the de-facto standard APIs in PC gaming.
There are some wrinkles there. A big one is that DirectX is a proprietary "standard", so you're completely dependent on the Wine team's ability to interpret and translate the DirectX API, which will never be perfect as long as Microsoft hides the internals, and may not be up to date enough for AAA titles that showcase new GPU features.
Another issue is that by depending on a compatibility layer, you sacrifice some performance - especially in Direct3D games that have to be translated on the fly to OpenGL (again, Linux could never have native DirectX support because Microsoft would forbid it). Hopefully Vulkan will be a panacea that equalizes all OSes by providing a modern cross platform graphics API.
Other than that case, I'm not even sure what Windows brings to the table that could be considered superior. Linux seems to do fine with input functionality (aside from the stupidity of some libraries not letting the desktop manager keep control of multimedia keys in full screen games), and everyone already uses cross platform sound SDKs now (OpenAL, FMOD, etc.).
Sound is actually my number one reason for being uncomfortable with Wine. Linux has adopted PulseAudio as a de facto sound standard, but Wine won't accept a mature back end for it. Users who run the official builds are therefore at the mercy of the ALSA back end, which doesn't play well with Pulse on a lot of machines in a lot of games.
wrote:There are some wrinkles there. A big one is that DirectX is a proprietary "standard", so you're completely dependent on the Wine team's ability to interpret and translate the DirectX API, which will never be perfect as long as Microsoft hides the internals, and may not be up to date enough for AAA titles that showcase new GPU features.
Actually, DirectX is a low-level binary interface to drivers. Microsoft can't really change anything about that without breaking all existing drivers and hardware, so they won't.
It isn't exactly rocket science, and the Gallium3D project already went a long way with it.
wrote:Another issue is that by depending on a compatibility layer, you sacrifice some performance - especially in Direct3D games that have to be translated on the fly to OpenGL (again, Linux could never have native DirectX support because Microsoft would forbid it). Hopefully Vulkan will be a panacea that equalizes all OSes by providing a modern cross platform graphics API.
Who says you have to depend on a compatibility layer? Again, look at Gallium3D. You can do 'native' D3D drivers for Linux too.
The whole point is getting away from OpenGL, because OpenGL is broken beyond repair. Replacing OpenGL with Vulkan isn't really a solution either, because if OpenGL doesn't have enough support, Vulkan won't either. It's the same parties involved.
wrote:Other than that case, I'm not even sure what Windows brings to the table that could be considered superior.
I take it you've never actually tried to develop graphics/multimedia stuff for Windows and Linux, or at least D3D/OGL?
The biggest problem with OpenGL is that every vendor provides their own implementation. This means that things like shader compilers and API calls aren't even 100% compatible from one vendor to the next, which makes testing and debugging a total nightmare.
D3D has a common runtime, which means that Microsoft is the only provider of the layer between application and driver. Which means that things like shader compilers and high-level API functions are shared by all vendors. Which means that stuff is guaranteed to work, regardless of what GPU and driver you use.
What's more, because Microsoft has defined these APIs and driver interfaces so tightly, there are quite robust automated validation tools (WHQL qualification) to at least ensure a minimum level of compliance to the D3D standard.
Linux stuff is completely amateurist in comparison, and their ecosystem is bound to fail, because too much is left to chance. Windows hasn't been the market leader for so long 'just because', but because it's actually a very compatible and robust ecosystem.
wrote:wrote:Windows and portablility don't really go together, unfortunately. It's funny how the most widely used OS is the one that's the least-compatible with what other OSes consider to be "standards".
Or... it's funny how these other OSes seem to ignore the biggest standards in the OS-world.
On the other hand I think it's funny how people can't see how darn compatible windows is on the other hand.
They have whole sections of the OS still there only for this.
And I wouldn't know personally if binaries compiled 20 years ago for the first linux versions would still work today.
wrote:Which has gotten us exactly nowhere so far. Yes, there are inferior SteamOS ports of some outdated DX9 games... who cares? (Despite Valve's claims, the Linux ports run slower than the Windows versions: http://rootgamer.com/2737/rootgamer/windows-l … ource-benchmark).
SteamOS still hasn't gotten anywhere nearer the goal of proper Linux gaming, where AAA-titles are available on Linux and work just as well as their Windows-counterparts.
Carmack is onto something.
https://www.reddit.com/r/pcgaming/comments/3k … _dota_2_reborn/
Arma 3, Batman, Bioshock, Borderlands, Civilization, Company of Heroes, Dirt Showdown, Dying Light, Empire Total War, Metro, Shadow of Mordor, Spec Ops: The Line, The Witcher, XCOM.
I believe more AAA games have been released for linux in the last 6 months than in the others 23 years and half combined.
If you consider newer Cryengine, Source, UE, Unity versions all natively support linux..
You see that the situation is way different than in 2011, when Carmack become full of the problems that since the 90s affected the platform.
wrote:wrote:There are some wrinkles there. A big one is that DirectX is a proprietary "standard", so you're completely dependent on the Wine team's ability to interpret and translate the DirectX API, which will never be perfect as long as Microsoft hides the internals, and may not be up to date enough for AAA titles that showcase new GPU features.
Actually, DirectX is a low-level binary interface to drivers. Microsoft can't really change anything about that without breaking all existing drivers and hardware, so they won't.
DX12 is a low level binary interface.
But every DX until now never went any really low. And indeed you always had the driver doing a lot of work.
Loosing compatibility is way easier than you can imagine
wrote:wrote:Another issue is that by depending on a compatibility layer, you sacrifice some performance - especially in Direct3D games that have to be translated on the fly to OpenGL (again, Linux could never have native DirectX support because Microsoft would forbid it). Hopefully Vulkan will be a panacea that equalizes all OSes by providing a modern cross platform graphics API.
Replacing OpenGL with Vulkan isn't really a solution either, because if OpenGL doesn't have enough support, Vulkan won't either. It's the same parties involved.
There's some pretty toxic rhetoric in this sentence.
When problem has ever been parties involved?
wrote:I take it you've never actually tried to develop graphics/multimedia stuff for Windows and Linux, or at least D3D/OGL? The bigge […]
wrote:Other than that case, I'm not even sure what Windows brings to the table that could be considered superior.
I take it you've never actually tried to develop graphics/multimedia stuff for Windows and Linux, or at least D3D/OGL?
The biggest problem with OpenGL is that every vendor provides their own implementation. This means that things like shader compilers and API calls aren't even 100% compatible from one vendor to the next, which makes testing and debugging a total nightmare.
D3D has a common runtime, which means that Microsoft is the only provider of the layer between application and driver. Which means that things like shader compilers and high-level API functions are shared by all vendors. Which means that stuff is guaranteed to work, regardless of what GPU and driver you use.
What's more, because Microsoft has defined these APIs and driver interfaces so tightly, there are quite robust automated validation tools (WHQL qualification) to at least ensure a minimum level of compliance to the D3D standard.Linux stuff is completely amateurist in comparison, and their ecosystem is bound to fail, because too much is left to chance. Windows hasn't been the market leader for so long 'just because', but because it's actually a very compatible and robust ecosystem.
WHQL is about stability tbh (and that's why it can potentially applies to every driver).
And the big switch happened between the late 90s and early 00s (and not to mention the whole Longs Peak issue).. but I guess many words have been already spent on the matter
Anyway, from what I can see in pcsx2, OGL is way more flexible at the moment.
pcgamingwiki.com
wrote:I believe more AAA games have been released for linux in the last 6 months than in the others 23 years and half combined.
Still it's not a whole lot compared to what's being released for Windows 😀
wrote:If you consider newer Cryengine, Source, UE, Unity versions all natively support linux..
Some of these had native Linux versions for many years, but even games that use these engines would rarely actually release a Linux version.
wrote:DX12 is a low level binary interface.
But every DX until now never went any really low. And indeed you always had the driver doing a lot of work.
Clearly you have no idea what I'm talking about. You must be one of those people who knows some things about Linux/OpenGL and then generalizes them across all OSes and APIs.
OpenGL is generally implemented in a monolithic way: the driver implements both the API and the actual hardware control.
DirectX is not like that.
There are two levels:
1) The DirectX runtime libraries, which implement the APIs for the application side.
2) The driver interfaces (this is what I was referring to).
In the case of D3D, there is a thing known as DDI: https://msdn.microsoft.com/en-us/librar ... s.85).aspx
The drivers only implement this part, which is a 'stripped down' version of the D3D API. The D3D runtimes, provided by Microsoft, translate the application API calls to DDI calls.
This means that the application API is completely consistent, because your application is always talking to the same runtime, regardless of what drivers you have installed. A lot of things are already handled by the runtime, such as shader compilation, validation of API parameters, high-level resource management etc.
This means that a lot of issues present in OpenGL are not present in D3D at all. A D3D driver simply doesn't have to do everything.
It has been this way since the very first version of DirectX, so I have no idea why you mention DX12 specifically. But it clearly shows your lack of clues.
wrote:There's some pretty toxic rhetoric in this sentence.
When problem has ever been parties involved?
How about always?
The problem with OpenGL is that all parties involved in gaming (Microsoft, nVidia, AMD, all game developers) focus entirely on Windows/D3D, and mostly ignore OpenGL. Which means that OpenGL drivers are underdeveloped, the API never reaches a decent level of maturity, and there generally is no interest in changing this.
I don't see how this would be different for Vulkan.
There was no reason for the involved parties to ever move to OpenGL, let alone Linux. Why would Vulkan be any different? Like OpenGL, it is still just a poor substitute for Direct3D.
wrote:WHQL is about stability tbh (and that's why it can potentially applies to every driver).
Except that there are specific WHQL tests for various types of drivers, where the display driver tests actually validate basic rendering operations and image quality as well (a well-known anecdote is about geometry instancing on ATi R300-series... officially this was only an SM3.0 feature. R300 was SM2.0, but had support for it. It could not be enabled by default though, because it would make the WHQL-tests fail. So you had to set a pointsprite size with a magic FOURCC to enable the feature: http://aras-p.info/texts/D3D9GPUHacks.html#inst).
See here for example: https://msdn.microsoft.com/en-us/librar ... s.85).aspx
Linux doesn't have ANYTHING like that, not even basic driver validation at all, let alone actually testing display-specific things.
wrote:Anyway, from what I can see in pcsx2, OGL is way more flexible at the moment.
Based on what?
wrote:wrote:If you consider newer Cryengine, Source, UE, Unity versions all natively support linux..
Some of these had native Linux versions for many years, but even games that use these engines would rarely actually release a Linux version
The only one to have had native Linux support for years (plural) is Source (and indeed almost every new game released with it is compatible. Perhaps not many AAA though)
UE3 always required some low level tinkering (and external ports usually made by Aspyr or Feral).
UE4 on the other hand added officially Linux as platform a year ago (but not many games have been using it)
Cryengine hasn't even crossed the 3 months birthday, while Unity still has to 100% mainline the thing.
wrote:Clearly you have no idea what I'm talking about. You must be one of those people who knows some things about Linux/OpenGL and th […]
wrote:DX12 is a low level binary interface.
But every DX until now never went any really low. And indeed you always had the driver doing a lot of work.Clearly you have no idea what I'm talking about. You must be one of those people who knows some things about Linux/OpenGL and then generalizes them across all OSes and APIs.
OpenGL is generally implemented in a monolithic way: the driver implements both the API and the actual hardware control.DirectX is not like that. There are two levels
Yes I know how it works (driver - mesa - gallium and all).
But when you are developing a game I thought the abstraction you are talking (which is what high and low level is referring to, right?) is 99% of times never low.
Then you are right I never touched these things.
wrote:wrote:There's some pretty toxic rhetoric in this sentence.
When problem has ever been parties involved?How about always?
The problem with OpenGL is that all parties involved in gaming (Microsoft, nVidia, AMD, all game developers) focus entirely on Windows/D3D, and mostly ignore OpenGL. Which means that OpenGL drivers are underdeveloped, the API never reaches a decent level of maturity, and there generally is no interest in changing this.
You seem to naively think DirectX come to "power" without any reason.
There were faults in its competitors (which I'm too noob to discuss in deep), and that's it.
wrote:I don't see how this would be different for Vulkan.
There was no reason for the involved parties to ever move to OpenGL, let alone Linux. Why would Vulkan be any different? Like OpenGL, it is still just a poor substitute for Direct3D.
Mobile.
This word alone would mean more than all the speeches regarding freedom, openness and "that makes 1% more draw calls" reasons.
And besides, I am the ignorant here, but please tell me how it would sucks. Did you already have a look to documentation?
Because I feel you are a bit too angry to just be skeptical.
wrote:wrote:Anyway, from what I can see in pcsx2, OGL is way more flexible at the moment.
Based on what?
Based on developer's words. Namely, you can't implement some exotic blending methods with DX.
And since performance aren't by no means compromised (unless you have an AMD card, but that's another matter) this alone makes me say that at the moment (not in the past) it's the best API, should you decide to write an engine from scratch (but low-overhead ones perhaps)
pcgamingwiki.com
wrote:The only one to have had native Linux support for years (plural) is Source (and indeed almost every new game released with it is compatible. Perhaps not many AAA though)
UE3 always required some low level tinkering (and external ports usually made by Aspyr or Feral).
UE4 on the other hand added officially Linux as platform a year ago (but not many games have been using it)
You didn't say 'UE4', you said 'UE', and there have been versions of UE with Linux support.
As for Source, not sure how 'native' you can really call it, seeing as it runs with the 'ToGL' wrapper: https://github.com/ValveSoftware/ToGL
Which actually is quite similar to what Carmack was talking about: just get DirectX code compiled and working on Linux.
wrote:Yes I know how it works (driver - mesa - gallium and all).
Yes, Gallium uses the same approach as DX. Problem is, most drivers, specifically the only decent ones for gamine, the binary releases from AMD and nVidia, are not Gallium-based, and therefore do not share any code, so it doesn't solve the problem of incompatibilities in the runtime.
wrote:But when you are developing a game I thought the abstraction you are talking (which is what high and low level is referring to, right?) is 99% of times never low.
Depends on who you ask.
Early D3D (before version 5) was ironically enough very similar to the 'new' command list approach in Mantle/DX12/Vulkan, and very low-level.
DX10 also was a step down in abstraction from DX6-9.
OpenGL has always been VERY highlevel, but some lowlevel access was offered by (proprietary) extensions.
It doesn't compare directly with D3D.
Anyway, I was talking about the part that is vendor-dependent, and that has nothing to do with what a game developer sees, because they only see the Microsoft runtime.
wrote:You seem to naively think DirectX come to "power" without any reason.
There were faults in its competitors (which I'm too noob to discuss in deep), and that's it.
I am far from naïve, and was active as a graphics programmer even in those days. I know quite well what happened, and I have documented some of the history on my blog, to counter history-rewriters in the OpenGL camp.
Most of them seem to be oblivious to the fact that OpenGL didn't really exist at all on consumer systems prior to the release of GLQuake (just read its readme), and that the early days of GL on Windows were actually minimal implementations known as MiniGL. True OpenGL support on consumer cards came much later.
A good blog to read is this one: http://www.alexstjohn.com/WP/2013/07/22/the-e … on-of-direct3d/
wrote:Mobile.
OpenGL ES is only a 'success' because there was nothing better. There's a reason why Apple developed Metal for iOS.
Besides, OpenGL ES is not OpenGL, and that is one of the many things that are wrong with OpenGL.
On Windows Phone, Direct3D is actually just Direct3D.
wrote:And besides, I am the ignorant here, but please tell me how it would sucks. Did you already have a look to documentation?
I'm not saying the API itself sucks, I'm saying that nobody is going to use it, which is the usual chicken-and-egg problem: no good drivers, so no games are going to target it, so no drivers are developed, and bugs and performance issues aren't solved...
Likewise, the OpenGL API isn't the biggest problem, but the lack of driver validation, lack of proper low-level standardization, and lack of actual use in the real world mean that it has always been in this immature state.
Those are things you can't tell from the documentation.
wrote:
Care to be more specific? I don't feel like reading through that whole thing to find out what exotic blend modes those would be, or even what version of DX they would be using. A lot of this stuff still uses DX9, which dates from 2002.
wrote:wrote:Care to be more specific? I don't feel like reading through that whole thing to find out what exotic blend modes those would be, or even what version of DX they would be using. A lot of this stuff still uses DX9, which dates from 2002.
According to the posts, this is under DX9 and DX11, shortened in the articles to "DX backends". Here's what the devs claim DX can't do which OpenGL can:
First article:
wrote:HDR colclip by Gregory […]
HDR colclip by Gregory
HDR (AKA High Dynamic range rendering) is useful for calculations done on a larger dynamic range, which is more accurate to be used on these scenarios since the PS2 also made use of HDR rendering. HDR allows to represent a wider range of colors so the shading algorithms have accurate color information for all the objects which is quite useful since it's needed for accurate reproduction of some lightning and bloom effects.
Note: Dynamic range is the ratio between the smallest and largest signal values.
The previously discussed accurate blending algorithm has been made a lot more efficient by replacing it with a new high dynamic range rendering based algorithm.
Let's take a look at the improvements made on the algorithm by comparing it to the GS in a scenario of blending two fragments of color 20 and 255 on a target of color 250. Notice that the new algorithm gives us the result using 2 passes, that's why it is also more CPU demanding than the old code.
Graphics Synthesizer
Formula Equation Result
(Cd+Cs) % 256 (250 + 20) % 256 14
(Cd+Cs) % 256 (14 + 255) % 256 13Older Algorithmn (Direct3D)
Formula Equation Result
for Cs < 128 : Cd + Cs (250 + 20) 255 (saturated result)
for Cs > 128 : Cd - (256 - CS ) (255 - (256-255)) 254Where the old algorithm would only work in cases of no overflow of operations, the new one will be even better since the first pass could go beyond the minimum and maximum limits. (no overflow)
New HDR based algorithm
Formula Equation Pass 1 Equation Pass 2 Result
Cd + Cs => Cd % 256 250+20 => 270 270 % 256 14
Cd + Cs => Cd % 256 14+255 (pass 1) => 269 269 % 256 13As you can see, the new HDR based algorithm produces accurate results compared to the GS in comparison to the older algorithm.
Second article (further reading here):
wrote:Now we come to something that is not a hack. Many of you who played certain games have encountered an error in the log such as “Impossible blend for D3D: (Cd - Cs) * 7 >> 7 + Cd “ and while it produces no issue in playing the game, it does mean some effects are not being rendered or are being rendered incorrectly. A good example of this is Grand Theft Auto: San Andreas. This game was practically unplayable in hardware mode due to the graphical issues arising from the impossible blend. The reason we have this issue is that some of the things that the PS2 hardware can do are not very easy or even possible to do on PC hardware. Gregory however decided to tackle the problem. He realized that there are some features in OpenGL which would allow the impossible blend to be emulated correctly and efficiently. In no time at all he had quite literally made the impossible be possible! Currently the issue is fixed only in OpenGL, however Gregory and Refraction are working on fixing it in DirectX 11 as well.
So if I read this right this was only impossible because their old D3D implementation didn't use a proper implementation, and as a result it saturated intermediate results. Quite...
It all sounds horribly clueless, and pathetic, which is no surprise, since it is being spun as pro-OpenGL. I always say that OpenGL is the Visual Basic of the graphics APIs...
wrote:So if I read this right this was only impossible because their old D3D implementation didn't use a proper implementation, and as a result it saturated intermediate results. Quite...
In other words, D3D could do it, but only with a correct implementation?
What about the impossible blend from the second article? Is that actually impossible under every version of D3D? A case of "didn't know the language well enough, botched the implementation"? Or something else?
wrote:In other words, D3D could do it, but only with a correct implementation?
Of course it can do it, why wouldn't it (this is basic shading/blending stuff, OGL and D3D run on the same hardware, there aren't any huge differences)? It only saturates if you use integers. If you use floating point datatypes, you can do any kind of HDR you want (and as you know, many games have done so, ever since DX9).
wrote:What about the impossible blend from the second article? Is that actually impossible under every version of D3D? A case of "didn't know the language well enough, botched the implementation"? Or something else?
Well no, you'll need DX9, or you may possibly get it to work well enough with DX8.1 (ps1.4), to get enough accuracy. But really, this shouldn't exactly be rocket science.
We used to fake HDR with bloom-effects even on GeForce2 cards (pre-shader stuff, DX7-class).
wrote:You didn't say 'UE4', you said 'UE', and there have been versions of UE with Linux support.
As for Source, not sure how 'native' you can really call it, seeing as it runs with the 'ToGL' wrapper: https://github.com/ValveSoftware/ToGL
Which actually is quite similar to what Carmack was talking about: just get DirectX code compiled and working on Linux.
I didn't mean native as in openGL or translated DX.
I meant native as in you can get your project to build on a given platform with a couple of clicks. After all it's what modern game engines are about, isn't it?
wrote:Anyway, I was talking about the part that is vendor-dependent, and that has nothing to do with what a game developer sees, because they only see the Microsoft runtime.
Given we were talking about games, I always assumed we had to see this from a developer prospective.
wrote:Most of them seem to be oblivious to the fact that OpenGL didn't really exist at all on consumer systems prior to the release of GLQuake (just read its readme), and that the early days of GL on Windows were actually minimal implementations known as MiniGL. True OpenGL support on consumer cards came much later.
A good blog to read is this one: http://www.alexstjohn.com/WP/2013/07/22/the-e … on-of-direct3d/
And this can be the reason indeed.
Is it the same this time? I don't think so.
wrote:OpenGL ES is only a 'success' because there was nothing better. There's a reason why Apple developed Metal for iOS. Besides, Ope […]
wrote:Mobile.
OpenGL ES is only a 'success' because there was nothing better. There's a reason why Apple developed Metal for iOS.
Besides, OpenGL ES is not OpenGL, and that is one of the many things that are wrong with OpenGL.On Windows Phone, Direct3D is actually just Direct3D.
OpenGL ES was conceived in 2003, long before any other API could ever think to run on a.. phone.
They were pretty limited back then, you know?
It's not until 3 years ago that these devices didn't reach DX11 compliance (or 4 if you count for DX9 one).
And guess what? That was even when the first WPs came out.
Not even apple, in their proprietary madness dared to dump it until they didn't see it was surpassed. And now it is, right. EDIT: and their immense retardness, they are also bringing it to desktops
But as stated plenties of times that's even what Vulkan is about. There won't be an API subset.
wrote:I'm not saying the API itself sucks, I'm saying that nobody is going to use it, which is the usual chicken-and-egg problem: no good drivers, so no games are going to target it, so no drivers are developed, and bugs and performance issues aren't solved...
Every major engine and hardware vendor already confirmed their endorsement
EDIT: and here it is
wrote:Likewise, the OpenGL API isn't the biggest problem, but the lack of driver validation, lack of proper low-level standardization, and lack of actual use in the real world mean that it has always been in this immature state.
This is exactly the chicken-and-egg problem that will be hopefully solved this fall. The egg is already there.
Let's see if this time it can become a nice pullet.
wrote:Care to be more specific? I don't feel like reading through that whole thing to find out what exotic blend modes those would be, or even what version of DX they would be using. A lot of this stuff still uses DX9, which dates from 2002.
I really can't be very precise.
Though I know texture_barrier and DSA are very useful.
More or less, modern GPUs when computing transparencies, can only account for values between 0 and 1. PS2 hardware on the other hand could go beyond this.
And no, it's not only hdr-colclip.
pcgamingwiki.com
wrote:I meant native as in you can get your project to build on a given platform with a couple of clicks. After all it's what modern game engines are about, isn't it?
The problem is not building it, but getting code that actually works properly and performs well on a wide range of systems.
wrote:Given we were talking about games, I always assumed we had to see this from a developer prospective.
What you see from a developer perspective is that because each driver has its own OpenGL implementation, there are a lot of inconsistencies. Code that may work perfectly on an nVidia driver may fail completely on AMD drivers or vice versa (this problem is not specific to Linux, because the same happens on Windows. Which is why nobody develops games for OpenGL on Windows... it simply doesn't work. Just look at the huge issues with Rage).
This is not something a developer can fix, it needs to be fixed at the OS level.
wrote:Is it the same this time? I don't think so.
I think it is. Once again, DX12 is already there, and Vulkan isn't.
wrote:They were pretty limited back then, you know?
That's no excuse. OpenGL has been around since 1992. Older versions of OpenGL ran on equally primitive hardware. There's no reason why they'd have a slightly different API and shader language targeting hardware with the same capabilities. Especially for revisions 2 and newer of OpenGL, which target shader-hardware only.
wrote:And guess what? That was even when the first WPs came out.
That's not the point (and WP supports DX9-class hardware with the DX11 API... as does the regular Windows version of course, since they're the same API).
Microsoft used to have its own mobile API as well, before WP8. But they made it into one API once the hardware was capable enough. OpenGL failed to do that.
wrote:Every major engine and hardware vendor already confirmed their endorsement
Seen that all before, with OpenGL. That says nothing.
wrote:This is exactly the chicken-and-egg problem that will be hopefully solved this fall. The egg is already there.
Let's see if this time it can become a nice pullet.
Again, seen it all before with OpenGL.
It's not going to happen. Vulkan is too late, it's going to suck, and nobody is going to care because we have Windows and DX12.
For OpenGL/Vulkan it's not enough to just exist. It needs to be better than DX12 and easier to use. That's just never going to happen, because Microsoft is just much larger and better organized. They get their APIs on the market faster, and have much better contacts with the IHVs for developing drivers and such. Microsoft also provides much better tools, such as the SDK and debugging/profiling tools.
wrote:I really can't be very precise. Though I know texture_barrier and DSA are very useful. More or less, modern GPUs when computin […]
I really can't be very precise.
Though I know texture_barrier and DSA are very useful.
More or less, modern GPUs when computing transparencies, can only account for values between 0 and 1. PS2 hardware on the other hand could go beyond this.And no, it's not only hdr-colclip.
Those are VERY new extensions to OpenGL, circa 2014. Even if you were to compare to DX11, that's an API from 2009. So the only fair comparison would be against DX12. But I doubt those emulator makers use anything newer than DX9.
Which doesn't matter, because you can still do everything a PS2 can do, and more. You just need to know what you're doing. Which often isn't the case. So many people these days using OGL and/or D3D without understanding the basics of rasterizing and shading. They have no clue about the stuff that was done with early non-programmable 3d accelerators, or even with software rendering.
Things like doing full Blinn-Phong per-pixel lighting on a GeForce2, or doing bumpmapping on cards that don't even have dot3 or embm support. Non-linear HDR bloom on cards with no floating-point support etc.
In short, they are using fixedfunction framebuffer blending, when they should be using render-to-texture (or be clever with using a higher precision framebuffer than what the PS2 has, and scale the values to avoid saturation). You can probably get it to work even with PS1.4 in DX8.1 that way. But surely on any SM2.0+ hardware.
The problem is PEBKAC.
