VOGONS


Fastest CPU Descent 1 can handle?

Topic actions

Reply 20 of 32, by CwF

User metadata
Rank Member
Rank
Member

This game is far to fun to not run a modern port. I run DXX-Rebirth on my current E5 xeon amdgpu debian workstation. I have very hard saves for those times I want to pop into a hopeless situation and die within minutes, then back to the thought...
It must be the best example of old into the new of any game. Seems flawless.

I used to know what I was doing...

Reply 21 of 32, by The Serpent Rider

User metadata
Rank l33t++
Rank
l33t++

P200 is not enough to cause Descent work at increased speed.

I must be some kind of standard: the anonymous gangbanger of the 21st century.

Reply 22 of 32, by dr_st

User metadata
Rank l33t
Rank
l33t
jmarsh wrote on 2021-03-25, 17:33:

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.

On a related note, I was recently informed that there is a simple hack to disable ship bobbing in both Descent and Descent II:
http://cloakedthargoid.wordpress.com/descent-ship-bobbing
Might help it be less annoying on fast CPUs, or if you suffer from motion sickness.

https://cloakedthargoid.wordpress.com/ - Random content on hardware, software, games and toys

Reply 23 of 32, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie

No problems for single player but you probably wouldn't want to do that if you ever intended doing any PvP (although I doubt anyone is still using the original builds for that) - viewing the map screen makes your ship visibly stop bobbing for other players so it was considered an AFK/"don't shoot me" indicator. Having a permanently unbobbing ship would have been considered cheating.

Reply 24 of 32, by dr_st

User metadata
Rank l33t
Rank
l33t
jmarsh wrote on 2021-03-28, 00:00:

No problems for single player but you probably wouldn't want to do that if you ever intended doing any PvP (although I doubt anyone is still using the original builds for that) - viewing the map screen makes your ship visibly stop bobbing for other players so it was considered an AFK/"don't shoot me" indicator. Having a permanently unbobbing ship would have been considered cheating.

Interesting. I actually have to wonder if that would be even theoretically possible. There is a good possibility that if some players ran the normal build and others ran the no-bobbing hack, multiplayer games would desync. Thus, you could only play like this if everyone did the same.

https://cloakedthargoid.wordpress.com/ - Random content on hardware, software, games and toys

Reply 25 of 32, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie

Descent doesn't really suffer from desync, clients just update other clients with changes to their status. There's no prediction or sanity checking. You can have a ship that is impervious to damage and moves five times faster than normal and other players won't be able to touch it.

Reply 26 of 32, by MrFlibble

User metadata
Rank Oldbie
Rank
Oldbie

Apologies for bumping this, but I'm trying to compile the DOS version of D1X and there's a problem I cannot figure out how to solve.

First off, I need to note that the code from the GitHub repo seems no longer suitable for use with DJGPP 2.x, presumably because of the changes which were made to the code for compatibility with newer compilers (this fork, albeit with less changes, does not work either).

Because of this, I had to use the code from Jeremy Stanley's page. My DJGPP setup:
djdev202.zip
bnu281b.zip
gcc281b.zip
gpp281b.zip
mak3761b.zip - version 3.75 works but does not fully support makefile features
nasm097.zip - later versions won't work

The thing is, individual components from the sub-folders compile fine without errors and populate the lib directory with .a files, but when make tries to put together the final binary from these, for some reason it spews out lots of errors concerning "undefined reference" to variables from all sorts of places:
eIo4ktZ.png
Any suggestion of what I might be doing wrong? I'm using DOSBox-X for compiling, because of its built-in LFN support (needed for GPP).

DOS Games Archive | Free open source games | RGB Classic Games

Reply 27 of 32, by AppleSauce

User metadata
Rank Oldbie
Rank
Oldbie
The Serpent Rider wrote on 2021-03-27, 13:46:

P200 is not enough to cause Descent work at increased speed.

What about a 233? I'm planning on playing it at some point.

Reply 28 of 32, by akula65

User metadata
Rank Oldbie
Rank
Oldbie
MrFlibble wrote on 2022-07-12, 16:46:

Apologies for bumping this, but I'm trying to compile the DOS version of D1X and there's a problem I cannot figure out how to solve.

You might check the following for tips and gotchas, if you have not already:

https://web.archive.org/web/20000415000000*/h … x.warpcore.org/
https://web.archive.org/web/*/http://ftp.morp … s.net/pub/d1x/*

Reply 29 of 32, by dr_st

User metadata
Rank l33t
Rank
l33t
MrFlibble wrote on 2022-07-12, 16:46:

The thing is, individual components from the sub-folders compile fine without errors and populate the lib directory with .a files, but when make tries to put together the final binary from these, for some reason it spews out lots of errors concerning "undefined reference" to variables from all sorts of places

These are linker errors. This suggests that some libraries or library search paths are missing in the linker's settings.

Are the symbols it complains about defined in the D1X project itself or in one of the external dependencies?

https://cloakedthargoid.wordpress.com/ - Random content on hardware, software, games and toys

Reply 30 of 32, by MrFlibble

User metadata
Rank Oldbie
Rank
Oldbie
dr_st wrote on 2022-07-13, 10:54:

These are linker errors. This suggests that some libraries or library search paths are missing in the linker's settings.

Are the symbols it complains about defined in the D1X project itself or in one of the external dependencies?

From what I can tell, the variables are defined within the project (there are too many warnings to fit on a single screen, and I was unable to log output into a text file).

But, I've just rerun the creation of dep.dep dependency files, and it looks like for some reason, it expects the include directory to be located inside C:\DJGPP\DJGPP, although I have installed and configured DJGPP into C:\DJGPP.

DOS Games Archive | Free open source games | RGB Classic Games

Reply 31 of 32, by MrFlibble

User metadata
Rank Oldbie
Rank
Oldbie

Alright, I've tried various GCC, GPP and Make package combinations, but either they don't compile anything at all, or complain about undefined references as described above.

It looks like make 3.75 is the only version able to compile the .a files, but it does not build dependencies with make dep for some reason -- making me wonder how it would work back then for the original D1X devs? Perhaps they never built in pure DOS (which would be closer to what DOSBox does)?

Is there any way to get the clean D1X 1.40 source? The original cvs repo is no longer online as it seems, and ftp.morpheus.net only has sources for versions up to 1.31. UPD: There's a version of D1X code at icculus.org from 2003, not sure if it would be of much use though.

DOS Games Archive | Free open source games | RGB Classic Games