Anyone use Fullscreen under Win32?

sdl-news_at_lokigame · October 31, 2000, 7:04pm

I’m just checking to see if anyone out there has ever seen SDL work
well in full-screen mode under Windows?

Under Win2000 and 1.1.5 it would work (sometimes), but it looked really
horrible (dark, flickering display, etc.) on my one test machine. Windowed
mode looked fine. Under Win2000 or Win98 with 1.1.6, starting in fullscreen
mode hangs the computer (black screen):

/* example code, flags includes SDL_FULLSCREEN, bpp_wanted=0 */
screen = SDL_SetVideoMode(640, 480, Options.bpp_wanted, flags);
/* but if we skip SDL_FULLSCREEN, it works fine */

Under Win2000 or Win98 with 1.1.6, SDL_WM_ToggleFullScreen() never does
anything. Both of these methods (starting fullscreen or switching to it)
work fine and flawlessly under x86-linux (Redhat 6.x or Mandrake 7.x). The
Win32 code was produced using the mingwin cross compiler as per the
directions on the SDL homepage (using automake/autoconf, so all the right
flags and libs should be there).

Has anyone ever seen full-screen work under Windows? Is there some other
magic I need to include?

- Wes

sdl-news_at_lokigame · October 31, 2000, 7:31pm

“Westley Weimer” wrote in message
news:8tn53s$b52$1 at ftp.lokigames.com…

I’m just checking to see if anyone out there has ever seen SDL work
well in full-screen mode under Windows?

I use SDL in full-screen mode under windows.

/* example code, flags includes SDL_FULLSCREEN, bpp_wanted=0 */
screen = SDL_SetVideoMode(640, 480, Options.bpp_wanted, flags);
/* but if we skip SDL_FULLSCREEN, it works fine */

Why is bpp_wanted 0? This doesn’t make a lot of sense to me. I use 16
(since my games are optimized for 16 bits), but I also include SDL_ANYFORMAT
in the flags for maximum portability.

Under Win2000 or Win98 with 1.1.6, SDL_WM_ToggleFullScreen() never does
anything. Both of these methods (starting fullscreen or switching to it)
work fine and flawlessly under x86-linux (Redhat 6.x or Mandrake 7.x). The
Win32 code was produced using the mingwin cross compiler as per the
directions on the SDL homepage (using automake/autoconf, so all the right
flags and libs should be there).

I’m not sure about SDL_WM_ToggleFullScreen(), since I’ve never used it. I
think DirectDraw may lose all surfaces in video memory when switching screen
modes (including changes in resolution that don’t affect depth).

Remember that blits can return -2 to indicate a lost surface. Handling lost
surfaces can be tricky.–
Rainer Deyke (root at rainerdeyke.com)
Shareware computer games - http://rainerdeyke.com
"In ihren Reihen zu stehen heisst unter Feinden zu kaempfen" - Abigor

David_Olofson · November 1, 2000, 5:24pm

Tue, 31 Oct 2000 sdl-news at lokigames.com wrote:
[…]

Under Win2000 or Win98 with 1.1.6, SDL_WM_ToggleFullScreen() never does
anything. Both of these methods (starting fullscreen or switching to it)
work fine and flawlessly under x86-linux (Redhat 6.x or Mandrake 7.x). The
Win32 code was produced using the mingwin cross compiler as per the
directions on the SDL homepage (using automake/autoconf, so all the right
flags and libs should be there).

I’m not sure about SDL_WM_ToggleFullScreen(), since I’ve never used it. I
think DirectDraw may lose all surfaces in video memory when switching screen
modes (including changes in resolution that don’t affect depth).

Yep, and that may actually happen even without a DirectX fullscreen app doing
anything - the user switching to another application usually discards all
surfaces. Great fun!

Remember that blits can return -2 to indicate a lost surface. Handling lost
surfaces can be tricky.

Basically, you have to separate the surface initialization from the rest of the
init code, so that it’s safe to call it in the middle of the game if you should
have to. I don’t have much experience with SDL (yet), but the easiest way with
DirectX is to just run the whole surface init sequence again (keep images in
"normal" memory, rather than loading them directly into DX surfaces), whether
or not you really lost all surfaces. Of course, it’s faster, nicer and
slightly more complicated to re-init only the lost surfaces. (May depend on the
design of your engine.)

David Olofson
Programmer
Reologica Instruments AB
david.olofson at reologica.se

slouken · November 12, 2000, 4:32pm

I’m just checking to see if anyone out there has ever seen SDL work
well in full-screen mode under Windows?

Under Win2000 and 1.1.5 it would work (sometimes), but it looked really
horrible (dark, flickering display, etc.) on my one test machine. Windowed
mode looked fine. Under Win2000 or Win98 with 1.1.6, starting in fullscreen
mode hangs the computer (black screen):

/* example code, flags includes SDL_FULLSCREEN, bpp_wanted=0 */
screen = SDL_SetVideoMode(640, 480, Options.bpp_wanted, flags);
/* but if we skip SDL_FULLSCREEN, it works fine */

It sounds like you are assuming things about the flags and hardware
that may not be true. For example, the most common reason for code
to fail on Windows fullscreen and work windowed and on Linux is that
you ask for SDL_HWSURFACE and/or SDL_DOUBLEBUF without fully knowing
the implications. When you ask for SDL_HWSURFACE, you are getting a
surface relating to the actual visible video memory. This means that
you’ll get lots of flicker if you write directly to it. SDL_DOUBLEBUF
means that you are getting a hardware page-flipped surface, and the
surface returned describes the non-visible video page. Also realize
that you can ask for these flags and not get them, which is what is
probably happening in windowed mode and on Linux. You also have to
worry about locking and pitch when dealing with hardware surfaces.

The safest flags to use when first writing SDL video code is SDL_SWSURFACE
with an optional SDL_FULLSCREEN or’ed into it.

See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software