DLudwig

I'd like to see a reasonably-standard C++ API specification for at least a few graphics-related things (and perhaps more over time), but am not sure if writing a graphics API with the sole goal of eliminating all other APIs or libraries, would make any sense. The people with whom I've talked to, some of whom have done work on P0267/io2d, don't seem to be explicitly aiming for this either, but perhaps I've missed something.

I'd be happy to see vec2/vec3/vec4 style APIs in the C++ standard, too. P0267/io2d does have some support for this, although I think it could certainly stand to get some love + attention!

I agree that having a standard with a common subset of widely-used features would be of value, however, I'm suspicious of the claim that it could cover "95% of use cases". Are there some specific use-cases that you have, or had in mind?

The authors of the recent, P0267 C++ graphics paper (aka "io2d"; latest revisions getting posted to https://github.com/mikebmcl/io2dts/tree/master/papers), as far as I've seen (online, mostly), aren't interested in making a "toy" API. Many, if not all of them, want people to be able to do 'real' work with it. They've also seemed willing to accept constructive feedback on it, and are cognizant that there is a good amount more work to be done, if something useful is to be a result!

There is, I think, room to work on different C++ features in parallel. A graphics expert isn't necessarily going to want, or be qualified, to lead a charge on all future, non-graphics features.

In terms of 'other languages have it too', here's one platform/standard that has it: HTML5. It's Canvas API is pretty widely available, although in practice, perhaps only with sufficiently powerful runtime-processing power.

Regarding software renderers, I'd argue that these are still useful, in some use cases. I've worked on some projects whereby a constexpr/compile-time canvas-style implementation would have been useful, I imagine.

SDL2's render API can use GPU acceleration, however its feature set is rather limited. This is plenty for many, however is incomplete for others. I've heard its feature set be referred to as 'SNES-level graphics', or something to that effect, from at least one SDL-internals dev, something which I'd also echo.

... and LibSDL 2.0.8 is now released (with the aforementioned Vulkan improvements)! Further details at https://discourse.libsdl.org/t/sdl-2-0-8-released/23957

It looks like the next version of LibSDL, 2.0.8, will support it to some degree, as of a commit from a few days ago: https://hg.libsdl.org/SDL/rev/d97ab6d12404

For reference, LibSDL recently added the ability to help initialize Vulkan, in a cross-platform manner. A bit of further info on this is available at https://discourse.libsdl.org/t/sdl-2-0-6-released/23109

A suggestion: wrap the bulk of content in platform-specific .cpp files, with pre-processor guards that'll check for platform. This should allow the library to be imported into other projects, simply by importing all .cpp files, and adding a path for header-includes. With that done, adding support for extra build systems becomes an optional, albeit nice-to-have addition, but by no means required.

I believe the thought was that, for many languages, there is an additional, standard runtime, which is not always remove-able from the language itself, which may not always be of a trivial size, and which is not guaranteed to be already available on a client machine.

Is Nidium being used in any real applications (or games)?

Are the needs of specific applications (or games!) influencing the feature set of Nidium?

But to what degree might this 'meta-API' be different than WebGPU/JS? Might this effort effectively end up creating two, new APIs, each with different vocabularies (one for JS, another for C or C++)?