The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

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.

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

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






On Thu, Sep 8, 2016 at 5:34 AM, 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

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

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








On Sun, Sep 11, 2016 at 2:30 PM, sgrsgsrg wrote:

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.

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.

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

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 ?

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:

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.

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




On Tue, Sep 13, 2016 at 12:03 PM, sgrsgsrg wrote:

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

SDL_gpu is still an immediate mode OpenGL renderer right ?

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





On Wed, Sep 21, 2016 at 11:13 AM, sgrsgsrg wrote: