/* We will use this renderer to draw into this window every frame. */
static SDL_Window *window = NULL;
static SDL_Renderer *renderer = NULL;
/* This function runs once at shutdown. */
void SDL_AppQuit(void *appstate, SDL_AppResult result)
{
/* SDL will clean up the window/renderer for us. */
}
I don’t understand why. Because of it’s static’s and it is local for the file? Why it doesn’t call SDL_Quit()?
This is called once before terminating the app–assuming the app isn’t being forcibly killed or crashed–as a last chance to clean up. After this returns, SDL will call SDL_Quit so the app doesn’t have to (but it’s safe for the app to call it, too).
The SDL_Quit() should not be called but the official examples doesn’t destroy a window and a renderer: SDL_DestroyWindow(app->window)
As the comment in the above example says:
“SDL will clean up the window/renderer for us”, which means that SDL will destroy the created window(s) and renderer(s) for you after SDL_AppQuit is finished.
About SDL_Quit. SDL_Quit is called by SDL on shutdown but it’s perfectly safe to call it in SDL_AppQuit.
It is 100% safe to destroy the window, but SDL_Quit()–which gets called right after SDL_AppQuit()–will also clean this up for you. SDL keeps a list of existing windows internally, so it knows what to destroy during SDL_Quit(), if you haven’t already done it yourself.
This is true for a lot of SDL objects, but not all of them. Documentation about what things SDL can clean up for you like this isn’t great at the moment (I think there’s a bug report somewhere to fix that…) but windows are one of them.
OpenGL contexts, however, are not, so you are right to destroy it.
SDL_Quit() can be called multiple times without causing problems, so you can call it explicitly if you like, even though it’ll be called again after SDL_AppQuit, and do nothing.
So your code is right, even though you technically didn’t need to destroy the window, I think it’s more correct to do it anyhow, so there’s balance in your app and it’s clear to everyone that the thing is going away and not leaking. We don’t do it in the example programs because we’re trying to keep the lines of code in the examples low, and demonstrate that you don’t have to worry about destroying windows if you don’t want to…but as you can see, this can cause confusion sometimes too.