Jump to content
  • Advertisement
Sign in to follow this  
Angelic Ice

OpenGL Cross Platform Graphics APIs

This topic is 587 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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!

Share this post


Link to post
Share on other sites
Advertisement

(suitably modern) desktop OpenGL is a strict superset of OpenGL ES. You can look particularly for the ARB_ES2_compatibility and ARB_ES3_compatibility extensions for specifics of compatibility.

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.

Edited by swiftcoder

Share this post


Link to post
Share on other sites
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.

Edited by felipefsdev

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

Either OpenGL 3.3+ or OpenGL 2.0 would be a good starting point.  Thought the OpenGL Superbible version 7 is pretty awesome tool.  I would recommend GLAD too, I'm using GLEW but will eventually transition away from it.

Share this post


Link to post
Share on other sites
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...).

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.

Share this post


Link to post
Share on other sites

What about this ?

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

Edited by _Silence_

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

The benefit of BGFX is drawing 3D graphics using the simple, comfortable API of a portable library instead of the complex, irritating and very different APIs of Direct3D, OpenGL and Vulkan on different platforms. BGFX is very suitable for use with SDL, which takes care of many complementary and more basic aspects of game programming (windows, input, event handling etc.) with the same approach of burying platform differences under a good, portable API.
Use SDL and BGFX together as the foundations of a potentially cross-platform game engine; it's better than reinventing the wheel or needlessly limiting portability..

Edited by LorenzoGatti

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!