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”

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.

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?

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