#Opengl 4.1 renderer not supported android
#Opengl 4.1 renderer not supported code
#Opengl 4.1 renderer not supported free

If you look at the Pong example, we can already write applications without having to care about how it is actually rendered underneath. nothing in getNativeHandle suggests that it has to be an OpenGL object ID. Of course it depends on how long the SFML community is willing to maintain 2 renderers. Considering that OpenGL is not immediately an issue the beginning of this transition can most likely wait one more year. That means supporting 2 (and a half if you count OpenGL ES) renderers for a transition period and giving up on OpenGL in ~2020, so that SFML can remain compatible with hardware from less than 5 years (the main issue being Intel GPUs).

#Opengl 4.1 renderer not supported android

Note that Metal support is related to the supported macOS/iOS version, not to a hardware, which is why I didn't put a year in macOS/iOS table cells.Īdditionally LunarG provides a SDK for using Vulkan with validation layers, for all the platforms that SFML is using except Android which looks to have its own official Vulkan SDK.Ĭonsidering the points given above, to me the best solution looks to start relying on Vulkan, while still keeping OpenGL (ES) for now. On macOS and iOS, MoltenVK (which provides an implementation of Vulkan that is based on Metal) is open source and under the Apache 2 license. The worst case is Intel integrated GPU which requires at least a Skylake (6th gen) CPU.

According to (API)#Compatibility and a few other sources here is what's supported: Switch to Vulkan for all platforms : this is maybe a bit early but looks to be the most promising solution.

#Opengl 4.1 renderer not supported free

Additionally it's not free (150$/user …) so… most likely not worth it.ģ.

#Opengl 4.1 renderer not supported code

Switch to OpenGL ES 2 on macOS through MoltenGL : this would potentially improve performance on macOS, and ease code sharing between macOS and iOS implementation, but on the other hand, OpenGL ES 2 is old (2007) and the fact that MoltenGL doesn't support more recent versions makes me think it will also die in a few years. Have a platform-specific renderer : I don't know the amount of tweaks and the burden of current support for OpenGL (ES) in SFML on all current platforms, but having a renderer per platform is very likely to be an awful huge pile of work, both for development and maintenance.Ģ. Here are a few suggestions about what looks possible:ġ. But the more SFML waits, and the more it'll sink in legacy (at least in mid-term regarding Apple platforms, and in long-term on other platforms too). This is not an issue for short-term, except if you're targetting better performance. You can more or less see that since Metal was released in 2014, no progress has been made on OpenGL (ES) support. On iOS, OpenGL ES 3.1 (2014) and OpenGL ES 3.2 (2015) are also not supported.

On the other hand, macOS supports up to OpenGL 4.1 (spec released in 2010) and iOS supports up to OpenGL ES 3.0 (spec released in 2012). In 2017 Metal 2 was released both to macOS and iOS. I’m working with core profile 3.3.As you may know, Apple is pushing its own GPU technology, Metal, which was made available to iOS in 2014 and to macOS in 2015. I don’t exactly how I have to activate the OpenGL context, my shaders are right, they are very easy. The openGLContext is not active, for this reason it exits when I come into the render() method. I’m trying to do my first OpenGL Programm with JUCE.