Maybe it's just me, and I haven't tried any game but Chronomaster since I installed SP4, but... Here's a repost from the Announcements forum:
Hmm... Everything else seems fine, but now VDMS is having issues.
Before SP4 I was playing Chronomaster (DOS adventure game) with VDMS and no problem. Now it's running extremely slow with sound enabled.
Hmm... Actually, it's running slow with sound disabled from the game setup, but running the game exe from Launchpad (with all the updates, naturally). However, it's not *as* slow this way.
By "with sound enabled" I assume you mean with Sound Blaster digitized sounds, and not FM synthesis music right?
I just installed SP4 myself, and at first glance nothing seems amiss / slower. I saw on the changelog for SP4 that they did make changes to NTVDM.EXE, so it's not inconcievable that they broke some games that ran fine before with VDMS. Try running the game in a vanilla NTVDM window, without VDMS of any kind. If it still runs slow, then it probably has something to do with SP4.
Yeah, that's what I mean. The game uses digitized sound and MIDI.
My testing showed that it is slowest when configured that way. If I tell the game there is no sound card, and yet I still run it with Launchpad, it's slow but not *as* slow.
Running it in a vanilla NTVDM window grants full-speed. My thought is that SP4 affected something in the way VDMS monitors for calls to the ports or whatever. I really have no idea, but...
I suppose I need to try more games and see if this is true for more than just Chronomaster, which is a late DOS era game.
Okay... I've done some more messing around. It seems that:
If I run Chronomaster or any other game from a normal NTVDM window, it's fine.
If I enabled VDMS from that same NTVDM window, it's still fine. Sound works and the speed seems correct.
It's only when using Launchpad that things slow down immensely. I'm gonna keep tinkering and see what I come up with.
UPDATE:
Most strange. I've found what appears to be the major factor in the slow down. I always set my Launchpad shortcuts to enable basic VESA support, whereas from a command prompt I have to do it via ALT-ENTER.
I know Launchpad's basic VESA support option does nothing more than set the NTVDM to full screen, but it *does* seem to be affecting something. If I deselect this option in Launchpad, and then hit ALT-ENTER to go full screen fast enough (so that the game doesn't kick out for lack of VESA support), everything runs fine.
Last edited by NStriker on 2003-07-02, 12:50. Edited 1 time in total.
Originally posted by NStriker UPDATE:
Most strange. I've found what appears to be the major factor in the slow down. I always set my Launchpad shortcuts to enable basic VESA support, whereas from a command prompt I have to do it via ALT-ENTER.
SP4 does include all previous hotfixes. You could look through the hotfix list for SP4 and try to find anything having to do with NTVDM.....GOOD LUCK!!!!!!!!!!!
Originally posted by NStriker Well, yes... I remember that other people have seen this before, however I particularly meant after SP4.
Yes, I caught that, but it's almost certainly related, right? It's probably like DosFreak said, SP4 contains the NTDVM changes and that probably triggered it.
Most strange. I've found what appears to be the major factor in the slow down. I always set my Launchpad shortcuts to enable ba […] Show full quote
Most strange. I've found what appears to be the major factor in the slow down. I always set my Launchpad shortcuts to enable basic VESA support, whereas from a command prompt I have to do it via ALT-ENTER.
I know Launchpad's basic VESA support option does nothing more than set the NTVDM to full screen, but it *does* seem to be affecting something. If I deselect this option in Launchpad, and then hit ALT-ENTER to go full screen fast enough (so that the game doesn't kick out for lack of VESA support), everything runs fine.
During some work I did on an installation document for the DOS SVGA DPMI game Silent Hunter for Windows XP a few months ago, some folks using the document for Win2K noted a problem with the VESA check-box option provided by LaunchPad v1.0.0.7 (and also v1.0.1.0) when attempting to initially execute the Silent Hunter DOS executable. In another VOGONS thread "Just a Suggestion" it was noted by DosFreak that Microsoft documents (Document KB812681) the fact that Windows XP(SP1) will use the first VESA BIOS video call by a VESA SVGA Dos application to switch automatically to full-screen mode. Windows NT4 and Windows 2000 do not have this behavior and must be manually switched to fullscreen mode by the user via the "ALT-ENTER" keystroke combination in order for the application to begin execution. This seems to be what NStriker has found and documented on this thread.
After a bit too much experimentation with WinXP Pro(SP1), the LaunchPad VESA (XP full-screen) checkbox option and testing batch files with multiple Dos TSRs I came to the conclusion that you should never launch any DOS SVGA application in full-screen mode under WinXP, just let WinXP do the work to switch to full-screen mode as this will eliminate many unforseen "problems". Many times programs (particularly Dos TSRs) executed as part of batch files before the execution of the main SVGA program will have strange problems or failures if executed on some WinXP systems with particular video cards/drivers. So while starting a game/batch file under WinXP with some video card/driver will work fine, on other systems the exact same executable environment will fail. The common factor for success seems to be to start all DOS executable/batch files in "Windowed" rather than "Full-screen" mode. If your WinXP video card/driver combo does not need it, there is no harm as the DOS executable/batch file will work anyway, and if your WinXP video card/driver combo does need it - so much the better. Seems to be a good rule of thumb for WinXP users, always start "Windowed".
OK, so how about the WinNT or Win2K users? Their NTVDM support will not automatically switch from "Windowed" to "Full-Screen" mode when an SVGA VESA application makes its first VESA BIOS call and since failure (or problems) may result when attempting to start the SVGA VESA application in full-screen mode in the first place, what to do? It seems that the WinNT/Win2K users must take up the approach that NStriker did, to "hit ALT-ENTER to go full screen fast enough (so that the game doesn't kick out for lack of VESA support)" and hope your keyboard reaction speed is just warming you up for the game...
Or must they?
To help solve this problem for those WinNT/Win2K users I have attached to this message a Windows 32-bit console application by the name of "FULLSCRN.EXE" which I wrote to allow those using the WinNT/Win2K operating systems to match the apparent behavior of WinXP when executing DOS SVGA VESA applications. If a DOS batch file is used to execute both "FULLSCRN.EXE" and then the desired Dos SVGA VESA application, the user gains the functionality of the WinXP(SP1) "Windowed" to "Full-screen" NTVDM capability.
For example, if a Win2K user was attempting to run the Silent Hunter executable by the name of "SH.EXE" from the "C:\Silent" sub-directory. They download the attached "FULLSCRN.EXE" file and place it in a directory named "C:\UTILS" for this example. The string "C:\Silent\SH.EXE" would typically be in the DOS Properties "Cmd line" program box. To use "FULLSCRN.EXE" they might create a batch file called, say "SHFULL.BAT" in the "C:\Silent" sub-directory and execute that instead of SH.EXE, with the DOS Batch file set to start in "Windowed" mode of course...
The "SHFULL.BAT" batch file might be as follows:
1@Echo off 2C:\Utils\FullScrn.exe 3C:\Silent\SH.EXE
The program "FULLSCRN.EXE" is not a DOS TSR executable, it is a Win32 console app, and MUST be the last program executed in a DOS Batch file before the target Dos SVGA VESA application. So put any other Dos programs/TSRs before any use of "FULLSCRN.EXE" in a DOS Batch file or you will have the same problems as the flawed WinNT/Win2K initial full-screen mode that led to this message thread.
When it comes to using LaunchPad it appears tempting to use the built-in AUTOEXEC.BAT option in the VDMSound Advanced Dos Environment tab, but I have not been successful using this built-in batch file to execute the "FULLSCRN.EXE" program. It seems to require a seperately executed batch file as listed above for "FULLSCRN.EXE" to work before the execution of the target Dos SVGA VESA application.
Enough for now, if anyone using WinNT/Win2K or even WinXP wishes to try it out the file "FULLSCRN.EXE" should be attached to this message...
Also, would writing a 16-bit proggy that switches to, let's say, 320x200x8bpp mode, mode 13 IIRC (which would trigger full-screen in all Windows), achieve the same result??
Originally posted by dvwjr During some work I did on an installation document for the DOS SVGA DPMI game Silent Hunter for Windows XP a few months ago,...
So you're the guy who came up with that. Been meaning to write you. That's exactly the kind of step-by-step guide needed for many games. Will try to contact you by email about details...
