SDL 3.0

SDL Development
41

where can I read about the upcoming SDL_GPU subsystem?

I’ve collected some FAQs and summary info here:

3 Likes
42

thank you! looks great)

1 Like
43

But how are SDL2 releases being made during SDL3 development?

44

Right now, fixes are trickling into SDL2; so far we have made point releases with a handful of fixes (2.26.2 shipped a few weeks ago).

I assume we’re going to reevaluate this as time goes on, and that depends what state SDL3 is in vs what SDL2 needs to stay viable while SDL3 is still in progress, but in the short term, I think we’re largely just doing small fixes to SDL2 right now, instead of blocking large tasks off into SDL2 milestones.

45

What about the patch for Surface glitching, is that going to be in SDL2, SDL3, or neither of them? Also, is anything known for bad UTF-8 in Android clipboard?

46

I don’t know off the top of my head; did these ever make it to the bug tracker? If not, we’re extremely likely to forget to look into them at all, as we’re pretty overwhelmed with pending tasks right now, and the bug tracker is our collective memory of these things.

47

The window surface issue was fixed for SDL3: Make SDL_GetWindowSurface HighDPI aware by ericwa · Pull Request #7069 · libsdl-org/SDL · GitHub

It doesn’t look like it’s been backported to SDL2 (yet?)

1 Like
48

Can we get a SDL_LockTexture that DOESN’T zero-wipe the entire data-buffer?

I’m making a cross-platform text-editor… the text editor has a flashing “caret” (insertion marker). I have to redraw the entire screen every time… because on each draw-frame, the memory gets wiped. Just to redraw a few pixels for the caret, I gotta redraw the entire screen.

I tested this on my profiler, about 98% of my applications energy is going into screen drawing. And also, my app is usually the highest energy-consuming app I’m using.

I don’t mind if this isn’t possible on ALL platforms, but it must be possible on SOME platforms. I really can’t see why you need to zero-wipe a buffer just to be able to draw it. I’ve never seen this before, not even in OpenGL. (On the same hardware).

49

Just cache your pixels in the separate array them memcpy it into target.

50

Isn’t the text cursor done by a color inversion? So it’s xor 0xFFFFFF each time without losing any data on the rendered text. It is also possible that most of the processing power is coming from the font rasterizer (for instance, FreeType is especially bloated nowadays); in the case of TrueType rendering, there is not much that can be done, since the only fast TrueType renderer of reasonable quality is owned by Microsoft and used in GDI and cannot be used in cross-platform, and the Microsoft’s rasterizer is a very specific algorithm that no one knows and it is extremely difficult to get a pixel-perfect match of it (FreeType 2.10.3 literally added a dirty compatibility hack by introducing a magic offset to imitate the rounding bias of a recursive subdivision).

51

Indeed. Invert-plotting can be achieved with a custom blend mode:

invertop = SDL_ComposeCustomBlendMode(SDL_BLENDFACTOR_ONE_MINUS_DST_COLOR, 
		SDL_BLENDFACTOR_ONE_MINUS_SRC_COLOR, SDL_BLENDOPERATION_ADD, 
		SDL_BLENDFACTOR_ZERO, SDL_BLENDFACTOR_ONE, SDL_BLENDOPERATION_ADD);

Set the source to your caret (cursor) shape, with black (0x000000) where you want no change and white (0xFFFFFF) where you want inversion.

52

I don’t know if you have bigger build system changes planned, but if you continue with autotools / providing .m4 file, please consider properly namespacing also it, for the benefit of programs / suites that support both building against sdl2 and building against sdl3. (Or like our exact use-case will likely be: have optional sdl2 components, and optional sdl3 components)
As for sdl2, we have carried a modified version of sdl2.m4 that does not conflict with sdl.m4.

(S3_0 is the last version where we had also sdl.m4 present)

53

lovely! How are yo u doing that?

54

Using routines in SDL2_gfxPrimitives.c, such as aaFilledPolygonRGBA() and aaBezierRGBA().

55

Please consider adding high DPI support for windows. Also see: WIP - Windows high-DPI support

56

High DPI support was added for Windows in SDL2 (2.24.0) a year ago, using Eric’s work. It uses slightly different APIs to activate it compared to other platforms (in SDL2 at least) because Windows doesn’t make per-window DPI scaling easy.

57

I just saw that SDL_GameControllerGetBindForAxis() and SDL_GameControllerGetBindForButton() have been removed from SDL 3. Please add them back in.

My project (currently in the process of converting from SDL2 to SDL3) internally uses the joystick API for gamepad support. I only use the gamepad API to set up the default input map, which can then be modified by the user. This has the following advantages:

  • I can use gamepads for which no mapping exists.
  • If a gamepad has “extra” unmapped inputs, I can use them.

Anyway, I need SDL_GameControllerGetBindForAxis() and SDL_GameControllerGetBindForButton() functionality for this. I can either use functionality supplied by SDL or I can write my own, and I’d rather not write my own, for obvious reasons. Just skipping the joystick API in favor of the gamepad API is not an option.

2 Likes
58

FWIW, I’m doing basically the same in an SDL2 project, so I too would prefer for these functions to be available in SDL3.

Also, I guess it’d be hard to provide them in the compat libsdl2 implemented on top of SDL3 if they’re removed without a replacement?

59

I removed them because they don’t fully represent the capabilities of the mapping system (you can bind multiple inputs and outputs) and I wasn’t aware of anyone else using them.

I can add them back in though if they’re helpful to people. Thanks for the feedback!

1 Like
60

I replaced those functions with SDL_GetGamepadBindings(), which provide the full set of bindings for a gamepad.

2 Likes