SDL_image

[shaps80]

AFAICT this package wraps just the core SDL library right? So https://github.com/libsdl-org/SDL_image for example is not included? Would it make sense to include that here or as a separate package?

[KevinVitale]

"AFAICT this package wraps just the core SDL library right?"

Correct.

"Would it make sense to include that here or as a separate package?"

It's a good question. A quick survey of the wrappers listed on SDL's webpage suggests there's no standard of expectations:

• this rust wrapper is spotty;
• this python wrapper covers all extensions.

---

At first glance, I'm hesitant to bring extensions into this package: the build process is complicated enough, and this is even without Windows support (which I badly want, and was again investigating when you opened this issue).

I have to give this some thought.

[shaps80]

I get it, and tbh I'd be fine with it being a separate package altogether, it's just something I'm realising is kinda helpful early on. SDL_Font too. These are things that pop up super early in development and prototyping.

I was investigating RayLib (hadn't tried it until now) too. It's really nice and has Immediate-Mode style APIs. But it's also limited in some respects AFAICT. That being said, it's the easiest API I've ever used for drawing and getting an image or text onto the screen.

SDL extensions make this stuff similarly easier, but basically RayLib prompted me to ask the question, cause it can't be understated the usefulness of of a straight-forward API without needing to grab multiple packages etc.

But honestly I don't have a problem with it being separate, just existing at all 😬

I'm not yet familiar enough with how these C-wrappers work otherwise I'd take a stab at it myself. I'm kind surprised this doesn't already exist tbh. Maybe C-interop means we don't need the wrappers as often, but things like your API (Game protocol for example) just make things much nicer in Swift in particular.

Also, Windows is 100% more important for me too, I'm onboard there 👍