In my quest for the perfect tweak (I gave up on the Holy Grail) I came across one of interest and fabricated another for TR1 play from pursuing Windows Task priority adjustment mechanisms.

DISCLAIMER: I have tested and am using both of these on a Win XP Home installation; Sony VAIO 1.5 Ghz, 512 Mb memory, nVidia geForce2 MX/MX400 w/32 MB. The only game I have tested them with is TR1. Use at your own risk.

Nonetheless I submit these for comments/feedback ("Cry havoc! And let loose the dogs of war!")

Tweak 1: I will simply reprint this one from the source: Ars Technica .

QUOTE

Give 16-bit apps their own separate processes

[HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ WOW]
"DefaultSeparateVDM"="Yes"

By default, Windows XP will only open one 16-bit process and cram all 16-bit apps running on the system at a given time into that process. This simulates how MS-DOS based systems viewed systems and is necessary for some older applications that run together and share resources. However, most 16-bit applications work perfectly well by themselves and would benefit from the added performance and stability of their own dedicated resources. To force Windows XP to give each 16-bit application it's own resources, browse to HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ WOW and find the String "DefaultSeparateVDM". If it is not there, you may need to create it. Set the value of this to Yes to give each 16-bit application its own process, and No to have the 16-bit application all run in the same memory space.

END QUOTE

If you should be running TR1 with Glidos and VDMSound then as far as I can tell, when the game is being started/played, the 16 bit applications are; DOSDRV, DOS4GW, TOMB and NTVDM (you can help me out here anytime Paul!) but I'm not clear on the dependencies, DOSDRV loads VDMSOUND, GLDVESA loads TOMB, etc. The GLIDOS.EXE application itself is 32 bit? (I believe).

This tweak helped my performance and is fairly safe since it only affects the resource allocation to 16 bit apps by giving each app their own, which means if your system has enough resources (memory, etc) and the apps do not require shared memory access to common resources, which I have already empirically proven they don't, there is no problem. Also the resources are released when you exit the game as they should be.

Tweak 2: Boost VDMSound priority

Preface: I started out programming real-time data acquisition systems in FORTRAN and assembler in 1982. Since then I have worked on numerous projects in numerous capacities including VMS cluster administration. My general word of warning on 'playing' with priorities: DON'T. Priorities are like loaded guns, they were not meant to be 'played' with. If you have a specific, identifiable target and reason for adjusting a process priority, do so gradually and carefully. A misadjusted priority in the wrong process can prevent even an emergency boot from recovering a system.

This tweak will elevate the priority of VDMSound above the bulk of the 'normal' Windows processes. It should not be done if you intend to do anything else while you are playing the game. It will not halt the 'normal' windows processes and it's easier than having to re-boot to a "game configuration" in terms of active services, startup applications, etc.

1. In the VDMSound installation directory (default is C:\Program Files\VDMSound) create a DOSDRV.BAT file. Insert the following command:

start /separate /abovenormal dosdrv.exe /i:VDMS.INI

The '/separate' switch is redundant to Tweak #1 above but it allows you to test the tweaks independently should you need to.
This command will start DOSDRV.EXE with it's own process space (/separate) with an elevated priority (/abovenormal). DOSDRV will in turn load the VDMS drivers using the VDMS.INI for initialization settings. The drivers will inherit the priority of the parent process DOSDRV.

2) Disable your screen saver. Not that it matters but screensavers are supposed to run "/belownormal". VMDSound works by 'sampling' the gameport, it's not interrupt driven. So your screen saver will get little to no cpu time.

3) Now start TR1 using Glidos and be ready to test, your not finished yet. You need to test your sound, especially the game-action sounds (bang-bang, footsteps). And your gamepad controls. They may be jerky. There are some setting in VDMS.INI you can adjust which will depend on your configuration. Read the VDMS.INI text, pay close attention to:

(My pre and post tweak settings. The values in [] were VDMS installation defaults. These are JUST EXAMPLES, your settings WILL be different).

[DMA Transfer Manager.config]
minDMAPeriod =1 ; pre=5 [5]
maxDMAPeriod = 5 ; pre=15 [15]

[SB Wave Player.config]
buffer = 20 ; pre=75 [75]

[Joystick Controller.config]
maxCoord = 1000 ; pre=250 [250]
pollPeriod = 125 ; pre=20 [125]

4) Bring up the task manager while TR1 is running and verify you have an NTVDM process running at "abovenormal". There should be a 'few' processes at HIGH priority and one should be the TASK MANAGER itself.

That's it. It may be necessary to tweak and re-tweak the VDMS.INI settings so I suggest a desktop shortcut to the file. Just start up Glidos, start TR1, test, exit TR1, adjust settings a try again.

A final note: Both of these tweaks are non-destructive and can be backed out (backup your original VDMS.INI file!).

As for priority adjustment

DO NOT USE ANY PRIORITY HIGHER THAN ABOVENORMAL, YOU COULD LOCK YOURSELF OUT OF THE SYSTEM AND HAVE TO POWER OFF TO REGAIN CONTROL. I just hate a hard shutdown, they are so ungraceful.

😎