Does SDL2 SDL_Quit require TTF_Quit, SDL_DestroyWindow, etc?

Game Development
1

This question pertains only to version SDL2 and above.

  1. Does using SDL2 SDL_Quit require TTF_Quit, SDL_DestroyWindow, etc?
  2. Will SDL_Quit find and destroy memory allocated to SDL2 Windows, Surfaces, Textures, TTF fonts, Files, etc?
  3. Must each subsystem be independently destroyed?
  4. If just SDL_Quit is used and the program is exited, shouldn’t the OS reclaim all previously allocated memory?
  5. What are the “bad” things that happen if only SDL_Quit is used?

Thanks :blush:

2

If you are going to terminate the process - you can not free anything
But aesthetically better to do this before quit

3

SDL_Quit() will clean up most (but not all!) objects created during use of the library (including windows, textures, etc). You aren’t required to clean up everything yourself, but it’s safe to do it, too (and often a good practice).

No, SDL_Quit() gets them all.

If the program exits, the OS will reclaim all allocated memory no matter what…however, there are some platforms where, if you changed the video mode of the display by making a fullscreen window, it might stay at the changed resolution if you don’t call SDL_Quit() to reset it.

There are some things that aren’t cleaned up by SDL_Quit(), like SDL_RWops objects. I don’t have a complete list. But most things–opened audio devices, created windows, renderers and textures, etc–are kept in lists internally and all will be closed during SDL_Quit() if the app didn’t do it already.

But everything (except the video mode on a handful of platforms) is closed, free’d, and otherwise disposed of when the process terminates, without SDL’s intervention, of course.

4

Thanks Icculas, this was exactly the type of information I was looking for. Thanks for not only providing an answer but an explanation too.

I can see the need for surface and texture destroy if multiple windows are being used or a lot of graphics are being manipulated, but for the purpose of quitting it did not seem necessary. I have seen other programming habits due to mis-understandings of the operating system. The only fear I had was perhaps there was a machine “state” config file that could have been corrupted - or something like that.

Older platforms of the 1970’s had memory leak problems that the OS could not reclaim but the Intel line of processors using virtual segmented memory for each program eliminates orphaned processes, memory, damens, etc. IBM mainframes were not well behaved in this way.

I appreciate the full screen video problem. This problem dates back to DOS!