Future 3D API...

SDL Development
4

You know what you’re doing and I look forward to trying it out.

Will the reworked 2D stuff be good for rendering a UI or HUD over the 3D stuff?

5

One could theoretically do this, but it wouldn’t be hard to render textured quads directly and avoid the extra complexity.

I think it would be more desirable to do a little 3D in a mostly 2D game (think about the rotating mountain menu in the otherwise 2D game Celeste, or maybe adding some cool post-processing effect to any 2D game).

1 Like
6

This is very exciting to read about, I’m looking forward to seeing what gets made!

Do you know yet what these changes might look like to a casual user of SDL? e.g. would this maybe bump the version to SDL3, or would the new API perhaps be a new subsystem that needs Initing?

7

would the new API perhaps be a new subsystem that needs Initing?

It’s probably going to work like the 2D API; you have to init SDL_INIT_VIDEO and then SDL_Create3DRenderer() (or whatever) will do the rest.

A mythical SDL3 would not be for adding something, it would be for changing or removing things.

1 Like
8

Yes, but please consider bumping the middle number (‘minor version’) because so far every release of SDL2 has apparently been just a ‘patch’ (which implies nothing added either). I’ve never understood this misuse of the semantic versioning style.

9

We don’t use semantic versioning.

10

We should probably document the threading rules for existing backends while we’re at it. When asked if XYZ render or video backend supports rendering from another thread, the answer tends to be “if it works when you do that, then yes”. Sometimes it depends on both video and renderer backends together.

We had some code in the Wayland backend (handling the surface suspension stuff) that assumed that nobody else would be reading from the display connection at the same time. That turned into random deadlocks in 2.0.16. Rendering from another thread worked before, so somebody decided to take a dependency on it.

11

The renderer part of that is documented in the SDL_Render header file – SDL_Render can only be used from the main thread. (Whatever happens if you break that rule is implementation/platform-dependent.)

SDL’s windowing APIs are pretty much the same thing. For full cross-platform compatibility you can only use them on the main thread. What happens when you break that promise depends on the platform. On macOS and iOS, the OS will prevent you from making calls off the main thread.

12

I think “threading rules” was too strong of a word. Maybe “thread assumptions made by app developers” is a better description :wink:

I wrote some of that thread-unsafe code in the Wayland backend based on the assumption that folks would play by the documented rules. We only found that wasn’t the case after it caused problems in real apps. Once we knew about the dependency, we could fix it by using the proper thread-safe APIs.

I don’t think we can wind back the clock on the existing apps out there, but we can at least document the current state of things to make sure we don’t step on any landmines with similar stuff in the future.

13

Perhaps you should! Three numbers separated by dots sure looks like semantic versioning.

14

I would question whether the contents of a header file qualifies as ‘documentation’. Everything of importance should be in, or at least linked from, the wiki.

15

Just adding basic ideas, that I gathered and thought a while ago, and that would still fit with the 2d backends:

  • Provide a shader manager in the generic layer (eg SDL_render.c), to:
    • lighten back-end from caching/storing/compiling(?) their internal shaders.
    • allow user to interact with it, for instance to use its own shaders.
      and do something:
      • SDL_PushUserShader()
      • SDL_RenderCopy()
      • SDL_PopUserShader()
        Won’t be supported by the SW renderer of course, but if it’s a no-op and the shader isn’t too fancy, a game could remain playable.
        That can be extended, with some function to add a uniform variable SDL_RenderAddUniform()

That provides some 3d capabilities, but not sure if this makes senses technically will all back-ends.
Of course this may be not as good as real GL with all the possible customization, and if this match a real user need.

16

All function documentation automatically bridges between the headers and wiki now; commits that change the doxygen will automatically land on the wiki and vice versa.

For example, this commit:

Automatically became this in the wiki:

This doesn’t yet cover every part of the headers, but already the vast majority of them are bidirectionally bridged like this.

17

I think there’s going to be a lot of decisions about what adds functionality and what adds usability.

I’m hesitant to add any 3D things to the existing 2D API if this works out, but I do like the idea of users being able to pick the level of complexity they can handle: 2D, 3D, or some helper functions on top of 3D to make it easier.

There’s a real risk in bloating the API though. We’re going to have to be careful.

18

“Risk” implies uncertainty. I would call it an inevitability: to even reach what’s considered “table stakes” levels of 3D functionality today, the amount of API surface you’re going to need to add will dwarf the entirety of what SDL is right now. If you don’t, you’ll end up with a 3D product no one will want to use.

19

I vote in favour of keeping the bloat down. This ethos is what makes SDL so great and sets it apart from other libraries / engines.

Speaking of which, when will the deprecated functionality of SDL2 be removed? A lot of new stuff has been added and the size is creeping up. Stuff like the addition of float coordinates make the integer functions redundant. I hope SDL3 isn’t going to remain a myth.

1 Like
20

This isn’t true, at least in terms of rendering.

Now once you start dropping in .obj loaders and stuff, yeah, it’s easy to put in the whole kitchen sink, and we’ll definitely try to avoid that.

Having a separate SDL_obj or SDL_gtlf library wouldn’t suck, though.

2 Likes
21

OK, so I won’t go into object loaders or how you didn’t even mention FBX and Blender format, probably the two most relevant object file formats in all of gamedev. Let’s just talk about rendering.

You mentioned custom shaders. If you want to render 3D geometry with shaders, people are going to want a way to use the same basic shader for multiple models, but with different parameters. So you need a concept of Materials.

Once people start rendering scenes composed of more than one 3D model, lighting becomes crucial. So now you need an API for Lights. Then you need ways to determine how to deal with multiple Lights shining on the same texel. So you need a Forward or a Deferred rendering algorithm, or preferably both and an API to choose between them.

Once people start lighting scenes, they’re going to discover that rendering even halfway decent lighting is very computationally expensive, and the bulk of that computation is redundant because it doesn’t change from frame to frame. So you need a concept of baking and applying lighting maps.

Once people have scenes, they’re going to want to not just place things in the scene but also move them around. They don’t want solid objects clipping through each other, so you need a concept of a 3D collision geometry simulator. (Even without a full physics engine, which I agree is beyond the scope of SDL, you will need a collision system.)

Once people start moving things around, they’re going to want them to move in a lifelike manner. So you need a concept of Animations, and a way to transition smoothly between Animations.

Once people move objects around, they’ll want to connect objects so they will move together, such as a person picking up a weapon and holding it in their hand so that it will move together with the hand in a visually correct way. So you need a hierarchical Scene Graph API.

And so on. If you do not have APIs for these basic things, no one will want to use SDL for even simple 3D rendering when engines such as Unity and Unreal provide them all, for free, out of the box. As I said above, this is table stakes for 3D. Like giving a mouse a cookie or boiling up a pot of stone soup, once you take the first step there are tons of other things that will inevitably be pulled into even the Minimum Viable Product, and any product that doesn’t end up containing them will not be viable.

22

You’re describing a game engine, not a rendering API.

4 Likes
23

Hello, I’m a newbie testing out SDL2.

May I request for a Youtube video of the future of SDL2?

It’s easier to watch a video of what you’re planning to do.