Initializing SDL 1.3 (Multimonitor)

Hello, all together…

I’ve got yet another question to SDL 1.3 an it’s multimonitor support.
I’ve searched the archive and the web as well, but there’s still a
question left:

On Win32, what’s the correct sequence of commands for creating 2 or more
fullscreen Windows?

So far, here’s what I got:

  • SDL_Init (of course…)
  • SDL_GetNumVideoDisplays()
  • Select the appropriate display and Create a Window with specified size
    and SDL_WINDOW_FULLSCREEN flag
  • Do some tasks and call SDL_ShowWindow

It work’s great if all Windows are created with the same size as the
resolution of the desktop of every screen was at the time of
initializing SDL, but when I try to specify some other size (800x600
Pixels e.g. on former 1280x1024 and 1024x768 displays), the first Window
get’s positioned correctly, but the seccond one is initialized at 480
pixels right of the top left corner of the 2. screen (1280-800). A
second problem is, that somehow the Event-Queue gets filled with events
if that happens, and the SDL_PollEvent command never returns from the
first call…

I took a look a the code and as far as I could understand it, the
position of a newly created Window is calculated using the coordinates
of the desktop-position of every display, which is being read on
initialization of SDL - is that correct?

At the moment, my workaround is to set all displays to the desired
resolution prior to SDL initialization using standard Windows-API, is
there any more elegant solution using SDL, or did I miss something?

I hope I didn’t mess up with some other facts here - anyhow, thanks in
advance for your thoughts…

Best regards,

Alexander Hofmann.

PS: As you might already have noticed, I’m no native English speaker; so
please excuse any bad mistakes…

-------------- next part --------------
A non-text attachment was scrubbed…
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20110125/634816b1/attachment.pgp

This is a bug in SDL, and I’ve entered it into bugzilla for tracking:
http://bugzilla.libsdl.org/show_bug.cgi?id=1106

Thanks!On Tue, Jan 25, 2011 at 8:45 AM, Alexander Hofmann < alexander.hofmann at new-h.de> wrote:

Hello, all together…

I’ve got yet another question to SDL 1.3 an it’s multimonitor support.
I’ve searched the archive and the web as well, but there’s still a
question left:

On Win32, what’s the correct sequence of commands for creating 2 or more
fullscreen Windows?

So far, here’s what I got:

  • SDL_Init (of course…)
  • SDL_GetNumVideoDisplays()
  • Select the appropriate display and Create a Window with specified size
    and SDL_WINDOW_FULLSCREEN flag
  • Do some tasks and call SDL_ShowWindow

It work’s great if all Windows are created with the same size as the
resolution of the desktop of every screen was at the time of
initializing SDL, but when I try to specify some other size (800x600
Pixels e.g. on former 1280x1024 and 1024x768 displays), the first Window
get’s positioned correctly, but the seccond one is initialized at 480
pixels right of the top left corner of the 2. screen (1280-800). A
second problem is, that somehow the Event-Queue gets filled with events
if that happens, and the SDL_PollEvent command never returns from the
first call…

I took a look a the code and as far as I could understand it, the
position of a newly created Window is calculated using the coordinates
of the desktop-position of every display, which is being read on
initialization of SDL - is that correct?

At the moment, my workaround is to set all displays to the desired
resolution prior to SDL initialization using standard Windows-API, is
there any more elegant solution using SDL, or did I miss something?

I hope I didn’t mess up with some other facts here - anyhow, thanks in
advance for your thoughts…

Best regards,

Alexander Hofmann.

PS: As you might already have noticed, I’m no native English speaker; so
please excuse any bad mistakes…


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


-Sam Lantinga, Founder and President, Galaxy Gameworks LLC

I’ve updated this bug in bugzilla:

I just did a bunch of work on multi-monitor and fullscreen support on Windows.

The way you set things up changed a little bit. Create each of your windows
with the desired size and the fullscreen flag, and use this macro for the
position: SDL_WINDOWPOS_CENTERED_DISPLAY(N), where N is the index of the
display you want to create the window on.

e.g.
window = SDL_CreateWindow(“Window on Monitor 1”,
SDL_WINDOWPOS_CENTERED_DISPLAY(1),
SDL_WINDOWPOS_CENTERED_DISPLAY(1),
640, 480, SDL_WINDOW_FULLSCREEN|SDL_WINDOW_SHOWN);

Can you try the latest snapshot and see if this works for you?
http://www.libsdl.org/tmp/SDL-1.3.zip

Thanks!On Tue, Jan 25, 2011 at 8:45 AM, Alexander Hofmann < alexander.hofmann at new-h.de> wrote:

Hello, all together…

I’ve got yet another question to SDL 1.3 an it’s multimonitor support.
I’ve searched the archive and the web as well, but there’s still a
question left:

On Win32, what’s the correct sequence of commands for creating 2 or more
fullscreen Windows?

So far, here’s what I got:

  • SDL_Init (of course…)
  • SDL_GetNumVideoDisplays()
  • Select the appropriate display and Create a Window with specified size
    and SDL_WINDOW_FULLSCREEN flag
  • Do some tasks and call SDL_ShowWindow

It work’s great if all Windows are created with the same size as the
resolution of the desktop of every screen was at the time of
initializing SDL, but when I try to specify some other size (800x600
Pixels e.g. on former 1280x1024 and 1024x768 displays), the first Window
get’s positioned correctly, but the seccond one is initialized at 480
pixels right of the top left corner of the 2. screen (1280-800). A
second problem is, that somehow the Event-Queue gets filled with events
if that happens, and the SDL_PollEvent command never returns from the
first call…

I took a look a the code and as far as I could understand it, the
position of a newly created Window is calculated using the coordinates
of the desktop-position of every display, which is being read on
initialization of SDL - is that correct?

At the moment, my workaround is to set all displays to the desired
resolution prior to SDL initialization using standard Windows-API, is
there any more elegant solution using SDL, or did I miss something?

I hope I didn’t mess up with some other facts here - anyhow, thanks in
advance for your thoughts…

Best regards,

Alexander Hofmann.

PS: As you might already have noticed, I’m no native English speaker; so
please excuse any bad mistakes…


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


-Sam Lantinga, Founder and CEO, Galaxy Gameworks

I finally got around to testing this (on a new project) and it does work, but it seems to have some caveats. Or possibly, my own code has bugs. I’m still investigating so I’m not ready to file bugs yet.

Test machine has 3 monitors of various sizes, Two NVidia cards, and runs Windows 7 64bit. Compiling with MinGW32.

  • Works as expected with OpenGL and when Windowed.
  • I call SDL_GL_MakeCurrent to set the current display/context, SDL_GL_SwapWindow with the correct Window.
  • Best behavior required me to destroy all Windows and reassign the GL contexts with SDL_GL_MakeCurrent. Otherwise I lacked focus. Even when I want to go from 3 to 1, best behavior was to destroy them all and recreate #1.
  • Full Screen OpenGL, the main monitor updates, and the additional monitors stay static with their 1st frame.
  • Toggling back and forth fullscreen and windowed by destroying windows eventually caused a crash. Though so far, I’ve only been able to reproduce this once.

Things to try:

Okay, I was able to make my code dramatically more stable by never deleting my OpenGL contexts. I was able to create and destroy 300 windows without any problems.

(highlighted for my own benefit)

Also, I was able to make all 3 monitors update in Full Screen, but ONLY if I alt-tabbed to a non-primary screen. As long as the Primary was out of focus, all 3 would update.

That said, if the Primary was in focus, clicking on any screen causes a flash each time a different screen was clicked, with no non-primary screens animating. Notably, GL performance was faster when the Primary was in focus.

If the non-primary screens were in focus (via alt-tab), you could safely click on either non-primary screen. Clicking on the Primary however caused the same flash as before, the Primary to take focus, and the non-primaries to again stop animating.

Of note, performance is best in Full Screen with the Primary selected. Windowed or non-primary in focus is noticeably worse.

I wonder if updating my NVidia drivers will make a difference?

Anyways, I’m just sharing notes. I’m still not satisfied that I’ve done all I can yet, so I’m going to try a few more things before I formalize this as a bug report.------------------------
| Mike Kasprzak | Sykhronics Entertainment (http://www.sykhronics.com) | Blog (http://www.toonormal.com) | Twitter (http://www.twitter.com/mikekasprzak) | Ludum Dare (http://ludumdare.com) |

Okay! Upgrading NVidia drivers solved the multi-monitor rendering problem. Huzzah!

The only thing left is that clicking on different screens causes a flash. However, I should be able to work around this by constraining the mouse to a single display, and moving a virtual cursor across the displays. I’m not sure if this is fixable anyway. Though it’s inconsistent with windowed App behavior, it could very well be a Windows limitation. TBH, I don’t really know of any games that support Multi-Monitor Full Screen anyway, so I can’t exactly point to a reference. shrug------------------------
| Mike Kasprzak | Sykhronics Entertainment (http://www.sykhronics.com) | Blog (http://www.toonormal.com) | Twitter (http://www.twitter.com/mikekasprzak) | Ludum Dare (http://ludumdare.com) |