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;
break;
case 0x16: /* 'u' key on US keyboard */
// if (scaling_active) {
// scaling_active = 0;
// sdl_resize(ds);
vga_hw_invalidate();
vga_hw_update();
// }
// gui_keysym = 1;
break;
And
case SDL_VIDEORESIZE:
// sdl_scale(ds, ev->resize.w, ev->resize.h);
vga_hw_invalidate();
vga_hw_update();
break;
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..
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:
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.
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.
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 …
exit
that ought to wrap it if you then ‘start’ that cmd .. I think. This is where NT shows off it’s OS/2 roots.
I’ve gone ahead and done a build on XP that seems to “work” but again it is SLOW on MS-DOS doom…
http://vpsland.superglobalmegacorp.com/install/qemu-1.1.1-windowsXP-sp3.7z
I’ve done more testing and doom plays MUCH better on Qemu 1.0 it seems going to 1.1.1 kind of killed it.. I’ll need to find/build 1.1.0 and see how that behaves…
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!
Hmm they all seem to just crash… so I’m building this on an XP sp3 VM on VMware … this will take a while…
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..
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
518,519c518,519
< toggle_full_screen();
// toggle_full_screen();
> // gui_keysym = 1;
522,524c522,524
< if (scaling_active) {
< scaling_active = 0;
//if (scaling_active) {
> // scaling_active = 0;
> // sdl_switch(dcl, NULL);
527,528c527,528
< }
// }
> // gui_keysym = 1;
804c804
resize.w, ev->resize.h);
---
> // sdl_scale(ev->resize.w, ev->resize.h);
How is Qemu 1.6.0 for Win32? My build is still insanely slow……
Unfortunately that didn’t reproduce very well…