![](https://media.kbin.social/media/21/4a/214a5698163c9a30d11640ffc0517e62493b01a3bfe14dc73f67779fdec399b1.png)
![](https://lemmy.dbzer0.com/pictrs/image/a18b0c69-23c9-4b2a-b8e0-3aca0172390d.png)
Mine is quite minimalistic, and relies for the D runtime and standard library (or other D libraries) for many things. Also my engine is primarily geared towards retro pixelart games, and works as such. Currently, the CPU renders to a low-res texture (as seen in emulators), which is then stretched to a higher resolution, later on it’ll replaced by custom shaders that do color lookup and render directly to a texture (which is quite complicated, simpler methods would cause easily misalignable pixels, thus defeating the engine’s purpose, even if some likes the “smooth” scaling from other engines).
Also GPU drivers.
If you’re mad at NVidia for their closed-source drivers, then remember that ARM seldom makes their Linux drivers available for free, so you have to either have to deal with absolutely no GPU driver while the CPU does the graphics rendering (might not be a big deal on a NAS though), or with open source drivers that are less capable than the Nouveau drivers and even fiddlier to install. The ARM Mali driver issue is so bad I was legit thinking on a solution to run the Android binary blobs (which at least are available by ripping them off from the Android kernel) on regular Linux, a lot of function call redirects would likely take care of that issue.