Quiz But the Windows pc is both DirectX and OpenGL. If you want your pc game to port to MAC, Linux, ps4 and wiiU it makes more sense to use an open GL engine than a direct x one as direct x is win pc and xbox only.
Also you'd expect the ps4 to trounce the xbone in sales because 1 its cheaper, 2 its faster and 3 it has less hassles with getting mmos & mods on it.
OpenGL ES 1.0 added an official 3D graphics API to the Android[9] and Symbian[10] operating systems, as well as by QNX[11] It is also supported by the PlayStation 3 as one of its official graphics APIs[12] (the other one being low level libgcm library) with Nvidia's Cg in lieu of GLSL.[13] The PlayStation 3 also includes several features of the 2.0 version of OpenGL ES.
PS4 will also use OpenGL, although I'm not sure about which standard.
Nintendo also uses a non-standard version of OpenGL, depending on which devices your talking about.
If PlayStation 4 is going to use OpenGL, then the most sensible thing to do is to go for the full OpenGL 4.4 and add some custom extensions to it to expose things that GCN is good at. AMD might well want to bring those extensions to their Windows and Linux drivers, too, though they probably wouldn't be used much on PC apart from straight console ports.
The problem with OpenGL extensions in a PC environment is that you can quickly get a big mess of different hardware supporting different combinations of extensions. The point of core versions of OpenGL is that they provide a convenient way to say, tons of hardware will support every single thing in this version. Otherwise, you could end up with a ton of code paths to try to support all sorts of different combinations of supported features.
But that's not such a problem with PS4. If your code only needs to run on a PS4, and the PS4 does support that particular extension, then you can use it without having to worry about compatibility. That might make things harder if you're planning on porting the game to PC, but it's not a problem for the PS4 version.
Still, regardless of whether you're using OpenGL, DirectX, or anything else, hardware compatibility is an issue on PC. If you only make one version, then you have a choice of a lowest common denominator that avoids using any features not available on really old hardware, or else making it so that a lot of hardware flatly cannot run your game at all.
Having multiple versions is a pain to support, though, and it gets worse as you add more versions. OpenGL tries to help with this somewhat by making each version a superset of the previous one, apart from when OpenGL 3.1 deprecated some really ancient stuff like dithering and color-index mode.
Fortunately, hardware conveniently comes in groups, so you can have one version to target a bunch of hardware at once. There's the OpenGL 4.x era (Radeon HD 5000 and later, GeForce 400 and later), the OpenGL 3.3 era (Radeon HD 2000-4000 series, GeForce 8000-300 series), and then some older stuff. Unfortunately, this is complicated some by Apple refusing to support anything after OpenGL 3.2, and Intel supporting versions rather erratically.
If you make a game with a recent version of OpenGL and want to have another version for older hardware, the older version basically has to give up any features not present in the older version of OpenGL. How hard it is to strip out a feature varies wildly by the feature. If you want to strip out stereoscopic 3D support, for example, all you do is not offer it as an option to the end-user. If you want to strip out tessellation, it's doable but something of a pain, as you tessellate your vertex data to some fixed degree in software before the video card sees it, kill the old tessellation control shaders and vertex shaders, turn your tessellation evaluation shaders into vertex shaders with some relatively minor header changes, and that's likely enough.
But if you make extensive use of geometry shaders and want a version for older versions of OpenGL that lack geometry shaders, have fun with that. It's going to be ugly, and you probably either have to hard disable a ton of graphical features or decide not to have the legacy version. The desire to have compatibility back to DirectX 9.0c is likely why games typically don't seem to do that much with geometry shaders, even though there's a ton of cool stuff that you can do with them and it's not that hard to do. I'm hoping that the PS4 and Xbox One will convince a lot of developers that compatibility back only to the DirectX 10/OpenGL 3 era is good enough for PC games.
As for OpenGL ES, that's really gimpy, even the latest OpenGL ES 3.0 version. It doesn't offer geometry shaders, most likely because they want it to be suitable for hardware that lacks unified shaders. If you don't have unified shaders, then you can build pixel/fragment shaders with only 16-bit floating point precision and probably not break anything. That's fine for color data, as you're probably reading in textures with 8-bit precision per color anyway. But it would turn geometry computations into a complete nightmare.
With AMD bringing GCN to tablets already and likely soon having an ARM chip with GCN, and Nvidia bringing Kepler to tablets and phones next year, they've got unified shaders and can support the latest versions of OpenGL. I'm hoping that will lead developers to care about the full OpenGL rather than just OpenGL ES. Being able to offload a lot more work to the GPU will make it possible to do some cool things with 3D graphics in tablets and phones, but it will probably take years before hardware support for it is widespread enough for developers to be willing to try it.
Originally posted by goldtoof Quiz But the Windows pc is both DirectX and OpenGL. If you want your pc game to port to MAC, Linux, ps4 and wiiU it makes more sense to use an open GL engine than a direct x one as direct x is win pc and xbox only.
Also you'd expect the ps4 to trounce the xbone in sales because 1 its cheaper, 2 its faster and 3 it has less hassles with getting mmos & mods on it.
For Mac and Linux, at least, that was my point above. But consoles are different, and you're already going to have to change some things to port a game to PC, even if it's Windows only. If you only want to port the game to Windows PCs, then you can use DirectX and it's fine. But if you want to support Mac and/or Linux in addition to Windows, then it's easier to have a single OpenGL version rather than having both OpenGL and DirectX versions, or worse, trying to get Crossover, Wine, or some such to make the DirectX version reliably work right on Mac and Linux.
This seems like the typical Microsoft monopoly-pushing. They want everyone using their product and they don't want their product to be compatible with anyone else. By doing so, they are likely trying to prevent SteamOS from taking off. What they don't realize is that SteamOS will likely be ran on dual-boot systems for the first few years to see if game developers are likely to support it. Depending on how that battle plays out, Microsoft could easily lose the PC gaming market, and their consoles will also lose support due to being difficult to port games to other consoles and PC.
Consoles slowly merging with PC hardware and software, and any move against that is like shooting yourself in the foot. Eventually, consoles and PCs will all use the same game disks and your choice of console or PC will revolve around the other features you want, like the social networks that come with consoles.
This post illustrates exactly why the general public fails miserably at running businesses.
Microsoft HAD to make this move. PERIOD. If they didnt then all the money they've invested into the gaming market, console or other wise, would be out the window. Allowing AMD to monopolize the entire console gaming industry based on mantle, effectively cutting out the entire PC gaming side of things (which is far larger than people realize) is literally the epitome of stupid.
This was a brilliant move on Microsoft's part, and i fully support them.
Oh, and BTW, this is from a self proclaimed console hater. Check my post history if you've don't believe me.
"The surest way to corrupt a youth is to instruct him to hold in higher esteem those who think alike than those who think differently."
"So long as the specific code used to implement a method is different, anyone is free under the Copyright Act to write his or her own code to carry out exactly the same function or specification of any methods used in the Java API. It does not matter that the declaration or method header lines are identical. Under the rules of Java, they must be identical to declare a method specifying the same functionality — even when the implementation is different.
When there is only one way to express an idea or function, then everyone is free to do so and no one can monopolize that expression. And, while the Android method and class names could have been different from the names of their counterparts in Java and still have worked, copyright protection never extends to names or short phrases as a matter of law.
It is true that the very same functionality could have been offered in Android without duplicating the exact command structure used in Java. This could have been done by re-arranging the various methods under different groupings among the various classes and packages (even if the same names had been used). In this sense, there were many ways to group the methods yet still duplicate the same range of functionality.
But the names are more than just names — they are symbols in a command structure wherein the commands take the form
java.package.Class.method()
Each command calls into action a pre-assigned function. The overall name tree, of course, has creative elements but it is also a precise command structure — a utilitarian and functional set of symbols, each to carry out a pre-assigned function. This command structure is a system or method of operation under Section 102(b) of the Copyright Act and, therefore, cannot becopyrighted. Duplication of the command structure is necessary for interoperability"
"It’s not that Mantle is the initial language with which developers are writing their games on each platform, as some have surmised; the point of Mantle is that it’s easy to reuse, in whole or in part, the development effort expended on the next-generation consoles when bringing the same game to life on the PC. This is because Mantle allows developers to use the same features and programming techniques they are already utilizing for next-gen game consoles. And while the initial iteration of Mantle is intended specifically for PCs, it has been designed from the beginning to be extensible to other platforms as well."
"In short, Mantle is a new and better way to bring the code developers are already writing for next-generation consoles to life on the PC. It achieves this by being similar to, and often compatible with, the code they are already writing for those platforms. The ultimate goal of Mantle is to give gamers the ultimate performance in compatible games, and doing that in such a way that developers are free to put forth whatever effort is required to ensure optimal performance for competing platforms."
The only way MS can stop something like Mantle is to not have AMD hardware in its consoles. Even not having a low level API (which would be crippling for the console performance) wouldn't prevent game developers from having a "mantle library" in their game engine that could access the hardware,
Currently playing: GW2 Going cardboard starter kit: Ticket to ride, Pandemic, Carcassonne, Dominion, 7 Wonders
Originally posted by Gaia_Hunter The only way MS can stop something like Mantle is to not have AMD hardware in its consoles. Even not having a low level API (which would be crippling for the console performance) wouldn't prevent game developers from having a "mantle library" in their game engine that could access the hardware,
You do have a point - there isn't anything stopping a 3rd party from implementing a Mantle API on XBox. Microsoft just said they wouldn't support it. If AMD chose to release the libraries on their own accord (or some other 3rd party, such as Unity or Unreal), there isn't much Microsoft could do -- aside from (maliciously) break those libraries with every XBox update (which sounds really evil, but has totally been done in the past) - since Microsoft doesn't support Mantle, they would be under no obligation to ensure updates work with Mantle.
there isn't much Microsoft could do -- aside from (maliciously) break those libraries with every XBox update (which sounds really evil, but has totally been done in the past) - since Microsoft doesn't support Mantle, they would be under no obligation to ensure updates work with Mantle.
Comments
But the Windows pc is both DirectX and OpenGL. If you want your pc game to port to MAC, Linux, ps4 and wiiU it makes more sense to use an open GL engine than a direct x one as direct x is win pc and xbox only.
Also you'd expect the ps4 to trounce the xbone in sales because 1 its cheaper, 2 its faster and 3 it has less hassles with getting mmos & mods on it.
If PlayStation 4 is going to use OpenGL, then the most sensible thing to do is to go for the full OpenGL 4.4 and add some custom extensions to it to expose things that GCN is good at. AMD might well want to bring those extensions to their Windows and Linux drivers, too, though they probably wouldn't be used much on PC apart from straight console ports.
The problem with OpenGL extensions in a PC environment is that you can quickly get a big mess of different hardware supporting different combinations of extensions. The point of core versions of OpenGL is that they provide a convenient way to say, tons of hardware will support every single thing in this version. Otherwise, you could end up with a ton of code paths to try to support all sorts of different combinations of supported features.
But that's not such a problem with PS4. If your code only needs to run on a PS4, and the PS4 does support that particular extension, then you can use it without having to worry about compatibility. That might make things harder if you're planning on porting the game to PC, but it's not a problem for the PS4 version.
Still, regardless of whether you're using OpenGL, DirectX, or anything else, hardware compatibility is an issue on PC. If you only make one version, then you have a choice of a lowest common denominator that avoids using any features not available on really old hardware, or else making it so that a lot of hardware flatly cannot run your game at all.
Having multiple versions is a pain to support, though, and it gets worse as you add more versions. OpenGL tries to help with this somewhat by making each version a superset of the previous one, apart from when OpenGL 3.1 deprecated some really ancient stuff like dithering and color-index mode.
Fortunately, hardware conveniently comes in groups, so you can have one version to target a bunch of hardware at once. There's the OpenGL 4.x era (Radeon HD 5000 and later, GeForce 400 and later), the OpenGL 3.3 era (Radeon HD 2000-4000 series, GeForce 8000-300 series), and then some older stuff. Unfortunately, this is complicated some by Apple refusing to support anything after OpenGL 3.2, and Intel supporting versions rather erratically.
If you make a game with a recent version of OpenGL and want to have another version for older hardware, the older version basically has to give up any features not present in the older version of OpenGL. How hard it is to strip out a feature varies wildly by the feature. If you want to strip out stereoscopic 3D support, for example, all you do is not offer it as an option to the end-user. If you want to strip out tessellation, it's doable but something of a pain, as you tessellate your vertex data to some fixed degree in software before the video card sees it, kill the old tessellation control shaders and vertex shaders, turn your tessellation evaluation shaders into vertex shaders with some relatively minor header changes, and that's likely enough.
But if you make extensive use of geometry shaders and want a version for older versions of OpenGL that lack geometry shaders, have fun with that. It's going to be ugly, and you probably either have to hard disable a ton of graphical features or decide not to have the legacy version. The desire to have compatibility back to DirectX 9.0c is likely why games typically don't seem to do that much with geometry shaders, even though there's a ton of cool stuff that you can do with them and it's not that hard to do. I'm hoping that the PS4 and Xbox One will convince a lot of developers that compatibility back only to the DirectX 10/OpenGL 3 era is good enough for PC games.
As for OpenGL ES, that's really gimpy, even the latest OpenGL ES 3.0 version. It doesn't offer geometry shaders, most likely because they want it to be suitable for hardware that lacks unified shaders. If you don't have unified shaders, then you can build pixel/fragment shaders with only 16-bit floating point precision and probably not break anything. That's fine for color data, as you're probably reading in textures with 8-bit precision per color anyway. But it would turn geometry computations into a complete nightmare.
With AMD bringing GCN to tablets already and likely soon having an ARM chip with GCN, and Nvidia bringing Kepler to tablets and phones next year, they've got unified shaders and can support the latest versions of OpenGL. I'm hoping that will lead developers to care about the full OpenGL rather than just OpenGL ES. Being able to offload a lot more work to the GPU will make it possible to do some cool things with 3D graphics in tablets and phones, but it will probably take years before hardware support for it is widespread enough for developers to be willing to try it.
For Mac and Linux, at least, that was my point above. But consoles are different, and you're already going to have to change some things to port a game to PC, even if it's Windows only. If you only want to port the game to Windows PCs, then you can use DirectX and it's fine. But if you want to support Mac and/or Linux in addition to Windows, then it's easier to have a single OpenGL version rather than having both OpenGL and DirectX versions, or worse, trying to get Crossover, Wine, or some such to make the DirectX version reliably work right on Mac and Linux.
This post illustrates exactly why the general public fails miserably at running businesses.
Microsoft HAD to make this move. PERIOD. If they didnt then all the money they've invested into the gaming market, console or other wise, would be out the window. Allowing AMD to monopolize the entire console gaming industry based on mantle, effectively cutting out the entire PC gaming side of things (which is far larger than people realize) is literally the epitome of stupid.
This was a brilliant move on Microsoft's part, and i fully support them.
Oh, and BTW, this is from a self proclaimed console hater. Check my post history if you've don't believe me.
"The surest way to corrupt a youth is to instruct him to hold in higher esteem those who think alike than those who think differently."
- Friedrich Nietzsche
Again, it doesn't matter that MS doesn't support Mantle.
Mantle is a low level API to interface with AMD hardware. Consoles use low level APi constructs to access the hardware in the consoles.
That AMD hardware is the based on the same architecture for both consoles and PC.
APIs can't copyrighted in the US as it was ruled in the court in Oracle vs Google regarding the Java API. (http://www.wired.com/wiredenterprise/wp-content/uploads/2012/05/Judge-Alsup-Ruling-on-Copyrightability-of-APIs.pdf)
"So long as the specific code used to implement a method is different, anyone is free under the Copyright Act to write his or her own code to carry out exactly the same function or specification of any methods used in the Java API. It does not matter that the declaration or method header lines are identical. Under the rules of Java, they must be identical to declare a method specifying the same functionality — even when the implementation is different.
When there is only one way to express an idea or function, then everyone is free to do so and no one can monopolize that expression. And, while the Android method and class names could have been different from the names of their counterparts in Java and still have worked, copyright protection never extends to names or short phrases as a matter of law.
It is true that the very same functionality could have been offered in Android without duplicating the exact command structure used in Java. This could have been done by re-arranging the various methods under different groupings among the various classes and packages (even if the same names had been used). In this sense, there were many ways to group the methods yet still duplicate the same range of functionality.
But the names are more than just names — they are symbols in a command structure wherein the commands take the form
java.package.Class.method()
Each command calls into action a pre-assigned function. The overall name tree, of course, has creative elements but it is also a precise command structure — a utilitarian and functional set of symbols, each to carry out a pre-assigned function. This command structure is a system or method of operation under Section 102(b) of the Copyright Act and, therefore, cannot becopyrighted. Duplication of the command structure is necessary for interoperability"
From http://community.amd.com/community/amd-blogs/amd-gaming/blog/2013/10/17/the-four-core-principles-of-amd-s-mantle .
"It’s not that Mantle is the initial language with which developers are writing their games on each platform, as some have surmised; the point of Mantle is that it’s easy to reuse, in whole or in part, the development effort expended on the next-generation consoles when bringing the same game to life on the PC. This is because Mantle allows developers to use the same features and programming techniques they are already utilizing for next-gen game consoles. And while the initial iteration of Mantle is intended specifically for PCs, it has been designed from the beginning to be extensible to other platforms as well."
"In short, Mantle is a new and better way to bring the code developers are already writing for next-generation consoles to life on the PC. It achieves this by being similar to, and often compatible with, the code they are already writing for those platforms. The ultimate goal of Mantle is to give gamers the ultimate performance in compatible games, and doing that in such a way that developers are free to put forth whatever effort is required to ensure optimal performance for competing platforms."
The only way MS can stop something like Mantle is to not have AMD hardware in its consoles. Even not having a low level API (which would be crippling for the console performance) wouldn't prevent game developers from having a "mantle library" in their game engine that could access the hardware,
Currently playing: GW2
Going cardboard starter kit: Ticket to ride, Pandemic, Carcassonne, Dominion, 7 Wonders
You do have a point - there isn't anything stopping a 3rd party from implementing a Mantle API on XBox. Microsoft just said they wouldn't support it. If AMD chose to release the libraries on their own accord (or some other 3rd party, such as Unity or Unreal), there isn't much Microsoft could do -- aside from (maliciously) break those libraries with every XBox update (which sounds really evil, but has totally been done in the past) - since Microsoft doesn't support Mantle, they would be under no obligation to ensure updates work with Mantle.
DOS ain't done until Lotus won't run?