TinyGL 0.4.1 (opens in new tab)

I used to work on a project called glshim (which ptitseb still maintains as gl4es, used by box86). glshim implements an ABI-compatible OpenGL 1.x fixed function API (as libGL.so.1) on top of an OpenGL ES 1.x driver. This allows you to accelerate completely unmodified OpenGL programs on mobile Linux devices such as the OpenPandora.

This approach even works with x86 user-mode emulation, by serializing render commands into a shared memory ring buffer and running the driver in native code out-of-process (which as a bonus was also generally faster than rendering in-process).

I built glshim after hand porting a bunch of open-source Linux games from OpenGL to OpenGL ES. The last game I hand-ported like this was Introversion's Uplink Hacker Elite. The diff was thousands of lines, and the resulting port had buggy rendering and blurry fonts, so I got fed up with hand ports and started working on a universal solution.

After a few years, I had ironed out most of the bugs in glshim, and ports to the Pandora were much easier. Uplink, however, was still in a sorry state. It made heavy use of glBitmap for crisp font rendering, and glBitmap was very slow to emulate on top of OpenGL ES 1.x. glBitmap basically manipulates framebuffer pixels directly, and the easiest way I found to do that was to upload a texture and render it with GL_NEAREST. Texture uploads seemed to be extremely slow and CPU-bound on the Pandora's Cortex A8 / PowerVR SGX 530. I ended up batching subsequent glBitmap calls, trying to coalesce them into a single texture upload per frame, and with that I still only managed single-digit fps.

With glshim, I had a moderately complete OpenGL implementation that only relied on a small subset of the OpenGL ES API. Then I stumbled on TinyGL. I realized that despite TinyGL not implementing much of the full OpenGL API, it was very fast and implemented basically everything I needed from OpenGL ES for glshim to work. So I forked it as "TinyGLES", deleted the extra GL parts, and optimized the rendering paths for ARM NEON. It ended up making a really good software rendering backend for glshim. I used this to finally release a good version of Uplink for the Pandora, which ran at around 80fps! With TinyGLES, glBitmap could blit directly to the software framebuffer, avoiding the slow/buggy texture emulation path.

It had been a few years and I couldn't find the modified source for my Uplink port, so I just swapped out the libGL.so file when I updated Uplink to use TinyGLES. But some users found an annoying bug in the port. Anytime you restarted the game, it put you directly in the "new game" menu, instead of allowing you to pick between new game or loading a save. I ended up fixing this with a binary patch to the game executable (which forced the game to the main menu screen on every launch), and that's the version currently available for the Pandora: http://repo.openpandora.org/?page=detail&app=uplink

I ended up writing my own software "kind of OpenGL" implementation at one point. The main reason why was because I was trying to take photos of objects, and triangles that we thought mapped to their surfaces, and I was trying to map the pixels in the photos back onto the textures of those triangles. I had a heck of a time with interpolating texture coordinates, until I learned more about the homogenous coordinate and how you have to interpolate then divide, etc. Having an existing simple software implementation (like this one) would have helped a bunch. =)

Anyone remember the various MiniGL that were initially implemented to run Quake?

https://en.wikipedia.org/wiki/MiniGL

I like what he does, but projects tend to loose interest from the author and become abandonware. For one project he accepted to publish it on github and forks continued to develop it, but original project stagnated.

mmmh... maybe it could be a good replacement of a hardware accelerated 32bits libGL which is still and currently required by the steam client (but it seems they are moving finally the last bits of 32bits code to libcef, but it is valve then don't be impatient). oh, yeah and I play games on elf/linux without that msft grade horrible proton (= wine with plentyfull of components copied straight from doz, as far as I know... that said a lean wine build for core win64 and vkd3d for vulkan/dx12 support... mmmh... wonder which games could run with that).

I wrote my own, but I had to put in assembly code to make it fast enough (amd zen2) so I am pessimistic about tinyGL being fast enough for that, and it is really a quick and dirty thing with bugs to avoid to build that horrible libGL for 32bits ONLY for the steam client (all the games I play are native vulkan3D, but I still run x11 native so I don't know about their wayland support).

I've always felt that OpenGL was too abstract for graphics novices; perhaps this tiny subset of GL will change that.

Fabrice Bellard is a robot from outer space - this must be the only explanation.

Taking 20 years to move from 0.4 to 0.4.1 seems like a long long time.