   SDL_ListModes
  HiI'm working in a fullscreen SDL game, but there are many different screen dimensions, and i wanted a function that could set my game screen to fit all the monitor screen, and i found SDL_ListModes. It will give me an pointer to an array with all the screen dimensions supported, but how can i use those dimensions? Can i call SDL_ListModes before SDL_SetVideoMode and use the pointer in the SDL_SetVideoMode to fit my game screen to the monitor screen?I'm pretty confused with making SDL pick the best screen resolution of the monitor screen and applying that resolution to my game screen.   
  SDL_ListModes() simply supplies you with information regarding what video modes are supported. Once you have that information, you can select a mode and then call SDL_SetVideoMode() with appropriate width, height, and color depth arguments.As for this part of your question:Quote:Can i call SDL_ListModes before SDL_SetVideoMode and use the pointer in the SDL_SetVideoMode to fit my game screen to the monitor screen?Yes, you would call SDL_ListModes() before calling SDL_SetVideoMode(), as described above. However, you don't use the pointer returned by SDL_ListModes() directly with SDL_SetVideoMode(); rather, you simply extract the information that you're interested in (width, height, color depth), and then use that information when setting the video mode.   ;  Thanks for the info, its working just how i wanted. In the two monitors where i have tested the program the position 0 of the array corresponds to the biggest screen dimension, but in the SDL libs it says "The array is not guaranteed to be sorted in any particular order.". In what cases does the position 0 of the array doesn't correspond to the biggest screen dimension available?   ;  What they are saying is you cannot rely on the list being sorted. You need to search the list for the biggest one if you want to use that as the default.An example of a case where the first item isn't the largest is a platform which enumerates display modes with the current mode first (or last), making it easy to do a "reasonable" default. Or perhaps they are returned in the reverse order than you expect.The bottom line is you must understand what it means when an API doesn't guarantee something. It means that it cannot guarantee it, so you have to code around it or you end up relying on specific implementation details that may change in future. This is not the way to write robust code.   