There’s simple and there’s naive. SDL already walked this path. So did pygame. It turns out without shaders, and all their complexity, you basically can’t do

There’s simple and there’s naive. SDL already walked this path. So did pygame. It turns out without shaders, and all their complexity, you basically can’t do anything useful at high resolutions. /shrug It’s too slow; compositing, transformations, all the things people want to do are very much harder to implement in software on top of a naive graphics stack. Simple doesn’t mean naive; you can have a simple api that is excellent. …but this is a naïve implementation, and it won’t work in any useful way at scale. People complain about ballooning complexity, but they often forget that stuff (eg. specialised graphics hardware) wasnt invented by a bunch of idiots. It was invented because the naive approach, that they used before was found to be in practice fundamentally limiting, inferior and failed to meet people’s expectations. Of course, if you vastly lower your expectations, and target say, 320x240 at 8bit colour, you can happily have a naïve implementation that works just fine (Don't believe me? Quote: > Having this we can now draw complex polygons and would probably need a “flood fill” algorithm. Typically it is implemented using a queue of pixels to check and paint, but we can use recursion, as long as the filled area remains small enough to not overflow the stack ^ This is the very definition of a naive implementation, and https://github.com/zserge/fenster/blob/e71d493fa6d544243dd601425179d6f7c7394b0e/fenster.h#L51 https://github.com/zserge/fenster/blob/e71d493fa6d544243dd60... settings one pixel at a time, is too. Delightfully charming as it might be to write your own functions that set one pixel at a time, it's a joke, really, if you expect to do anything serious)