> direct access to the command buffers of the GPU

Impossible given the platform limitations at that time, on Linux that code works on top of GLES 3.1. I didn't want too many Windows-only features there.

> No matrix transform routines?

There's no need for that. That library is for C#, which includes these routines in the standard library of the language for many years now, since .NET core 1.0: https://learn.microsoft.com/en-us/dotnet/api/system.numerics...

My remark was about Fenster, and a critique of your comment that it somehow isn't good enough because it lacks GPU acceleration and that sort of thing. The point of Fenster is to be minimal and simple yet still allow programmers to get stuff on the screen in a way that's easy and fun. It performs superbly at the role it was conceived for. We can list features we want/think are table stakes for a modern graphics pipeline or whatever, and there are plenty of libraries that are up to those tasks. This one is doing something different.

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…

For any graphic intensive application it would be obviously be necessary to use a GPU.

But for quick hacking / porting old demos / writing emulators and also text based UI it can be fast enough.

With the added benefit of small footprint, high compatibility and fast startup time.

The Lite editor https://github.com/rxi/lite is using pure software rendering (on top of SDL) in a rather naïve fashion but it still renders full 32bit colors at full resolution at more than 60FPS on my computer, not the best solution but still surprisingly fast given the simplicity of the renderer.

This is typically a case where simple/naïve can beat a juggernaut like Electron.

> is using pure software rendering (on top of SDL) in a rather naïve fashion

https://github.com/rxi/lite/blob/master/src/rencache.c#L4

I think you'll find that they found the naive approach was sufficiently poor, performance wise, that additional optimizations had to be applied on-top.

> But for quick hacking / porting old demos / writing emulators and also text based UI it can be fast enough.

/shrug

If you want to use it, use it. It's 'good enough'...

> if you vastly lower your expectations

> No direct access to the command buffers of the GPU?

Lol, show me one library that does this without going through an abstraction layer like Vulkan. Details like this are not even documented by GPU vendors and you'd need to reverse engineer every supported GPU architecture yourself.

I was being sardonic.

Guy writes a library with the design goals of making basic, retro-like graphics functionality easy and fun with a minimum of code, and certain Hackernews dogpile him because it can't be integrated with an AAA pipeline or whatever.

Ah, apologies then :)