SDL3 request: Fix the software renderer initialization

[iu1j4]

Hello, at first big thank you for the current work on SDL library (SDL2 and SDL1). I really like it and use in few personal projects. I don't like breaking changes in api. I have just ported my sdl1 apps into sdl2 and would like to work more on functionality than porting it again to sdl3 sdl4 sdl5 ... It would be better to write new library with new name to not suggest porting from sdl2 to sdl3 and keep sdl2 in state that you apply bug fixes. What I can suggest you is to fix the library initialization. I use it sometimes on hardware with 3d support and sometimes on hardware without 3d support. Depending on the hardware I have to use: SDL_CreateRenderer() for 3d and: SDL_GetWindowSurface() in pair with SDL_CreateSoftwareRenderer() It would be nice to integrate it into core library. If I create renderer with SDL_RENDERER_SOFTWARE, then the library should call SDL_GetWindowSurface and SDL_CreateSoftwareRenderer. similary: SDL_UpdateWindowSurface() needs to be replaced with SDL_RenderPresent()

And what is the most important - don't drop support for software renderer. Thah is the main reason why I dont use other libs. Fot POS and KIOSK apps there is no nedd to use 3d and the hardware used in such env is very limitted. It would be nice to get some hints howto port sdl2 app into sdl3 (if the api will be simillar) or the info that they are incompatible and needs rewriting the app.

[icculus]

Well, to be fair, the SDL2 API hasn't changed in almost a decade, and we're providing a compatibility layer that will present the SDL2 API using SDL3 behind the scenes, so you're probably covered if you don't want to upgrade.

As for the software renderer: you can force the 2D renderer API to not use hardware acceleration (so it draws to a buffer of pixels that it sends to the screen with SDL_UpdateWindowFramebuffer when you call SDL_RenderPresent).

We are writing a migration guide for SDL2 -> SDL3 conversion. Right now it's just a note added to a text file every time we change an API, because we've only been at this for a few days at the moment; eventually we'll flesh it out to be more verbose, but for now it serves as an authoritative list of all API changes.

(But also, since there's a long way to go on SDL3, it's way to early to be targeting it.)