SDL in virtual machines

SDL Development
1

Hi List.

I guess my question regarding fullscreen toggling didn’t interest anyone - I
don’t blame you considering that the limitations of win32 SDL are pointed
out in some FAQs and other info available on the main website. The fact that
I came to that information rather late, however, is because I was googling
and coding for quite a bit, trying out many different potential solutions –
so the problem was lack of direction, not effort. It would be nice to know
if anyone has suggestions for workarounds, or if any info is available
regarding eventual releases of either SDL 1.2 or 1.3.

A new phenomenon of interest has cropped up: I tried using virtualbox to
code for win32 (I can only abide booting the whole machine in windows for so
long), and the program works, but the mouse input goes haywire. I know far
too little about how virtual machines interact with OS scheduling and other
performance impactors, so I was wondering if anyone knows how a virtual
machine will affect SDL’s input mechanisms for mouse and if there’s anything
to say about it that should give me the appropriate cautions.

Thanks!

Christian

2

I guess my question regarding fullscreen toggling didn’t interest anyone - I
don’t blame you considering that the limitations of win32 SDL are pointed
out in some FAQs and other info available on the main website. The fact that
I came to that information rather late, however, is because I was googling
and coding for quite a bit, trying out many different potential solutions –
so the problem was lack of direction, not effort. It would be nice to know
if anyone has suggestions for workarounds, or if any info is available
regarding eventual releases of either SDL 1.2 or 1.3.

Sorry that no one picked up your post.

The right solution is to reload your graphical assets every time you
lose your OpenGL context. How are you currently dealing with this?

I recall some mention of an SDL_Event type that would alert you to the
loss of OpenGL context, but I haven’t used MSWindows for so long that
I have allowed myself to be ignorant of such matters.

A new phenomenon of interest has cropped up: I tried using virtualbox to
code for win32 (I can only abide booting the whole machine in windows for so
long), and the program works, but the mouse input goes haywire. I know far
too little about how virtual machines interact with OS scheduling and other
performance impactors, so I was wondering if anyone knows how a virtual
machine will affect SDL’s input mechanisms for mouse and if there’s anything
to say about it that should give me the appropriate cautions.

Have you tried other emulators?On Thu, Jun 3, 2010 at 3:27 PM, Christian Leger <chrism.leger at gmail.com> wrote:

–
http://codebad.com/

3

Thanks for your input Donny.

I did find out that the recommended reaction to losing OpenGL context is to
reload resources and states. I found this a bit sad, since from what I
gather it is not necessary, but it’s something SDL doesn’t yet have the
facilities to avoid. On the other hand, it’s not a bad idea to have neatly
organized texture and state reloading routines, so I guess I’ll do that. I
haven’t tried it yet, but it’s on my list.

One solution I considered to circumvent the fullscreen issue is to simulate
fullscreen by resizing the window, repositioning it, and removing the frame.
Is there an obvious flaw in this approach?

I haven’t tried other virtual machines than virtualbox. Have you had success
running realtime 3D sdl/opengl applications in a virtual machine of some
kind? I’m rather certain performance is not the fundamental problem, since
my program currently runs an order of magnitude faster than it needs to in
native mode. In fact, the problem I was encountering, to the best of my
ability to determine, is that mouse deltas were greatly exaggerated. If I
had a way to mitigate this it would be fun.

Thanks!

ChristianOn Thu, Jun 3, 2010 at 3:41 PM, Donny Viszneki <donny.viszneki at gmail.com>wrote:

On Thu, Jun 3, 2010 at 3:27 PM, Christian Leger <@Christian_Leger> wrote:

I guess my question regarding fullscreen toggling didn’t interest anyone

  • I

don’t blame you considering that the limitations of win32 SDL are pointed
out in some FAQs and other info available on the main website. The fact
that
I came to that information rather late, however, is because I was
googling
and coding for quite a bit, trying out many different potential solutions
–
so the problem was lack of direction, not effort. It would be nice to
know
if anyone has suggestions for workarounds, or if any info is available
regarding eventual releases of either SDL 1.2 or 1.3.

Sorry that no one picked up your post.

The right solution is to reload your graphical assets every time you
lose your OpenGL context. How are you currently dealing with this?

I recall some mention of an SDL_Event type that would alert you to the
loss of OpenGL context, but I haven’t used MSWindows for so long that
I have allowed myself to be ignorant of such matters.

A new phenomenon of interest has cropped up: I tried using virtualbox to
code for win32 (I can only abide booting the whole machine in windows for
so
long), and the program works, but the mouse input goes haywire. I know
far
too little about how virtual machines interact with OS scheduling and
other
performance impactors, so I was wondering if anyone knows how a virtual
machine will affect SDL’s input mechanisms for mouse and if there’s
anything
to say about it that should give me the appropriate cautions.

Have you tried other emulators?

–
http://codebad.com/

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

4

One solution I considered to circumvent the fullscreen issue is to simulate
fullscreen by resizing the window, repositioning it, and removing the frame.
Is there an obvious flaw in this approach?

Only the potential for extra scaling overhead, and that the extra
stuff you’re doing doesn’t come with SDL APIs :slight_smile:

I haven’t tried other virtual machines than virtualbox. Have you had success
running realtime 3D sdl/opengl applications in a virtual machine of some
kind? I’m rather certain performance is not the fundamental problem, since
my program currently runs an order of magnitude faster than it needs to in
native mode. In fact, the problem I was encountering, to the best of my
ability to determine, is that mouse deltas were greatly exaggerated. If I
had a way to mitigate this it would be fun.

No, however I’ve always been very interested in it.

OpenLINA is a virtualization solution that has attempted to tackle the
performance issues related to multimedia apps. Of course it’s more for
running Linux on Windows than the other way around…

How often do you have to test performance-critical code on Windows anyway?

Good luck :)On Thu, Jun 3, 2010 at 4:13 PM, Christian Leger <chrism.leger at gmail.com> wrote:

–
http://codebad.com/

5

SDL_SetVideoMode with the flag SDL_FULLSCREEN set has worked for me in the past on Windows XP.
SDL_ToggleFullscreen or whatever it was, however, had not.------------------------
EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/

6

SDL_ToggleFullscreen() is X only I think.On 04/06/2010, Nathaniel J Fries wrote:

SDL_SetVideoMode with the flag SDL_FULLSCREEN set has worked for me in the
past on Windows XP.
SDL_ToggleFullscreen or whatever it was, however, had not.

7

Kenneth Bull wrote:> On 04/06/2010, Nathaniel J Fries <@Nathaniel_J_Fries> wrote:

SDL_SetVideoMode with the flag SDL_FULLSCREEN set has worked for me in the
past on Windows XP.
SDL_ToggleFullscreen or whatever it was, however, had not.

SDL_ToggleFullscreen() is X only I think.

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

I’m 99% certain you’re right.
Though there’s no reason for it to be (could be made a simple macro [or function] wrapping SDL_SetVideoMode on other backends).

EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/

8

I made some tests and found that indeed, the mouse input is greatly
exaggerated in virtualbox: xrel and yrel are stupendously oversized. I was
hoping to work in a virtual space to avoid booting into windows, but I think
I’ll just go back to what I usually do - boot into windows once a week.

I’m pretty sure I’d tried SDL_SetVideoMode (it’s my preferred method in
Linux anyway since for some reason it’s blisteringly faster than
SDL_ToggleFullscreen), but with the SDL_FULLSCREEN flag it destroyed my
rendering context. I’m not sure anymore what effect resizing the window had,
so I will soon try to see if I can just resize the window to desktop size.

What kind of scaling would take place in the case of a desktop-sized window
vs. fullscreen mode? Doesn’t the video drivers and video card do pretty much
the same work as if it ws fullscreen mode? I could be outrageously wrong, of
course, but for now I have no such notion.

ChristianOn Fri, Jun 4, 2010 at 1:49 AM, Nathaniel J Fries wrote:

Kenneth Bull wrote:

On 04/06/2010, Nathaniel J Fries <> wrote:

Quote:

SDL_SetVideoMode with the flag SDL_FULLSCREEN set has worked for me in the
past on Windows XP.
SDL_ToggleFullscreen or whatever it was, however, had not.

SDL_ToggleFullscreen() is X only I think.

SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

I’m 99% certain you’re right.
Though there’s no reason for it to be (could be made a simple macro [or
function] wrapping SDL_SetVideoMode on other backends).

EM3 Nathaniel Fries, U.S. Navy

http://natefries.net/

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

9

I made some tests and found that indeed, the mouse input is greatly
exaggerated in virtualbox: xrel and yrel are stupendously oversized. I was
hoping to work in a virtual space to avoid booting into windows, but I think
I’ll just go back to what I usually do - boot into windows once a week.

One suggestion I’ve seen is to use USB pass-through for the mouse.
Assuming you have a USB mouse, and your virtualizer supports USB
pass-through, just assign the mouse to that machine.

This can be a hassle, especially switching back and forth, but it’s
probably still more convenient than rebooting.

GregoryOn Fri, 4 Jun 2010, Christian Leger wrote: