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.

This entry was posted in qemu, Win32 by neozeed. Bookmark the permalink.

About neozeed

What is there to tell? I've loved UNIX like things since I was first exposed to QNX in highschool (we had the Unisys ICONS!), and spent the better time of my teenage years trying to get my own UNIX... I should have bought Coherent in retrospect.. Anyways latched onto Linux in 1992, and then got some old BSD admin books and have been hooked on the VAX BSD & other big/ancient things since...!

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×768@16.8M) 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 ……?

      • Hmm, maybe because I was using a batch file to launch QEMU the dosbox persists anyway… Thanks for the clarification.

      • 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!

  3. SDL performance sucks ass. Two Doom ports added the option to use OpenGL for framebuffer instead of SDL and it’s faster.

    • Maybe that is something to look into, it should be simple right, just a ‘textured surface’ that you keep on updating….?

      • 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.)

      • woooosh… lol I’d probably try ‘borrowing’ the code from some other project that does it..

  4. 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

Your email address will not be published.

Notify me of followup comments via e-mail. You can also subscribe without commenting.