Message-ID: <5323A090.4010805 at icculus.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
But maybe there’s a definite win here for game developers by being able
to upload vertex buffers and draw 3D geometry, if it lets them get that
same benefit for 3D stuff that the Render API got me for Dredmor.
Probably there are a handful of programs where it would let the
Renderer be used, and probably it would let some more stuff run on
slightly older hardware, but I strongly doubt that it would be enough
to justify adding it into SDL’s core. After all, OpenGL’s Immediate
Mode has Display List support, but that wasn’t enough reason for SDL 2
to start out with an equivalent, even though support for it would
conceptually be simple. For my money, providing enough capabilities to
extension libraries for one of them to do it is enough, let SDL 2
remain restricted to “the short list” of features.
At any rate, to the best of my memory we could implement command
buffering by writing a custom renderer back-end, and sticking it
between the public API and the SDL back-end. The only reason why we
"can’t" do it right now is that the structures that we’d have to
modify don’t have definitions within the public headers, only opaque
declarations, so we can’t change what back-end a renderer is using.
And since we could do that if the headers had the right structure
definitions, we should be able to extend the existing renderers with
non-SDL code by using the exact same structure definitions. The only
reason why it isn’t convenient is that the information in question
isn’t provided right now.
But here’s the problem:
- This is about as far as the software renderer could go. More features
on top of this get really hard, and things like pixel shaders get
impossible. Already we’d have to decide if optimizing a software
renderer is worth the time it would take just for getting polygons to
the screen.
I’d say that software renderer optimizations are a no-go. If we want
to enable something via the API that will be slow on the software
renderer, then we should just add a note about the slowness (and maybe
a flag to trigger a failure any time you attempt something that’s
expected to be slow). The software renderer is usually not going to be
a speed demon regardless of all other matters, so we should just
accept it, and add a flag to trigger errors from any function that’s
expected to be “too slow”.
I’m already sort of the opinion that we should expose 3D
rendering as a flag, like we do for render targets, and just say you
can’t do it without some sort of GL or D3D.
If we’re going to add 3D rendering then it should go in the software
renderer too. If it’s slow then so be it, that’s what they get for
using the software renderer instead of hardware renderer (this
wouldn’t make it useless, it would only restrict it to render farms &
such).
- The next email thread will be about “if SDL has 3D rendering built in,
why can’t it also have X, Y, and Z?” the same way that the existence of
the Render API at all makes people ask why it can’t also have 3D
rendering. It’d still be a “toy API,” and serious apps would want more
power, and the struggle continues.
If I was at a point where I could spend time on it, I would take this
as a reason to implement a shader system for the software renderer as
an extension library. That way we could just point to it and say
something like “core features go in SDL, fancy stuff always goes
outside SDL”, using it as an example.
Should the line we draw be “if you need texture-mapped polygons, we can
help, but if you need shaders, use OpenGL and/or Direct3D?” I don’t know
the answer yet. It might be a line too far already.
I’d say that 3D and shaders are both definitively extension-library
territory. I think we should cap out with triangles (after which we
should test using triangles as the back-end implementation for
textured quads).> Date: Fri, 14 Mar 2014 20:36:32 -0400
From: “Ryan C. Gordon”
To: SDL Development List
Subject: Re: [SDL] API for non-rectangulars