play with caches and memory latency? there are source ports which might run at the correct speed too;

mrau wrote:

play with caches and memory latency? there are source ports which might run at the correct speed too;

Yeah maybe some bios settings can slow things down but that would require rebooting and then undoing my changes when I want to play something else

I know about the dxx rebirth source port but that's for windows 7 and up

I was heavily involved in the community when the source was released and the ORIGINAL D1X community updates came out. I have no idea how easy they are to find these days, but you might try looking around for them. D1X was still a DOS executable but some of the first things done were an adjustable framerate limiter & various fixes for the fast machines that were appearing around then (800~1GHz just like yours.)

My Forte VFX1 rig is 366/412MHz (depending on where I feel like setting the FSB) & I have to run vanilla D1 for the VFX1 support. I find it playable but I do start to notice the effects of the fast CPU. Homing missiles will follow you to the planet's core and back. 😎

You can always try the high-res command-line options: -320x400, -640x400, -640x480, etc. For Descent 2 use -superhires and you can pick up to 1280x1024 in the menu (works on my P4/3.0!)

amino glycine wrote:

I know about the dxx rebirth source port but that's for windows 7 and up

It used to run on Win9x. I take it GCC and SDL2 decides what platform they should run on for them

Did some looking into this. D1X DOS 1.40 binaries are available on on its site on the internet archive. There was a 1.43 floating around with some updates that made it more compatible with Win98/XP among other things, but I haven't found a working download yet (I might even have a copy somewhere!) Or you can roll your own from the source, which is still available.

It uses Allegro for sound which seems a bit cranky - I couldn't get FM music to work under DOSBox in some quick testing - but IIRC it went fine on hardware.

D2X 0.2.5 source & binaries are available on its old website which is shockingly still online.

One of the main goals for both these ports was to keep them playable on increasingly fast CPUs, so you might find them useful. 😀 Both 1.43 and 0.2.5 represent the last available versions of these before they were abandoned and subsequently rolled into Rebirth.

You could also try one of the Win9x ports from back in the day, or if you have a Voodoo card, the D1_3DFX community patch which IIRC took some code from D2_3DFX. I don't think it had a frame limiter built in but you might be able to force it to vsync. Although if you're doing that I'd say just find the newest version of Rebirth that will run on 9x.

Jeremy Stanley had a Version 1.43 D1X build which you can still download through the Wayback Machine:

https://web.archive.org/web/20100524094137/ht … tanley/d1x.html

You will need SDL and OpenGL libraries.

Another Windows Version 1.43 D1X build is available here:

http://www.dfiles.de/download/d1/patches/d1x143w32.zip

Thanks for the help everyone

Funny thing happened, I came across my old copy of Descent from the 90s, the registered version. It runs fast but totally playable. If I downclock my CPU as far as it will go, the game runs at the correct speed.

Weird how the shareware version had problems but the registered doesn't.

akula65 wrote:

Jeremy Stanley had a Version 1.43 D1X build which you can still download through the Wayback Machine: […]
Show full quote

Jeremy Stanley had a Version 1.43 D1X build which you can still download through the Wayback Machine:

https://web.archive.org/web/20100524094137/ht … tanley/d1x.html

You will need SDL and OpenGL libraries.

Another Windows Version 1.43 D1X build is available here:

http://www.dfiles.de/download/d1/patches/d1x143w32.zip

^^ Oh neat, shame there's no DOS executable though. I just tried to compile J.S.'s modded 1.43 on a modern Linux distro but it didn't go well. 😜 Maybe I'll give it a shot on an old RedHat VM when I get more time.

Playing with 1.40 has been fun, it's been years since I've used it last. I don't know why Rebirth didn't keep the -missiondir parameter.

For anyone still wanting to play Descent 1 at a playable speed, MoSlo works great - http://www.hpaa.com/moslo/
http://www.hpaa.com/moslo/v15/moslo15.exe

Save it somewhere and change the command line on the moslo exe. I use the following

C:\Software\moslo\moslo.com /50 /m2 C:\descent\dcntshr.exe

This will slow the CPU speed by 50% which is about right on my P3 550MHz when running it on Windows 98 SE
M2 changes the method from system timer to realtime clock making things smoother (but less compatible with early 90s games)

Original requirements were a lot less, but this was running DOS / Win95 and no programs needed to slow the CPU down
https://www.computerhope.com/games/games/descent.htm

You'd really think that by the 32-bit DOS extender era, all newly released games would be using proper timing routines that wouldn't depend on the clock speed of the CPU. 😕

It's crazy how there are games, some of which are much older than Descent 1, that still work perfectly at the same speed on modern hardware as they did on systems back in the day. It's simply a matter of non-sloppy programming.

I can understand this for the very early DOS games that depended on optimized assembly routines to make the most out of a 4.7MHz 8088 system, but not for anything that came out half a decade later and was written in a higher level language.

digger wrote on 2021-03-20, 11:54:

You'd really think that by the 32-bit DOS extender era, all newly released games would be using proper timing routines that wouldn't depend on the clock speed of the CPU. 😕

bethesda wants to know your location

Using the -640x480 command line option usually slowed Descent down enough to playable speed, plus you get SVGA graphics.

digger wrote on 2021-03-20, 11:54:

You'd really think that by the 32-bit DOS extender era, all newly released games would be using proper timing routines that wouldn't depend on the clock speed of the CPU. 😕

It's crazy how there are games, some of which are much older than Descent 1, that still work perfectly at the same speed on modern hardware as they did on systems back in the day. It's simply a matter of non-sloppy programming.

I can understand this for the very early DOS games that depended on optimized assembly routines to make the most out of a 4.7MHz 8088 system, but not for anything that came out half a decade later and was written in a higher level language.

There are in 2021 some (lots of if I was cynic) new games that are cpu speed dependant often for physic and game script. Skyrim, Spyro remake are know examples and often original game console with Pc port (skyrim for example). Pcgamingwiki is a usefull source of that.

There's also this version (Add the Descent 1 files to run Descent 1)
Descent 2 port for Win95

for anyone interested in just playing the original .exe, something around p90-p133 will be the sweet spot. it'll be playable down to dx2/66 if one can tolerate somewhat low framerates, and that's probably what most played it on when it came out. speaking of low framerates, the playstation port uniquely has excellent colored lighting and dual analog stick support.

-640x480 is a valid suggestion for a fix, it's just visually very different and lacks the cockpit view.

for anyone interested in just playing the original .exe, something around p90-p133 will be the sweet spot

Make it P200.

digger wrote on 2021-03-20, 11:54:

You'd really think that by the 32-bit DOS extender era, all newly released games would be using proper timing routines that wouldn't depend on the clock speed of the CPU. 😕

It's crazy how there are games, some of which are much older than Descent 1, that still work perfectly at the same speed on modern hardware as they did on systems back in the day. It's simply a matter of non-sloppy programming.

I can understand this for the very early DOS games that depended on optimized assembly routines to make the most out of a 4.7MHz 8088 system, but not for anything that came out half a decade later and was written in a higher level language.

yes you'd think so, but i suppose if the task is to sell games 'right now' then taking care of potential future problems relating to faster cpus isn't part of the project

at the time i imagine the hope was to run as fast as possible and no machine on the market made it unplayable, as long as that remained true for the period in which the game was on sale i doubt they would have considered the issue something that even needs consideration

Most of Descent is programmed to handle variable framerates so there was no need to limit the maximum framerate. But unfortunately a few things slipped through and still update per frame instead of per ms, the most notable being the ship bobbing (which gives the sense that the entire game is running faster when it's not) and the tracking rate for homing missiles.

the homing missile thing is already enough to render the game unplayable by itself, since it makes enemy ones unavoidable, so it's unfortunate indeed. maybe the inclusion of higher resolutions in later patches was their quick workaround for this issue...

descent 2 is improved in this regard but still screws up the mouse sensitivity on fast systems. granted, there's quite a number of other problematic 1996 DOS games, so parallax weren't the only ones to blame in this regard.

The Serpent Rider wrote on 2021-03-25, 12:32:

for anyone interested in just playing the original .exe, something around p90-p133 will be the sweet spot

Make it P200.

maybe - personally i would never want to run into any speed issues and a fast p200 might already be too fast when looking at a wall in some simple room. the fastest thing they could have possibly tested the game on is a p100, going by the release date, but some 430NX p90 would be more realistic factoring in the development cycle.

i kind of wonder to what extent they could have been aware of the speed senstivity during development, i.e. is dropping all the detail on a p90/p100 already enough to cause breakage?