Port to OpenGL ES 2.0

[einthusan]

Hello, I am thinking of forking this and swapping out OpenGL 4.x with OpenGL ES 2.0 so that I can set the foundation for mobile device support (iOS/Android). Is there any specific reason for using 4.x in the first place?

EDIT: OpenGL ES 3.0 has buggy drivers on most mobile devices, and it should be sufficient to use OpenGL ES 2.0 which is both performant and stable. I have changed the title of the issue accordingly.

[johanhenriksson]

Hi! Sounds like a cool idea, go for it :)

To be honest I don't remember why I originally picked 4.x, it has been a few years.

[einthusan]

Yes, indeed I am going to. We are working on an educational game for preschool children to learn math and sciences. It will be mostly 2D looking, with 3D space to move around in. Hope to start work on the modifications in a few days! Thanks.

[einthusan]

FYI: Just an update!

Currently doing research on the best approach. There is 3 possible routes. golang/x/mobile/gl or google/ANGLE or MoltenGL. I prefer to avoid MoltenGL because it requires commercial licensing.

EDIT: There is a 4th option, which is to directly use go-gl/gles but this would not enable development on desktop OS (e.g. macos). To get around this, we can create our own go-gl/gl binding using go-gl/glow which mimics GLES2 as close as possible, and switch between those during development and deployment, but it would be a lot more work. I think.

I am also trying to get more feedback from the community to help me decide better.
go-gl/glow#51 (comment)

I am also told because golang/x/mobile/gl uses go channels, that it may be inefficient. I need to benchmark the various implementations before finalizing which to go with. I am also considering writing an interface that would easily allow someone to swap out a particular backend implementation with ease.

The goal is that if we can accomdate multiple backends, then using google/ANGLE it would enable porting to Vulkan and Metal backends because google/ANGLE has support for this. This would make it future proof and the most compatible with newer devices/platforms, but would require external dependencies so initial setup will be a little more complex.

Hence, multiple backend swapping capability (via interface implementation) is important if we want it to be both easy to get up and running initially, and then have wider platform support upon deployment without changing any application level code.

[einthusan]

TITLE EDIT: Changed from OpenGL ES 3.0 to OpenGL ES 2.0 due the following reason.

OpenGL ES 3.0 has buggy drivers on most mobile devices, and it should be sufficient to use OpenGL ES 2.0 which is both performant and stable. I have changed the title of the issue accordingly.

NOTE: OpenGL ES 2.0 (GLES2) is based on a stripped version of desktop OpenGL 3.2. Initially, I had thought GLES2 was based on desktop OpenGL 2.1, which does not have the required features to begin a port.

[johanhenriksson]

Closing since the project is moving to Vulkan. Im guessing you're not working on this anyway :)

[einthusan]

Closing since the project is moving to Vulkan. Im guessing you're not working on this anyway :)

I didn't forget about this. We actually have moved to Vulkan and are in the beginning stages of procedural generation. So are you rewriting the entire codebase for Vulkan from scratch? Exciting to know there is going to be further development on this. 👍🏽☺️

[johanhenriksson]

Cool! Yeah I started to write a vulkan backend, but I've decided Im not interested in duplicating all of the work, since its just a hobby project for me anyways. So I threw out all the opengl code :D

We'll see what happens, but I'd say its pretty unlikely that this project will ever reach a point where its useful to others as anything other than perhaps as a learning resource

[einthusan]

Where is your Vulkan backend located? Can you point me to the link?

[johanhenriksson]

Where is your Vulkan backend located? Can you point me to the link?

It has replaced the render package: https://github.com/johanhenriksson/goworld/tree/master/render

It's not really a separate backend anymore, its intermixed with the rest of the engine code, since there's only going to support vulkan going forward.

[einthusan]

Thanks.