I’ve removed the fullscreen/resizing on Qemu 1.1.1

And now it is *MUCH* faster…

Next I’ll have to investigate better audio libraries, as winwave seems to leave a lot to be desired.

Basically the changes in ui/sdl.c were:

case 0x21: /* 'f' key on US keyboard */
// toggle_full_screen(ds);
// gui_keysym = 1;
case 0x16: /* 'u' key on US keyboard */
// if (scaling_active) {
// scaling_active = 0;
// sdl_resize(ds);
// }
// gui_keysym = 1;


// sdl_scale(ds, ev->resize.w, ev->resize.h);

So now it keeps the correct video display size, so it isn’t going like crazy trying to scale the screen 30 times a second..

Doom now looks normal!

As you can see stuff like Doom now looks normal.  As mode changes are initiated by the video card, it keeps the scale to where it was in prior versions.  At least its not going 1:1 native as looking at a 320×200 window on a 1280×768 desk would be a tad hard..

And yes, even things like Windows 3.0 look correct when the screen changes resolution:

Windows 3.0 in 386 enhanced mode

Also I should add that if you are going to try to use disk images that are *NOT* 1.44 MB they will not work.  You’ll have add this flag to Qemu:

-global isa-fdc.check_media_rate=off

I’ve been told the new handling of disks is better in this version so I’ve left this setting where it was..

I have just updated the download link, but for those who missed it, you can download the i386  win32 version here.

16 thoughts on “I’ve removed the fullscreen/resizing on Qemu 1.1.1

  1. Thanks for the binary! The speed indeed increased a lot.
    It’s a pity that QEMU still have broken support for Cirrus at high resolution and color (like 1024×[email protected]) for WFW 3.11 for QEMU versions higher than 0.9.1. Although with -vga vmware and patched SVGA driver it’s possible to run WFW 3.11 at 1024×768@256 colors.

  2. Oh I discovered that this binary won’t run under XP… Maybe due to dependencies I guess? Since the error happens while loading mcvcrt.dll. Also, what’s the difference between qemu-system-i386.exe and qemu-system-i386w.exe?

    • The ‘w’ Executables detach and run in a window… so you aren’t left with a dead dos box in the background.. Useful for people who like to package Qemu ….

      I’ll have to see about XP I’d imagine they would run ……?

        • try starting the ‘w’ exe with a start ….

          start qemu-system-i386w bla bla …

          that ought to wrap it if you then ‘start’ that cmd .. I think. This is where NT shows off it’s OS/2 roots.

          • Not only on DOS Doom but also WFW 3.11 is much slower than 0.15.1…
            Not sure about its mechanism, the thing I noticed that is 1.1.1 is kinda “better” on memory management, which allows more TSRes to be loaded into UMA while in 0.15.1 there are less.

          • more UMB’s .. now that is interesting… 1.0.1 is almost as fast as 0.15 … but I don’t see the compelling reason for 1.0 … I should try to merge the slirp from 1.1.1 into 1.0.1 to see if it can network at least, and be somewhat useful. that and figure out how to build the fmod SDL … so much to do!

      • Well I think that SDL still does a pointless blit in this case 🙁
        You might want to consider using OpenGL instead of SDL. Note though, it’s reported that conversion from paletted graphics to 32-bit is often slow in OpenGL (so in 8-bit mode, SDL wins; but if the paletted graphics is uploaded as grayscale texture, SDL loses.)

  3. I just found this post, excellent! SDL scaling has been driving me mad…

    Applied this fix to 1.6.0 – code has changed slightly but still works. For anyone interested here’s the diff to patch ui/sdl.c

    < toggle_full_screen();
    // toggle_full_screen();
    > // gui_keysym = 1;
    < if (scaling_active) {
    < scaling_active = 0;
    //if (scaling_active) {
    > // scaling_active = 0;
    > // sdl_switch(dcl, NULL);
    < }
    // }
    > // gui_keysym = 1;
    resize.w, ev->resize.h);
    > // sdl_scale(ev->resize.w, ev->resize.h);

Leave a Reply