Doom v1.6 emulation

[nukeykt]

Doom 1.6 emulation.
I was working on Doom 1.6 emulation this summer. It is nearly completed(including savegame compatiblity). The only issue i know is demo compatiblity. Some demos go out of sync. It is likely due to Pain Elementals.

[fragglet]

This is certainly comprehensive. I'll need some time to properly review it.

OTOH: It isn't necessary to disable certain command line arguments when emulating old versions. For example you can get rid of the conditional code around -timer and -cdrom.

[fabiangreffrath]

o_O Wow, what a massive effort.

Though, I really dislike the fact that it requires re-definition of most of info.c in d_compat.c. Is it possible to somehow circumvent this?

[chungy]

Does this emulate the beta shareware or the leaked/hacked 1.6 patch?

[nukeykt]

This emulates beta shareware. But are their EXEs different?

[chungy]

I don't know, I haven't managed to find a copy of the other release.

[fragglet]

So I've been blocking progress by not reviewing this and I apologize.

I have some reservations about the approach taken. First, this is a really big merge and it would make a lot more sense if this was broken up into a series of smaller changes, ideally on a branch that we can test things on. This is how we've developed other such large features.

In terms of the changes here, the main thing that I don't think is a good approach is the d_compat.c file, because:

• It has almost no comments.
• It does a bunch of state table changes in code rather than in tables.
• The mapping functions in it are called throughout the codebase in places including the renderer.

From what I understand, this file is solving two problems:

1. Some of the table entries from info.c did not appear in older versions of Doom.
2. Some of the table entries in v1.6 were different and changed in development between the beta version and the v1.666 release.

In addressing (1), maybe a simpler approach is to just add a field to the types used in info.c documenting when each entry was added? For example, for D_Compat_MobjExists(m), you essentially are just trying to answer the question, "is gameversion >= v, where v is the version of Doom in which m was added?". These "Exists" methods then become so simple that you probably don't even need them as a function.

There are a few places where you need to map from one table index to another (D_Compat_SpriteToNew, D_Compat_SpriteToOld, etc.). I think these are limited to: savegames; dehacked; error messages. In each of these cases performance isn't important, so it should be possible to calculate the mapping in real time using a range scan over the table without needing to maintain a mapping table.

Regarding (2) above, I actually wonder whether this should be out of scope for the project. Or at the very least: is this best achieved in code? Could you get the same result by using an auxiliary dehacked patch? I suspect that you probably can, and it's probably a lot cleaner. There's already precedent for this with chexdeh.zip (see idgames) which stores the changes needed to emulate Chex Quest in Chocolate Doom. There's the additional advantage that you also make this work available to users of other source ports who may be interested to experience some of the differences from the v1.6 beta.

[nukeykt]

Ok, Thanks for reply.
Unfortunately there are differences in sprite/state/mobj tables item sequence between 1.6 and 1.666 (e.g. Keen's states are next to torch in 1.6, but before in 1.666). So there will be some troubles with your suggested approach.
Dehacked patch seems to be interesting. I'll try to make patch soon. But on the another side there bunch of differences in action functions, that cannot be done via dehacked, which make it a bit useless in other ports.