gl4es: OpenGL 2.x on OpenGL ES hardware

A translation layer between two graphics APIs

The name is a compressed statement of the whole project. GL4ES takes OpenGL 2.x calls and OpenGL 1.5 calls and makes them work on hardware that only speaks OpenGL ES 2.0 or 1.1.

The README states it as a library that provides OpenGL 2.x functionality for GLES 2.0 accelerated hardware, and notes that it also supports OpenGL 1.5 functions, sometimes with better results than using the native GLES 1.1 backend. In the other direction there is support for GLES 1.1 hardware emulating OpenGL 1.5, plus a selection of OpenGL 2.x and later extensions.

The stated focus is compatibility and speed across a wide selection of games and software. The list of titles that have been tested is specific: Minecraft, OpenMW, Serious Sam in both encounters, RVGL, The Secret Maryo Chronicles, TORCS, SpeedDreams, GL-117, Foobillard, Half Life 1 and 2, and Blender 2.68, with some success reported on Linux ports of XNA games through MonoGame or FNA.

The platforms are equally varied: OpenPandora, ODroid, Raspberry Pi 2 and 3 at least, PocketCHIP, the OrangePI class of boards, Android, iOS, and x86 and x86_64 Linux tested with mesa-egl. AmigaOS4 support is described as work in progress, using an experimental GLES2 driver for Warp3D.

The fixed pipeline emulator behind the ES2 backend

Most OpenGL 1.x rendering was the fixed function pipeline: matrix stacks, lighting, fog, texture coordinates and colour material, all handled by the driver with no shaders in sight. GLES 2.0 dropped that pipeline entirely, keeping only the programmable one.

gl4es therefore contains a fixed pipeline emulator, which the README says has most of the OpenGL 1.5 drawing calls implemented. That is what makes the old titles in the tested list work at all. On top of it sits a shader conversion layer, and here the README is blunt: the shader conversion is really crude, so only simple shaders will work, especially since the implicit conversion between float and int is not handled.

ARB_program support is present, with those programs converted on the fly to GLSL shaders. Lighting support covers double sided lighting and colour separation, and fog coordinates are supported along with secondary colour. An ES2 context should be usable, which the README calls out as useful for SDL2.

The gap between the fixed pipeline and the programmable one is where the failures live. The README notes that glxgears works but that FlatShade is not implemented and probably never will be, so the output is slightly different from using a GLES 1.1 stack or real GL hardware. GL_TEXTURE_1D, GL_TEXTURE_3D and GL_TEXTURE_RECTANGLE_ARB are not yet supported in shaders, though they work in fixed pipeline functions, and a 3D texture is currently just a single 2D layer. Programs that link only a fragment or only a vertex shader are not supported yet.

The GLES 1.1 backend gives up more

On hardware that only speaks GLES 1.1 the emulation target is OpenGL 1.5, and the feature list shrinks accordingly.

Framebuffer objects are done through the FRAMEBUFFER_OES extension, which the README notes must be present in the GLES 1.1 stack. Lighting does not support double sided lighting or colour separation. Fog coordinates and secondary colours are not supported at all. GL_TEXTURE_3D is reduced to its first layer. Vertex buffer objects are supported, but they are emulated even when the GLES 1.1 driver has native VBO support.

That last point is the practical warning for anyone benchmarking. On a GLES 1.1 board you are paying for emulated buffer objects on top of an emulated fixed pipeline, and the driver underneath cannot help.

The general limitations section applies on top of the backend specific ones. Reading of the depth or stencil buffer will not work. GL_FEEDBACK mode is not implemented, and there is no accumulation buffer emulation. GL_SELECT has limitations in its implementation, for example the current depth buffer and bounded textures are not taken into account and custom vertex shaders will not work there. NPOT textures are supported, but not with GL_REPEAT or GL_MIRRORED, where only GL_CLAMP works properly unless the hardware itself supports NPOT. Multiple colour attachments on a framebuffer are not supported. Occlusion queries are implemented, but with zero bits of precision. The README ends that list with a candid probably many other things.

Installing it means replacing the system libGL

The installation section of the README is two sentences, and both of them matter.

The first is to put lib/libGL.so.1 in your LD_LIBRARY_PATH. The second is a warning: gl4es is meant to replace any libGL you can have on your system, for example Mesa.

That is the whole deployment model. Because applications on Linux resolve their OpenGL symbols through the shared libGL.so.1, putting the gl4es build at the front of the library search path means an unmodified binary picks up the translation layer instead of the system driver. For a single board computer whose native driver only offers GLES, that is how a desktop game can run without being recompiled.

The trade is explicit in the warning. If a system has Mesa, and Mesa is better for the workload, then shadowing it with gl4es is a downgrade. gl4es is for hardware where the alternative is no OpenGL at all.

The build itself is documented in COMPILE.md, which the README points to for how to compile and for per platform specific comments. The repository root shows the build systems in use: a CMakeLists.txt, an Android.mk for the Android build, and GL4ES.cbp for Code::Blocks. There is also a debian directory, so packaging for Debian derivatives has been considered.

Tuning behaviour through environment variables and glHint

A translation layer that silently changes what a program sees is a debugging problem waiting to happen, so gl4es gives you switches.

The README states that there are many environment variables to control gl4es behaviour, and that they are also usable at runtime through glHint calls. USAGE.md is where the full list lives, along with what each variable does.

Having both routes matters for two different situations. Environment variables are what you set before launching, which is how you compare two configurations on the same device without rebuilding anything. glHint is what the program itself calls, which is how a developer finds out why a particular draw call behaves oddly without restarting the whole environment.

The testing infrastructure in the repository matches this attitude. There is a tests directory, a test.cmake file for integrating those tests with CMake, and a traces directory, which suggests the project records and compares GL call traces as part of checking that the emulated pipeline matches the real one.

The reference material is split out too. There is a spec directory, a refs directory for reference material, and a media directory alongside the gl4es.png logo and the README's links to screenshots and videos of working titles.

What gl4es is better at than glshim

The README is explicit about its ancestry and its differences. gl4es is based on glshim, but the author says it has since evolved far from it, with a different feature set and different objectives, and recommends looking at glshim if you need things like RemoteGL or TinyGLES for software rendering.

That is the alternative worth understanding, because it identifies two different problem spaces. glshim is a general OpenGL to GLES shim with a software rendering path and remote display support. gl4es concentrates on hardware accelerated compatibility, on the fixed pipeline, and on a specific list of platforms where a desktop title has to run.

There is also the option of not translating at all. A modern GPU with a proper OpenGL driver, or Mesa on a desktop Linux system, gives you the real API rather than an approximation, and where a game runs acceptably there, a translation layer is pure overhead. gl4es earns its keep where the alternative is that the game does not run.

One last obligation comes with the library. The README asks that if you use gl4es in your project, whether statically or dynamically linked, you mention gl4es in your readme or about page. That request is not a licence term, but it is a reasonable one, since the project is maintained by a single author and the tests in the wild are what keep the compatibility list accurate.

Maintenance, licence and what to check first

The repository is MIT licensed, with the LICENSE file at the root. Permissive terms mean you can link it into a commercial product without the copyleft obligations that would apply to a GPL library, and the README asks in return that you credit it where you use it.

On maintenance, the last push was on 2026-10-14, so the code is current. There are, however, no GitHub releases at all, which means there is no tag to pin a build against and no changelog entry in the release system to consult. The version information lives in a version.h file at the root and the change log in CHANGELOG.md, which is where you look instead.

The repository also carries a .travis.yml file, so continuous integration runs there, and there are CONTRIBUTING.md and AGENTS.md files alongside the usual issue tracker configuration in the .github directory.

Three checks are worth doing before you commit to gl4es for a project. First, whether the specific title you need appears in the tested list in the README or in the screenshots and videos linked from MEDIA.md. Second, whether it depends on any of the missing features, and the two that break most projects are depth or stencil readback and non power of two textures with GL_REPEAT, which are common in games that rely on hardware specific tricks. Third, whether the build works on your target, since the per platform notes live in COMPILE.md rather than in the README.

Editorial conclusion

gl4es is the right pick for a Raspberry Pi class device, an Android or iOS build, or an old single board computer that has to run a desktop OpenGL title that predates shader based rendering, because the fixed pipeline emulator covers most OpenGL 1.5 drawing calls and the library is designed to stand in for the system libGL. It is the wrong choice for a modern GPU that already speaks OpenGL, for a title that needs depth or stencil readback, multiple colour attachments or reliable non power of two texture wrapping, and for anything that depends on precision occlusion queries. Verify first that the game you care about is on the tested list in the README or in MEDIA.md, build it with the per platform notes in COMPILE.md, and confirm that LD_LIBRARY_PATH points at your built libGL.so.1 rather than at Mesa.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. ptitSeb/gl4es on GitHub
5. README