As for d3d, microsoft are busy "conquering" the mobile market and their 3d API is not top priority for them now.
By the way have you noticed that the opengl functions are no longer marked as "obsolete" in their documentation, but instead are labeled "desktop only" - same as the entire win32 api, e.g. CreateWindow or CreateFile
This is risky, I don't see this happening, there are already giants in the market. Better they support OpenGL.As for d3d, microsoft are busy "conquering" the mobile market and their 3d API is not top priority for them now.
I don't see much wisdom in their actions too. The world is changing and they apparently don't know what to do. The billions they have don't seem to be of much help either.This is risky, I don't see this happening, there are already giants in the market. Better they support OpenGL.
But i don't think they deserve us to mourn for them any more than how much they would mourn for a hypothetical opengl demise
If I were MS I would take a reasonable path of success at least in the very changing very competitive mobile market, and do support the standard, which is OpenGL.
Unlike the desktop market where there's almost no competition (or minimal), and where consumers of the graphics have no choice, the mobile market on the other hand is completely the opposite. There are already several platforms that are very competitive and very well established. All use the same standard for graphics! Therefore, why would I choose a different approach with yet to be released platform that I'm not sure about its success???
Remember, consumers in the mobile market cannot be forced. They always have a better alternative.
You're looking at it from the perspective of getting existing mobile developers to port their applications. That's not where Microsoft is coming from.
Microsoft wants to make existing desktop developers port their applications to WinRT. And desktop developers made their peace with D3D long ago. Also, GL ES lacks many features of desktop GL 3.x that make D3D interop much easier: ARB_fragment_coord_conventions, ARB_vertex_array_bgra, and so forth.
So, as a desktop developer with an existing D3D-11 codebase, you could take the hard road of porting to GL ES, or you could take the much simpler roads of just using what you have now.
We don't know yet. If you ask Microsoft, you don't use OpenCL on win32 either. Only time will tell.Originally Posted by Alfonse Reinheart
Not to mention that there is no telling if that WinRT thing will be used by anyone at all, no matter how Microsoft would like the things to be. We will see.
If you remember initially there was no OpenGL on vista. Microsoft were quite bold and arrogant at the time. And what happened? Eventually OpenGL WAS supported on vista. And vista itself was a failure, which cooled their arrogance quite a bit.
Except that it's already being used by many people. So yeah.Not to mention that there is no telling if that WinRT thing will be used by anyone at all
Yes, but they weren't also removing Win32. They are now with Windows on ARM. There's a difference between them deciding not to take out a small bit of already existing functionality and them removing an entire API that just so happens to include that small bit of functionality (ie: OpenGL). The former is them wanting to ditch GL, the latter is them wanting to ditch the thing WGL relies on.If you remember initially there was no OpenGL on vista. And what happened? Eventually OpenGL WAS supported on vista.
Even moreso because Windows on ARM requires, at the very least, a full recompile due to being on ARM CPUs. So it's not like we're talking about backwards compatibility with existing executable (as was the case with Vista).
Microsoft wants a clean start with Windows on ARM. Maybe they'll add some way to create an OpenGL ES context at some point in the future, and maybe they won't. But if you want to believe that the entire Win32 API will magically manifest itself on Windows on ARM, I can't stop you.
I wouldn't hold my breath though.
Linux would love to fail like Vista...And vista itself was a failure
It was only a failure in relation to WinXP and Win7.
As for portage: smartphones are essentially two categories now really: iOS and Android. The former, unless the most ancient of iPhone, is OpenGL ES2 + Apple extensions and the latter is freaking anything. The former is write mostly only C/C++/Objective-C/Objective-C++ the latter mostly write in Java... you can talk of Android NDK to avoid Java, but it is not very practical as the compile gets targetted for a set of CPU's. Even ignoring the Compiled vs Java thing on Android, GLES2 implementations on Android are all over the place it terms of bugs and what-not... coding workarounds for desktop is small potatoes compared to Android (there are LOTS of very different GPU's and lots of driver revisions for each)... my point is that a code base for any platform is no fun at all to move to Android and hope that it works enough most of the time.
I admit that MS has big courage and/or insanity of not supporting OpenGL ES2 on their mobile platform since that is what folks on mobile are used to.... and that MS is really the distant 3rd by such a HUGE margin... On the other hand, as someone that works with OpenGL ES2 everyday, I can say that I am quite irritated pissed about OpenGL ES2... I am not just talking feature X that is in GL3 or GL4 (as that is a hardware issue too) but the the interface (I've complained of it before: image specification, _API_ limitations associated to shaders, and a few other missing points in the API). I am hoping that the next version of GLES (called Halti or something like that) will sort out the.. issues.
Here is for hoping that at SIGGRAPH 2012
- next version of GL is out with the spec "rewrite"
- GLES3 announced and released
I hope they add uniform buffers to GLES3, its about time to get rid of the old woody uniforms that are per-program-object state
This is what I find.. amazing and scary:
Tegra Wayne is GL4.1 part for embedded to be shipping is Q3 2012
Insanity.
Posting Permissions
