Hey forum : )

My initial plan was to learn OpenGL but I quickly realised that OpenGL and OpenGL ES are not the same, seemingly neither is a subset of the other? Correct me, if that is wrong.

Nonetheless, I would like to create a C++-game for common OS, as in Windows, Mac, Linux, Android and iOS. Now, it seems that this is not possible with something as GLFW and GLEW. I heard of GLFM, but that sounds like it would require less crossplatform-code and more OS-specific one.

My previous experience is limited to SFML, where I had to change only a little bit of code among platforms.

Do I need input, etc.? Well, good question. It would be great to have but this project primarily is about working with a bit more low-level graphics code without having to write 20 lines in order to create a window-context.

I'm not really sure if "learning OpenGL" and "writing code that works on OpenGL and ES without changing too much" is even feasible.

I also heard of bgfx, not sure if that would solve my problems in anyway.

But maybe I'm living in a dream-world : )

Thanks a lot for taking your time!

My initial plan was to learn OpenGL but I quickly realised that OpenGL and OpenGL ES are not the same, seemingly neither is a subset of the other? Correct me, if that is wrong.

Yes, the OpenGL versioning and all the forward/backwards compatibility that they tried to provide between versions is quite a PITA.

Nonetheless, I would like to create a C++-game for common OS, as in Windows, Mac, Linux, Android and iOS. Now, it seems that this is not possible with something as GLFW and GLEW. I heard of GLFM, but that sounds like it would require less crossplatform-code and more OS-specific one.

GLFW is for desktop, but can support web if you use Emscripten, and GLFM is for mobile and web.

For a loader, ditch GLEW and use GLAD (http://glad.dav1d.de/ | https://github.com/Dav1dde/glad).

In practice, it's a bit of a wilderness out there, and if you are trying to do something on the cutting edge, you'll end up with minor incompatibilities and fallbacks between even different chipsets and drivers that claim to support the same versions of OpenGL or OpenGL ES.

So long as you stick to vanilla OpenGL ES 2.0 or 3.0, it should be pretty trivial to port your code to other (suitably modern) OpenGL systems.

Yes, GLES 2.0/3.0 is the best case scenario. As example, Godot uses ES 2.0 by default.

In fact, if you are not doing something cutting edge like @swiftcoder said, and you are properly separating your renderer from the game engine logic, porting between different versions of OpenGL to suit your needs isn't so dificult. Let's say you just want to render quads on screen, you will just need to put an #ifdef here and make it render a quad using each OpenGL version you want to use. GLES is still the best option.

Thanks! So, learning OpenGL ES first is a better way to go? Is it better to go with 2.0 for the sake of platform-support?

Also, are there any good and modern sources to learn proper OpenGL ES? A lot I found does not seem to be modern at all.

Additionally, thanks for the note on GLEW, will use GLAD instead!

Either OpenGL 3.3+ or OpenGL 2.0 would be a good starting point.

Oh, so OpenGL instead of OpenGL ES?

What about this ?

EDIT: Just noticed the OP already mentioned it in his first topic...

Google has a library called Angle which implements GLES on desktop... On Windows it works by translating all the calls to D3D11 :o (I assume for stability reasons...).

Oh, that sounds really cool!

If you actually want to make a game instead of becoming a graphics API expert though, then using a library like BGFX will be much better use of your time.

Honestly, I wanted to do this project to see if working with graphics APIs is in my interest, as I loved to create visual applications (games too) until now. Though I only used high level abstractions of them, as in SFML etc.

So maybe I should just do a project in OpenGL for my desktop and care about all these other cross-platform-dream-idelogies in my head later, haha.

About BGFX, I read about it quite some times but never really understood what it is. Because you can bring your own graphics API to it (e.g. SDL) and use that instead? But then, what if I do not want to bring my own to it - I probably have to, right? What other APIs could I use? The overall idea of BGFX is not entirely grasping around me. Do I give it just a renderer/window-context and it will do the rest when I use BGFX-calls? Because if I had to continue using e.g. SDL, what is my benefit? It seems to support many graphics API... but e.g. SFML does not support DirectX to begin with, so I do not really understand the gain and idea behind BGFX.