You want to make good looking retro games for Linux, but OpenGL drivers rarely follow standards and are often full of bugs. After testing on many devices, you end up avoiding most of the modern features and your code is still an overly complex mess that breaks without constant maintenance. You looked at Vulkan and found it even more complex with exceptions hard-coded for every known model of graphics cards just to make a cube rotate. You tried the abstractions, which only made fixing the bugs more difficult. You are now paranoid about which dynamic dependency will break next. Most of the surviving games simply used software rendering. It was robust simplicity before rendering 2D meant emulating on top of a complex 3D rendering pipeline with depth division, texture sampling, undefined behaviour, crashes and precision problems just to copy a few bytes in memory.

You probably think about software rendering as that slow and ugly thing from the 1990s with nearest neighbor sampling when CPUs struggled to do what GPUs later became good at. CPUs are much more powerful today, but still limited by data speed and cache misses when attempting to emulate a GPU with perspective projection. If you back a little bit to isometric rendering techniques where games were resource efficient with unlimited detail level and then add modern deferred light effects and CPU optimizations, you have my new software renderer without all the annoying complexity and bugs from graphics cards. It still has real-time 3D with perspective, but mostly as a side-feature for tools and assisting 2D techniques.

Why would my software renderer be fast enough? I used to work as a mobile firmware developer writing intrinsic assembly optimizations for real-time video analysis to compete against dedicated hardware. My boss used to tell me that my code didn't need any more optimization because the competitors were ten times slower. Anyone who claims that assembler is always slower than C++, just doesn't know SIMD vectorization. Knowing the tricks with intrinsic assembly instructions can give a 200X performance boost and seriously compete against graphics cards in low-resolutions using higher frequency, less memory duplication, less pipeline overhead, less redundant calculations, less latency and smarter algorithms.

Why would my renderer not also end up full of bugs? I have a university degree in computer science, Asperger's Syndrome, over twenty years of programming experience, and worked with safety-critical robotic vision for airport traffic control. If you simply assume that your code is perfect, you will only increase the cost when you make a mistake. Space ships exploded on launch because of arrogance from coders that refused to test their code after "prooving" correctness. A proof only states that output is correct given perfect input on a theoretically perfect system, which is never the situation in real life. Regression tests only find some of the new bugs and the rest accumulates over the years due to over-fitting. Module testing only finds bugs in active code that's actually called, making the rest into a mine-field when code changes. Only patience and using all the techniques can produce quality software.

So why am I asking for your help with this? Unlike graphics engines, this is a new graphics API. It needs graphics engines made by advanced C++ programmers with experience in SIMD vectorization and multi-threading, before beginner and intermediate programmers can use them efficiently and creatively to make their games in different programming languages. They need tools for making game assets and pre-made image filters. I could spend my next 20 years doing all this myself, but then I would have less time to ensure the best possible quality for the core library.

Tools
Part of making an engine is making tools for the files. You can make 3D model import functions, Blender plug-ins, model editors, GUI editors, sprite editors, animation tools, et cetera.

Visual components
Part of making tools is expanding the available components for creating interfaces. If integrated with the virtual machine, the style can be changed for reuse. Only timeless desktop styles are used, so no hidden swipe moves or overly large checkboxes that will be out of fashion with the next Iphone release.

Porting
If your preferred desktop operating system is not supported, make a window management module. Currently supporting Ubuntu, Mate, Mint, Manjaro and Raspbian Buster using X11.

I have no experience with Macintosh, but it should in theory be small modifications. Instructions for how everyone can test this in a virtual machine would be great.

The framework was partially ported to Microsoft Windows before I had to abandon the operating system for being too incompatible with my devices (motherboard, mouse, keyboard, camera and router). Yes, Linux won on driver compatibility this time, due to planned deprecation from hardware vendors. If you still have a computer compatible with Microsoft Windows, then you can write a Win64 compatibility module.

It's difficult to keep the rendering API small yet packed with useful features, so develop new engines outside. Only the most light-weight, fast compiled and reusable parts that others request for their abstractions can go into the graphics API. Use of patch-work third-party dependencies like SDL and OpenGL would defeat the purpose of making a static software renderer in the first place. This library should not require patching every year, nor make lots of exceptions for specific OS versions, because that would be a sign of poor quality without long term planning for operating systems in year 2100.

The goal is to be much better tested than most safety-critical systems, so that you can use static linking and not worry about patching bugs in the future. It does however include a few floating-point operations (not 100% deterministic) where the fixed-point operations would be too slow or non-determinism is inevitable anyway due to incorrect timing without a real-time operating system.

Now that we have sorted out the impatient developers with a long rant, reply if you are interested in making an engine with tools for this project. Then fork the repository and make your project folder in the SDK where you experiment with rendering techniques and abstractions to learn the basics. When finished with a stable version, rebase and make a pull-request against the main repository. Revoking contributions after being merged requires consent from the respective repository owner and a very good excuse, like finding bugs that cannot be fixed. Other people should be able to base their work on the contribution, so don't steal anything online.

The main repository
https://github.com/dawoodoz/dfpsr