Switching rendering method at runtime |
GameCodingNinja
|
I did have it working at one time but I think a newer version of SDL caused it to then error out.
Running both is not supported so you can try at your own risk. When I had them both running, I used the software rendering to display my loading animation. Worked perfectly for that while it lasted. Why do you want to run both? |
|||||||||||
|
AmigaBlitter
|
Thank you for the reply.
"Why do you want to run both?" I have three rendering engine, actually. Some video cards may run faster in openGL mode, while some other card may use the third engine. Software mode should be the fallback mode in case none of the other drivers are available. Being able to switch this at runtime would be cool. |
|||||||||||
|
GameCodingNinja
|
Having a software rendering mode as a fall back may have been a good idea back in the mid 90's, today it's just a waist of your time. Chances are you put a bunch of effort into supporting SDL software rendering capabilities and you just want make use of all that hard work. I understand where you are coming from but splitting your time between the two is a waist of effort. If there is even one person who would need to fall back on that software rendering, they will not be happy because they want the speed and look that comes from hardware rendering. Also, your engine design can be greatly simplified by just supporting OpenGL, which runs on everything.
|
|||||||||||
|
Switching rendering method at runtime |
Sik
|
2016-10-29 17:22 GMT-03:00, GameCodingNinja:
Eh, with 2D stuff it may still be fast enough, and I've seen cases where hardware rendering wasn't a good thing (e.g. some magnifiers have trouble with GPU-rendered stuff). As for the original question, I don't think you can switch renderers on the same window. Maybe with some trickery involving creating and destroying renderers without destroying the window, but try at your own risk (I doubt this would work honestly). _______________________________________________ SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||
|
GameCodingNinja
|
That might be the case for some very old hardware no one is currently using and anyone one using it would not be looking to play "today's" games on it. So it's a moot point. It's hard enough just to come up with a game idea that is doable and actually finish it. To split your time between two very different API's which will force you to gimp OpenGL, doesn't make a lot of sense. There's a lot of cool things you can do with OpneGL that can't be done with the old SDL render API. Also, the more you know about OpenGL, the more marketable you are in the job market. There are no employers looking for SDL Render API experience. That should tell you all you need to know. |
|||||||||||||
|
Switching rendering method at runtime |
Jonas Thiem
Guest
|
Not much trickery though:
I remember destroying renderers and recreating them without issue to switch between OGL and Software at runtime. Works exactly as you'd expect it. Of course you need to download & re-upload/recreate all SDL_Texture's on-the-fly yourself, but if you wrapped them in some custom wrapping struct instead of using SDL_Texture's directly with some global list of all your structs it's not that hard to do. I don't recall if I destroyed the window as well, but again that's not really hard to do in addition if it doesn't work without doing that. Â Just obtain old size, and resize new window immediately to old size again. The only effort is really re-creating textures as described above. On Sat, 2016-10-29 at 19:04 -0300, Sik the hedgehog wrote:
SDL mailing list http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org |
|||||||||||||||
|