libGDX is based on OpenGL (ES), but iOS 12 has officially deprecated OpenGL. There will be tons of job to do if libGDX wants to evolve. For commercial engines, they have started long to adapt to the OpenGL deprecation. Any plan from libGDX team? Or have they already started the works?
Initially they were reluctant to support Vulkan. Recently they are looking into both of Metal and Vulkan support by using ANGLE as backend.
Metal/Vulkan Support [Planned]
We are well aware that Apple has deprecated OpenGL (ES) on iOS and macOS. Thus, we are looking into Metal/Vulkan support in the near future. Projects like ANGLE look very promising for this.
See their roadmap.
Currently, ANGLE's Metal support is still in progress. Once it has done, the libGDX developer team will work on. I hope so.
Already an issue for the same on LibGDX issue tracker.
Discussed possibilities :
Replace OPENGL/Adding support of metal
All rendering code in libGDX is based on the GLES API. Adding Metal would
require a complete rewrite of all rendering code, which would essentially
mean an almost rewrite of libGDX.
Software implementation of OpenGL on top of Metal (writing a wrapper)
MoltenGL is an implementation of the OpenGL ES 2.0 API that runs on Apple's Metal graphics framework.
Angle, Vulkan is in progress(may be in future it support metal.)
Related
According to Apple, OpenGL is no longer supported. However, it appears v4.1 of OpenGL was supported on many devices as of July 28, 2020. I have a 2020 Macbook Pro 16" model, which does not show up on the list provided above. While I am sure some form of compatibility exists on my device, I am unsure how I can develop with OpenGL when modern versions are deprecated.
I wish to be developing between my Macbook Pro running Big Sur and my Windows desktop. For this reason, I obviously do not wish to focus on a device-specific library such as Direct3D or Metal. Is it possible to work with newer versions of OpenGL (such as OpenGL 4.6) despite support not being directly provided by Apple? I've heard AMD video cards do not play well with OpenGL, so what options am I left with?
Built-in OpenGL on macOS works a little bit different from other platforms like Windows or Linux. On Windows, system-provided opengl32.dll doesn't actually implement OpenGL but is rather a proxy-library dynamically loading functions from a driver provided by a graphics card vendor. Graphics card vendors provide drivers independently from Microsoft and OpenGL capabilities can be implemented without Microsoft approval.
In contrast, macOS is much more closed system, where all graphic drivers are part of the system and cannot be (normally) updated without updating system itself. Apple holds the full control over OpenGL functionality in system and doesn't give graphics card vendors any way to deliver users more up-to-date OpenGL features (even when their hardware supports them on other systems).
This is quite unpleasant situation for a developer of multi-platform software, as Apple steadily pushes to their platform-specific APIs like Metal as the only choice, which implies a stronger vendor-lock and/or a more expensive development.
An alternative to using platform-specific APIs directly could be using a proxy-library implementing a multi-platform API on top of platform-specific API. So far, currently known options:
Apple's OpenGL implementation over Metal.
Unfortunately, it has stuck on OpenGL 4.1, and there is no reason to expect the version will ever grow up; the library could be even removed in some newer macOS.
You may already notice that information provided by a system library on modern macOS versions mentions Metal, so that it is already a wrapper over other graphics API (although Apple may cheat by accessing some internals).
MoltenVK, an open-source Vulkan 1.1 implementation over Metal.
This is not an OpenGL library, but Vulkan is another multi-platform graphics API and some references tells that MoltenVK in current state is solid enough for using in real projects, and Vulkan 1.1 is expected to give more features than outdated OpenGL 4.1 (though, I cannot confirm this personally, just my expectations).
MoltenGL, a closed-source OpenGL ES 2.0 implementation over Metal.
As current implementation is limited to OpenGL ES 2.0 (e.g. much lower than Apple's built-in OpenGL / OpenGL ES libraries), it looks quite useless...
Google ANGLE, an open-source OpenGL ES implementation over other APIs.
So far, ANGLE implements only OpenGL ES 2.0 over Metal, and OpenGL ES 3.1 (3.2 in progress) over Vulkan. So that with more layers like MoltenVK it could theoretically give more, if layers will not blow up ;). However, even OpenGL ES 3.2 doesn't look good enough compared to OpenGL 4.1. There is also MetalANGLE - an ANGLE library fork adding iOS support and some extra features.
Zink, an open-source OpenGL implementation over Vulkan.
Zink already implements OpenGL 4.6 on Linux (supported OpenGL version depends on exposed Vulkan features and extensions).
There is a work-in-progress making this Mesa Gallium driver working on top of MoltenVK on macOS.
To me, it looks that sticking to OpenGL 4.1 (provided by Apple) for a while is quite a good option in case if your application may afford losing some features requiring higher version of OpenGL. Although Apple has deprecated OpenGL in SDK, so far it looks non-realistic that it will be actually removed in nearest future within newer macOS updates; even Apple M1 GPU received OpenGL 4.1 support on macOS Big Sur. Don't know if Apple has some strategy black-listing applications using deprecated APIs from AppStore market (e.g. system will support OpenGL, but you will not be able publishing application on AppStore), but this might become an issue in some future. Alternative OpenGL 4.6 implementations (on top of Metal or on top of Vulkan-on-top-of-Metal) might come in some distant future.
Relying on Vulkan-on-top-of-Metal implementations might be most provisional choice, but it will certainly require more efforts to develop a graphics engine on top of Vulkan instead of OpenGL. Cannot comment, though, how current MoltenVK implementation is comparable to native Vulkan implementations on Windows for the same graphics hardware (by features/performance/limitations). Of course, using some existing graphics engine already implemented on top of several graphics APIs (Vulkan/Metal/Direct3D/OpenGL/OpenGL ES) will also take this maintenance burden from you, but this is out of scope of initial question.
#gkv311's answer is quite comprehensive. I'll add the following thoughts (full disclosure, I am the lead dev on the MoltenVK and MoltenGL projects):
IMHO, the Vulkan eco-system is your best bet for future-proofing game dev across the largest number of platforms. Here is a good summary of API layering options, based on that approach, allowing options for running OpenGL or DX over Vulkan, and/or Vulkan over Metal, DX, OpenGL, etc.
Some of these layering options can be stacked. For instance, Zink and DXVK can run on top of MoltenVK, providing OpenGL-over-Vulkan-over-Metal and DX-over-Vulkan-over-Metal functionality.
As far as Vulkan goes, MoltenVK has good performance, and good industry traction, being used by a number of AAA games ported from Windows origins, or running on top of Wine. If anyone has any questions, or wants to query some of those game developers, I suggest asking a question in the MoltenVK Discussions area.
MetalANGLE has emerged as another open-source option for OpenGL ES.
Is it possible to use Libgdx for a desktop development only and access newer versions of Opengl from Libgdx abstraction? I mean, if you want to develop mobile apps you will have to use a some verison of Opengl ES, which does not support lot of things like classic Opengl does (e.g. drawing wireframes, etc.).
Lets say I don't want to use Opengl ES but normal Opengl, version 4+ in these days, and fully use its features for oa desktop development. Does Libgdx have support for this?
On the desktop, libGDX is built on top of LWJGL, which at of the time of this answer supports up to OpenGL version 4.5.
So if you're using libGDX on the desktop, then you can simply access the LWJGL calls directly. This will break your build for mobile or web deployment though.
I am going to buy a book on OpenGL, but I have a few questions as to what I should be learning.
I am torn between dedicating myself to learn OpenGL 1.x or OpenGL 2.0, because OpenGL ES 2.0 only exists on 3G and beyond, and if I were to develop an app and place it on the app store, I would want everyone with an iphone capable of utilizing the app.
Also, I want to experiment with desktop OpenGL.
So, my question is as follows:
simply put, what should I be learning? If I learn Desktop OpenGL, would this be easily transferable to OpenGL ES? Like if I knew OpenGL in c/c++, would I also know OpenGL ES, what major differences are there?
Also, would you recommend I learn both 1.x and 2.0, for the specific reason I stated previously, that I would want all iphone owners capable of utilizing my app, not just 3G and beyond?
Lastly, are there any books you would recommend? I really enjoy the style of this tutorial. It's very easy to follow, shows a lot of code, and explains every line of code carefully.
I faced the same question myself, and my decision was to go with OpenGL ES 2.0. Firstly because the great majority of iOS devices in use today can run it (iPhone 3GS or better). Secondly because the future of OpenGL is shaders because they offer so much more flexibility than the fixed pipeline of ES 1.
That said, I will add that using shaders is NOT easy. It takes a lot more effort to set everything up in ES 2 than it does in ES 1. Many more things can go wrong, with many more times that you'll be looking at your program creating nothing but a blank screen leaving you scratching your head and wondering why.
Once you get the basics, though, ES 2 isn't really all that bad. It's just a pretty steep learning curve.
As for the desktop vs ES question, I would recommend learning ES. It's a very nice & functional subset of OpenGL, and will allow you to write programs that run on many more platforms. Using full OpenGL might get you into trouble if you want to port your code to ES, since there are aspects of it that don't translate.
To get you started with OpenGL ES 2, I highly recommend this tutorial and this book.
OpenGL ES 1.1 uses much of the old deprecated functionality, whereas OpenGL ES 2.0 uses the modern shader-only vertex array/buffer approach, being more future ready. If you learn desktop GL, you won't have too much difficulties using OpenGL ES, as they are quite similar.
If you really want to use the old-style OpenGL ES 1.1, then I suggest you to learn desktop OpenGL 2.0 (best done with the "OpenGL Programming Guide"/"Red Book") which will teach you the old immediate API along with the modern vertex array/buffer functionality and (in conjunction with the book "OpenGL Shading Language"/"Orange Book") also the use of programmable shaders. So this way you will be ready to use old-style (1/(2)) and modern ((2)/3/4) desktop GL along with OpenGL ES 1.1 and 2.0.
But if you want to start directly with the new and modern way of programming OpenGL (which might be advisable, although the old-style is a valuable experience), then I would rather suggest to use the newest edition of the "OpenGL SuperBible", which will teach you modern-style ((2)/3/4) desktop OpenGL without the old deprecated functionality. But then much OpenGL ES 1.1 code won't be of much use to you (although you will surely understand its principles). Although I really appreciate my knowledge of the fixed-function old-style OpenGL, I would rather suggest beginners to start with modern OpenGL right-away, even if it might be a bit harder to learn for a beginner, as this is the way to do hardware-accelerated real-time graphics today (and tomorrow).
But what really matters is, that in contrast to learning the API by mind you should understand the underlying principles and the principles of 3d graphics in general. Then you won't have much difficulty switching to other APIs, like Direct3D, anyway.
I have to start a 3D-Project for mobile platforms. First of all I would like to outline the main aim - skeletal animation. As for the solution I was thinking of OpenGL ES and C++. So the questions are:
Is OpenGL ES robust enough to handle skeletal animation (including those skinning shaders)
Is OpenGL ES supported widely across mobile platforms, and what are the most famous ones? (for instance, is iPad supported?)
Is this possible anyway, I mean will I have enough computation power?
Is it worth using XNA math library, because of its SIMD optimization (though I'm really unsure that SIMD is supported on mobile platforms, but who knows...).
Is it good to use C++ for this? If yes, then which compiler should I choose for development and testing? Moreover, I have no clue what compilers are used for mobile platforms?
As you might have got it - I've never programmed for mobile platforms yet. Therefore, some general recommendations are welcome.
Yes, OpenGL ES 2.0 can handle vertex skinning for skeletal animations quite well. OpenGL ES 1.1 used a fixed function pipeline, without shaders, so it's harder in the older API to do this, but 2.0 adds support for shaders. OpenGL ES 2.0 is present on all shipping iOS devices (the iPhone 3G S and newer supports it, including both iPads), as well as almost all Android devices (I could only find a couple of very low end handsets that didn't). Windows Phone 7 doesn't appear to support OpenGL ES, but I believe BlackBerry does.
If you're interested in this, I highly recommend reading Philip Rideout's book "iPhone 3D Programming". While it has "iPhone" in the title, he uses generic C++ for almost all of the code in the book, so it should translate to other platforms well and should be easy for you to understand. He even has a section in the "Optimizing" chapter with code for performing vertex skinning on OpenGL ES 2.0 and even 1.1. You can grab the sample code for the book here, including a demonstration of this skinning.
C++ is supported on iOS through Objective-C++, where you could set up the platform-specific UI elements in Objective-C and then do all your backend and rendering logic in C++. Again, Philip does this in his book, and you can see in his source code example applications how he structures this. The people at Imagination Technologies have also set up some platform-agnostic scaffolding in their PowerVR SDK, which some people have used for quickly getting their 3-D rendering up and running on mobile devices. Also in that SDK are some great documents about moving from OpenGL to OpenGL ES, as well as performing various effects on these GPUs.
I have heard of some people getting slightly better performance for small vertex sets by performing transformations on-CPU (on iOS this can be done using the Accelerate framework), but I'd imagine that vertex shaders would be much faster for larger geometry. The PowerVR GPUs that I've worked with in mobile devices are much more powerful than you'd think, particularly the new one that ships in the iPad 2.
You'll need to use the Xcode IDE, with either its GCC or LLVM compiler to target iOS devices, but I believe Android has a few more options in that regard.
In short:
Yes, of course. Why not?
Yes, I suppose. What else? DirectX definitely not.
Yes, I suppose. But depends on what else you want to do.
No, at least not just because of SIMD, as I suppose it is not much supported on mobile platforms, at least the SIMD instructions XNA is optimized for.
Yes, why not? I think the i...s mostly use Objective-C, but there should be compilers for C++, too. Just ask google, as I also don't have any mobile experience.
I want to start with my webGL project and minimal require is my graphic card support openGL 2.0.
Problem exist because i have intel laptop with integrated intel 965 graphic media accelerator and driver is up to date and it support openGL 1.5.
Is there any solution how to update my graphic carf to support 2.0? Is this possible?
Okay. just stay patient actually because ANGLE is coming. It seems to me that your hardware is able to run directX 9 and ANGLE is a project from google to allow webgl support from directX. But as the others say, you can't upgrade opengl drivers just like that. Or you could try MESA in the firefox build.
For more information, see Learningwebgl.com.
Sadly no. With a little more effort you can still develop against opengl 2.0 but you'll need to use another machine (or just buy a better graphics card) to test anything 2.0 specific (pixel shading for instance).
Ok, that's not entirely true. You could download the mesa library and compile it for win32 and get some of the opengl 2.0 functionality emulated in a software renderer but it would be very slow.
It's possible that updating drivers might help some, but probably won't make that jump. Otherwise, you could use something like Mesa3D, which does the rendering in software. It can be slow, but does support up through OpenGL 2.1 (including shaders), if memory serves.
If there's no other way, you could try http://www.mesa3d.org/ . I haven't followed this project for quite some time, but apparently they currently provide OpenGL 2.1 software rendering.
I just updated drivers my HP 6710b with Mobile Intel 965 Express Chipset -- and now WebGL is working in Firefox 4 RC1!
I put instructions on this site.
It is not pretty but it works!
angleproject is your best bet. Check out which exact 965 card you have from here (search for 'intel gma' in wikipedia), which also lists the OpenGL support version for these cards. It might take a couple of months though before you can use angleproject to accelerate your WebGL application.
I have a slightly newer 4500MHD, and I have the same problem. WebGL works on Firefox 3.7a4, but fails in the later versions a5 and a6. I had to use the latest drivers from Intel which claim to support OpenGL 2.0. The Microsoft drivers don't ship with OpenGL support.
I have reported a issue in the Firefox https://bugzilla.mozilla.org/show_bug.cgi?id=570474. It looks like support for Intel cards might be fixed by the time the releases are in beta.