[SDL] Improve SDL2 graphics API

[sgrsgsrg]

Really, I'm in love with SDL2 : good portability, easy event handling, powerful audio API (what could be more powerful than direct writing to the buffer ?).
I started to use it for my (professionnal) game project, but I have to admit, all graphic-related stuff is quite outdated. Sure it's far better than the worthless software rendering that were in SDL 1, but I feel it's the most lacking part. It's a big waste of resources for a desktop computer, and an inacceptable one for mobile devices.

Some people will say "do the opengl stuff yourself", yeah, but while I can handle the audio and other stuff myself handling OpenGL require lots of specific knowledge if you want to do anything more than the old "glBegin -- glEnd".

What I'd like to be added is:

- Texture batching : specify a texture, give an array of source/dest coordinates to be rendered in 1 draw call (so many people need that..)
- Do more things in retained mode

I don't know if all devices covered by SDL would support that, so theses functions would need to have a fallback (eg. texture batching calling multiple classic Draws)

It was already done by some SDL users : https://forums.libsdl.org/viewtopic.php?t=11226&sid=6d123e4460735297c6c5573a69c4dae6

Meanwhile, i'll probably recompile SDL with his modifications. But it'd be nice to have this officially merged into SDL.

[sgrsgsrg]

Sub-pixel rendering / positionning is really needed too. Keep the nearest pixel rounding method by default for backward compatibility, then and add a flag like "SDL_SUBPIXEL" to use when the renderer is initialized

[Jonathan Dearborn]

This is sorta the aim of the SDL_gpu project (
https://github.com/grimfang4/sdl-gpu).

GPU_TriangleBatch() gives you arbitrary geometry rendering in one call.
SDL_gpu automatically collects batches when you use GPU_Blit().

Subpixel positioning, such as SDL_gpu does already, would require several
additional SDL render functions which would accept floating point arguments
(or else break the API).

Jonny D

Post by sgrsgsrg
Sub-pixel rendering / positionning is really needed too. Keep the nearest
pixel rounding method by default for backward compatibility, then and add a
flag like "SDL_SUBPIXEL" to use when the renderer is initialized
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[sgrsgsrg]

I know there is this library but it has some problems. The rendering is very sluggish in windowed mode, i don't know why but i dont have this problem with the SFML renderer (it's not the CPU since its usage is approx 0.5%). Disabling the Vsync completely block the app, getting about 0.5 FPS and max cpu usage. My nvidia drivers are up to date.

Also, someone removed the BlitBatch function from SDL_gpu, forcing the users to get headaches with TriangleBatch... i don't understand this decision. Since you already have 50 functions doing nearly the same thing with 1-2 different parameters, why delete the one that make life easier...

Batch rendering (shown to the used or automated inside RenderCopy) should be simply included into SDL2. Using third party stuff for core functions like that sucks... The audio API had unlimited power with its direct access to the sound buffer, I'd like to have the same applied to the graphics api :)

[sgrsgsrg]

Oops, by "SFML renderer", i meant "SDL renderer" by the way

[Jonathan Dearborn]

On which platform does windowed mode make SDL_gpu sluggish for you?

I removed BlitBatch because it was too limited and in some cases required a
lot of hidden computation. Both of these made it hard to maintain. When
you needed to do anything other than simple blitting, it would require
another specific version of that function in the API. It makes sense for
things like BlitScale et al. because SDL_gpu does automatic batching anyhow.

In the SDL_gpu repository, there is a blit-batch-test with code that
reimplements BlitBatch on top of TriangleBatch in case that helps:
https://github.com/grimfang4/sdl-gpu/blob/master/tests/blit-batch/main.c

I agree that SDL2 should incorporate this functionality. There has been a
patch for it that is nearly complete:
https://bugzilla.libsdl.org/show_bug.cgi?id=1734

The functionality that does exist in SDL2's renderer is most useful for
porting old games to new platforms instead of creating new, modern games.

Jonny D

Post by sgrsgsrg
I know there is this library but it has some problems. The rendering is
very sluggish in windowed mode, i don't know why but i dont have this
problem with the SFML renderer (it's not the CPU since its usage is approx
0.5%). Disabling the Vsync completely block the app, getting about 0.5 FPS
and max cpu usage. My nvidia drivers are up to date.
Also, someone removed the BlitBatch function from SDL_gpu, forcing the
users to get headaches with TriangleBatch... i don't understand this
decision. Since you already have 50 functions doing nearly the same thing
with 1-2 different parameters, why delete the one that make life easier...
Batch rendering (shown to the used or automated inside RenderCopy) should
be simply included into SDL2. Using third party stuff for core functions
like that sucks... The audio API had unlimited power with its direct access
Smile]
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[rtrussell]

AIUI the patch is OpenGL only. My opinion is that there needs to be a compatible Direct3D implementation before it can go in SDL2.

Richard.

[sgrsgsrg]

I'm on Windows10. I hadnt the opportunity to test on other platforms though.

Those micro stutters are random. Sometimes there are 10 per frame, sometimes 0 for several seconds. I did a printf of the frameTime of my app (calculated with SDL_GetPerformanceCounter/Frequency), and each time a micro stutters appears the frameTime is a bit higher.

[sgrsgsrg]

I can do more tests (like doing modifications in SDL2/SDL2_gfx and recompile) if you have ideas about... what to test [Wink]

[sgrsgsrg]

I have some news.

It's definitely a vSync problem.

If i disable vsync and set a SDL_Delay(1) in my main loop the rendering is as smooth as when i used SDL2 renderer.

If i dont put any delay, the app renders at like 0.2 FPS

Any idea ?

[sgrsgsrg]

Perfectly smooth with vSync + delay(1)

What does that means ?

On my test level (quite empty) each frame i do 25 GPU_Blit, 1 GPU_BlitRotate, 1 GPU_Clear and 1 GPU_Flip, nothing more.

[Jonathan Dearborn]

You might incur a penalty from the OS scheduler because you're hogging all
the CPU time. SDL_Delay() is a way to give back time for the CPU to run
other tasks.

Jonny D

Post by sgrsgsrg
Perfectly smooth with vSync + delay(1)
What does that means ?
On my test level (quite empty) each frame i do 25 GPU_Blit, 1
GPU_BlitRotate, 1 GPU_Clear and 1 GPU_Flip, nothing more.
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[sgrsgsrg]

With vsync but no delay I never use more than 0.7% CPU on my tests but i still have stuttering.

With delay (no matter vsync or not) i have about the same CPU usage but no stutters at all

[sgrsgsrg]

SDL_gpu is still an immediate mode OpenGL renderer right ?

[Jonathan Dearborn]

That depends on what you mean by "immediate mode", which has a loose
definition to many. The programming style wouldn't be any different as far
as SDL_gpu is concerned. You just assume no objects are left from the last
frame, make function calls, and expect them to be done in order.

Technically, SDL_gpu is more retained mode, whereby it buffers your blits
until they need to be sent to the GPU and it uses VBOs so the upload does
not block. These optimizations help tremendously in real use cases.

Jonny D

Post by sgrsgsrg
SDL_gpu is still an immediate mode OpenGL renderer right ?
_______________________________________________
SDL mailing list
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

[Mason Wheeler]

Just saw this, and it looks like no one responded.

No, SDL_gpu has support for multiple GL versions, and if you use higher than 1.0 it doesn't do immediate mode.

Mason