Here’s my point of view from already implementing these things in SDL_gpu…
I’d rather that the rendering system did not do smart things behind my
back, so SDL_gpu has explicit calls that you need to perform in response to
certain events (e.g. GPU_SetWindowResolution() upon SDL_WINDOWEVENT_RESIZED
and GPU_GetVirtualCoords() to scale device coordinates from mouse events to
your virtual/logical resolution). It makes sense that for easing the
porting of games you may want those things done for you, but that is no
concern when the aim is a modern rendering system. I think something like
SDL_RENDER_WITHNATIVE3D would be a hint to disable these smart things.
SDL_gpu now has GPU_ResetRendererState(), which would be the equivalent of
SDL_RenderEnd(). SDL_gpu stores the state that it expects to have and can
reset that state in this function (no glGet*() at all). For reference here
(SDL_gpu has renderers for fixed-function and shader-based OpenGL), it
resets the current shader program, the current GL context, the glColor, the
enabling of GL_TEXTURE_2D, the enabling of GL_BLEND, the blend function and
equation, the viewport, the bound texture, and the bound framebuffer.
Everything else is set as needed when flushing the vertex buffer, because a
simple VBO buffered rendering optimization is already in SDL_gpu.
Some of those settings (like blend modes) would likely have to happen in
SDL_RenderEnd() even in a shader-based renderer.
Your code certainly will need to know what 3D context it gets. SDL_gpu
presents that information in its renderer structure so you can check which
backend you got (only OpenGL and OpenGL ES so far), which backend version,
which shading language, which shading language version, and which features
SDL_gpu uses that it has detected as available.
Jonny DOn Thu, Jan 8, 2015 at 8:41 PM, T. Joseph Carter < tjcarter at spiritsubstance.com> wrote:
I think Sik may have jumped the gun ever so slightly on bringing this
discussion up because he and I were discussing it off-list and it’s going
to take slightly more than these two functions to accomplish what we’re
talking about.
First, when creating a renderer, you’re going to have to ask for a
renderer that can SDL_RENDER_WITHNATIVE3D. That’s going to inform your
renderer that certain things it typically does for you in older versions of
SDL2, you’ve assumed responsibility for. Things such as deciding what to
do when a resize event happens. The renderer presently tries to do
something smart for you because it can, but it cannot do that if you’re
going to mix 2D and 3D. If a renderer cannot be created that supports this
flag, your call to create one will fail.
Second, to support this on fixed pipeline OpenGL, someone (hi!) is going
to have to audit the fixed pipeline renderers to see what states they
change, and what states they assume. This is not 100% trivial, but
fortunately at this point fixed pipeline OpenGL is more or less a finite
problem. Certain things you enable are going to need to be glDisable’d
before calling SDL_RenderBegin and renderer functions. And should any
renderer addition in the future enable other pipeline features it doesn’t
already use (somewhat unlikely, but possible) it will need to disable them
in SDL_RenderEnd. This means some state thrash to avoid the glGet calls,
but frankly the state thrashing is faster than glGetANYTHING, and if you’re
worried about speed loss because of thrashing state, why are you using the
SDL renderer at all? It’s bad at this and no promise was ever made that
it’d ever get any better.
The restrictions on shader-based render targets are far fewer because
there’s far less actual state. In fact, it’s quite possible that RenderEnd
and RenderBegin could be empty functions.
Third, it might be necessary to add some ability to query the SDL render
state and possibly to make changes to it from your own code. You’ll have
to get along with the renderer, essentially.
The idea of using some helper library in OpenGL predates the use of
shaders. Fixed pipeline GL being a state machine, however, the use of
those library functions required observance of preconditions and
expectation of postconditions.
This is a concept still somewhat in its infancy because while certainly
possible, it’ll take some effort to do it an abstract way whether you’re
using GL or GLES, fixed or programmable pipelines, etc. Probably your code
has (or will have) certain assumptions about the 3D context it wants to
work with.
And presently, Direct3D in SDL is something you do either completely
without SDL’s intervention or gets done by the renderer. You can’t ask for
a Direct3D window like you can OpenGL. In order to make this work with
non-OpenGL 3D APIs like Direct3D or Metal (should that ever get support),
we’re going to have to answer some serious questions.
And likely the answer will be best implementation wins.
Joseph
On Thu, Jan 08, 2015 at 08:17:24PM -0400, Alex Szpakowski wrote:
That would involve many glGet* function calls in the OpenGL backends,
which isn?t very efficient. I?m not sure if efficiency is something people
care about when using SDL_Render though.
On Jan 8, 2015, at 10:16 AM, Sik the hedgehog <sik.the.hedgehog at gmail.com> wrote:
I know people want to mix the renderer API with direct access to
OpenGL and such but the problem is that doing that will clobber with
the renderer’s expected state, resulting in things not working at all.
So I had an idea: let’s have two functions called SDL_RenderBegin and
SDL_RenderEnd. The former sets the GPU state to what the renderer
wants, the latter undoes that change.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org