Can I relay on my Cocos2d-x based application game to always use OpenGL (and OpenGL ES in mobile platforms)? Since this library allows inline OpenGL calls within it's code I want to know if I can use them without worrying about portability. Is there anything else Cocos2d-x uses for rendering? Like DirectX in Windows Desktop / Phone and maybe a software renderer on devices without graphic cards?
Cocos2d-x uses OpenGL on all platforms.
Keep in mind that on Desktop OSs depending on OS, GPU and drivers the OpenGL renderer may fall back to software rendering for certain features, or not support them at all (drawing glitches or errors).
Moreover OpenGL for desktop computers and OpenGL ES for mobile devices are not fully compatible both in API and supported features.
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.
In other word, is there any GPU that does not support OpenGL, and instead support other graphic rendering libraries like DirectX, OpenCl.
"GPU support of OpenGL" is not uniquely defined. It takes much more than hardware to make OpenGL work. Notably, OS driver infrastructure, and driver itself.
Therefore, it is possible to have a GPU that is capable of all OpenGL features, but have no OpenGL software implementation (either not exists, not installed etc.). Ex.: because of marketing reasons Microsoft does not support OpenGL on XBox. Same thing with Windows: often there is only basic OpenGL available with default Windows graphics drivers. It could be easily fixed by installing vendor driver, but most users don't bother.
And other way around, there are GPUs that are not capable of running some or all of the OpenGL features in hardware. Those features could be implemented in software. Ex.: First Android OS versions had software implementations of OpenGL ES in case phone didn't have dedicated GPU or if GPU was not fully capable of OpenGL ES.
Also, there are platforms that do not support OpenGL or DirectX and use their own APIs. Ex.: Sony use custom API for their Playstations.
At this day and age, no, you'll not find a GPU that won't support some version of OpenGL, with the possible exception of some super-specialised chips - but those won't support DirectX either.
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 looking for the best native library that is similar to three.js in its structure and simplicity but is also extensible enough to support glsl shaders.
Requirements:
Open Source or very well documented for possible extension/enhancement
Allows commercial derivatives/use
Can either be wrapped in a physics library or easily paired with one.
Fast enough to support modern game graphics.
OpenGL or Mantle based. (I don't want to be stuck with windows.)
Windows support
Supports a system similar to three.js local/world coordinate system.
Raycasting support for doing collision detection.
Huge Bonus:
Supports Linux and OSX as well as windows.
I am looking for the closest match to Three.js as possible that is written in C++ similar to three.cpp but has completed functionality and is less beta/alpha status.
Have you tried Magnum ?
http://mosra.cz/blog/download-magnum.php
Supported platforms
Graphics APIs:
OpenGL 2.1 through 4.4, core profile functionality and modern extensions
OpenGL ES 2.0, 3.0 and extensions to match desktop OpenGL functionality
WebGL 1.0 and extensions to match desktop OpenGL functionality
Platforms:
Linux and embedded Linux (natively using GLX/EGL and Xlib or through GLUT or SDL2 toolkit)
Windows (through GLUT or SDL2 toolkit)
OS X (through SDL2 toolkit, thanks to Miguel Martin)
Google Chrome (through Native Client, both newlib and glibc toolchains are supported)
HTML5/JavaScript (through Emscripten)
Threejs actually does support glsl shaders. You can use THREE.ShaderMaterial class to create your own shader then pass your vertexShader and fragmentShader to it.
Another option is to program directly in WebGL. ThreeJS is built on top of WebGL. The only reason why I decided to use ThreeJS was to avoid writing glsl shaders since WebGL doesn't have materials and forces you to write your own glsl shaders, so if that's what you want you could go directly to WebGL. WebGL is more low level than Threejs.
If you don't like javascript, then you could use JogAmp's Ardor3D which is in Java. It's a 3D scenegraph renderer just like Threejs but in Java.
All of the above options have super fast game quality rendering performance.
I have a PC with a good CPU but slow GPU (integrated graphics card). I have noticed that some commercial games work much better using their software renderers instead of OpenGL or DirectX. I am making a Java app that will use JOGL/LWJGL to access OpenGL. To enable a software rendering option, should I look at a pure-Java software renderer, or native software-only OpenGL implementations?
You can install Mesa 3D. This OSS project supplies an OpenGL driver for Windows which is based on a software renderer.