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)
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
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 DOn Thu, Sep 8, 2016 at 5:34 AM, sgrsgsrg wrote:
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
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
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:
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 DOn Sun, Sep 11, 2016 at 2:30 PM, sgrsgsrg wrote:
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 [image:
Smile]
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.
What if you leave vsync enabled but just add a delay? It sounds like you’re
running hot and getting throttled by the OS or the driver.On Mon, Sep 12, 2016 at 3:33 PM, sgrsgsrg wrote:
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
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 DOn Tue, Sep 13, 2016 at 12:03 PM, sgrsgsrg wrote:
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.
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 DOn Wed, Sep 21, 2016 at 11:13 AM, sgrsgsrg wrote:
SDL_gpu is still an immediate mode OpenGL renderer right ?
This has been done now, in the latest mercurial. All the 2D drawing methods now have an additional float version.
Also, batching is now done in the background, so drawing is sent to the GPU in one go. Not quite a batched version of the SDL_RenderCopy, but still quite a bit faster.
This is great, but what’s the likelihood of an updated SDL2_gfx to take advantage of it? Sub-pixel-accurate plotting of thick lines and arcs, filled polygons and ellipses etc. would be really nice. Is SDL2_gfx actively maintained?
