Is there a modern vanilla-compatible Heretic port?

[printz]

Is there any Heretic source port that has these traits?

1) Exact gameplay compatibility. It seeks to preserve all quirks and harmless bugs from Heretic, like Chocolate-Heretic does
2) Graphic and stability limit-removing. No VPO, no savegame limit, no rendering limits.
3) High resolution support
4) Uncapped framerate
5) High-quality sounds and music (but please, not with ZDoom's limitations) -- this may actually be already solved in vanilla Heretic with DOSBOX "Sound Canvas"-like music.

Doom has PrBoom+ and Eternity (the latter is better but has a weaker compatibility level system). Heretic has nothing?

[VGA]

Hey, you are a coder. Can you add Heretic support in Eternity? Or rebase the (discontinued from ver 3.3) Crispy Heretic code to the newest/SDL2 version of Chocolate/Crispy Doom?

Because it has non-demo-breaking bugfixes, is limit-removing, uncapped framerate, double native resolution and portable.

[Graf Zahl]

I don't think you can expect demo compatibility in a port that's also Doom compatible. There's too many subtle differences between both games that are very hard to get working with each othther. In an isolated project that would be different.

Ultimately I even think that it's the demo compatibility requirements that prevented such a port, because unlike Boom for Doom there never was any groundwork done. It's simply easier to implement support for these games if you just need to make it play correctly instead of making it play identically.

[LexiMax]

Crispy Doom used to have a Heretic version, but it was discontinued. It's a chocolate fork, so you might be able to copy-paste the heretic code back into the project and get it working again.

[kb1]

Graf Zahl said:

I don't think you can expect demo compatibility in a port that's also Doom compatible. There's too many subtle differences between both games that are very hard to get working with each othther. In an isolated project that would be different.

Ultimately I even think that it's the demo compatibility requirements that prevented such a port, because unlike Boom for Doom there never was any groundwork done. It's simply easier to implement support for these games if you just need to make it play correctly instead of making it play identically.

It should actually be easier than Doom was, cause we have source code for the Raven games, that hasn't been fiddled with. I've done some preliminary tests of Heretic source against disassembly of Heretic.exe, and so far, they appear to be spot on. Furthermore, Heretic code is very "Doomy", meaning that a modern port can benefit from all the work done with Doom source ports. And, finally, it's not that difficult to tack on some demo sync debug code into Heretic.exe. I did something similar with Strife a few years back. I dumped a write-memory debug function on top of the screenshot code. It stored it's data into the extra screens[] buffer. When you pressed F5 (take screenshot... or was it F11?)

would dump the buffer's contents to a file, and reset the pointer. You had to press F5/F11 every few seconds to avoid buffer overrun!

A VB program assembled these chunks into a single complete demo analysis file. It wasn't pretty, but it worked. Per tic, I captured the P_Random() index (prndindex), the return address from calling P_Random(), and the player position (and maybe a few more values). With the source code, this can be enough to point you in the right direction.

I didn't mean to convey that it would be easy, but there is a straight-forward path.

Having said all that, isn't Chocolate-Heretic/Hexen exactly that: the Raven sources with some modern I/O code from Chocolate-Doom? Seems like an excellent place to start.

[Gez]

Fun fact: Raven Software didn't care about demos at all, as evidenced by how the IWAD demos will desync.

[fabian]

AlexMax said:

Crispy Doom used to have a Heretic version, but it was discontinued. It's a chocolate fork, so you might be able to copy-paste the heretic code back into the project and get it working again.

Actually, the Raven code is still there (and synced with Choco), it is just commented out in the build system.

https://github.com/fabiangreffrath/crispy-doom/issues/132

[kb1]

Gez said:

Fun fact: Raven Software didn't care about demos at all, as evidenced by how the IWAD demos will desync.

I have a feeling that that is going to be easy to sort out, for someone working on it. They used to play ok in older versions. I think Raven shifted a few things around, but didn't re-record the existing demos. That can be worked out, I imagine, without too much difficulty.

Another Fun Fact: Raven code can explain what Doom code really looked like, including module names, and original code placement, before that guy (can't remember his name - starts with B...) re-factored everything. In my opinion, he really jumbled things up, cause the Raven source module names seem to make more sense, and the code looks like it's where it belongs, moreso than the Doom source release. Anyone else notice that?

[Wagi]

I have a feeling that that is going to be easy to sort out, for someone working on it. They used to play ok in older versions. I think Raven shifted a few things around, but didn't re-record the existing demos. That can be worked out, I imagine, without too much difficulty.

The only concrete change I am aware of that was made between the original release and Shadow of the Serpent Riders was the behavior or mace spots. Given that the demos on E3M2 and E2M9 (which contain a Firemace) go out of sync while the one that takes place on E2M5 (which has no Firemace) doesn't, I wouldn't be suprised if it was the only change.

The Doom wiki seems to mention that the excess mace spots in Heretic 1.0 used to spawn monsters depending on the episode they are placed in (and even mentions that they have a ~75% chance of doing so). It also mentions that due to a glitch, excess mace spots in Episode 4 would spawn Shadowspheres. Question is, can we find out how exactly this mechanic worked? It's important that all P_Random() calls are done in the correct order, after all.

[Fonze]

Wagi said:

The only concrete change I am aware of that was made between the original release and Shadow of the Serpent Riders was the behavior or mace spots. Given that the demos on E3M2 and E2M9 (which contain a Firemace) go out of sync while the one that takes place on E2M5 (which has no Firemace) doesn't, I wouldn't be suprised if it was the only change.

The Doom wiki seems to mention that the excess mace spots in Heretic 1.0 used to spawn monsters depending on the episode they are placed in (and even mentions that they have a ~75% chance of doing so). It also mentions that due to a glitch, excess mace spots in Episode 4 would spawn Shadowspheres. Question is, can we find out how exactly this mechanic worked? It's important that all P_Random() calls are done in the correct order, after all.

I would believe that the firemace has something going on with it, but I'm not sure I buy that info from the Doom Wiki. I've never seen a mace spawn summon an enemy instead and I own Heretic 1.0, but of course it's possible to miss things so I can't guarantee that it doesn't. But I don't believe it. I didn't own SotSR until a couple years ago, but 1.0 I've had since I was a youngin. There is a 25% chance, iirc, for no maces to spawn, with the other 75% spread amongst the placed mace spawns. What order everything happens in upon map initialization is a good question, though, especially given Heretic's vast usage of P_Random() all over the place. This is a bit unrelated, but I noticed that HHE turned all mace spawns in my current wip (through the .exe) to wizards/disciples upon map init, which didn't happen before I edited the .exe. That was the first and only time I've ever seen maces replaced with enemies, but in addition no maces spawned ever after that so I suspect some of that was just HHE being a PoS.

Also, some functions within the .exe have other functions streamlined in that do not appear within the source. One of the sorcerer/D'Sparil effects in P_Enemy, for example, has a secret A_Pain built in.

Now, that may or may not affect things (certainly that example wouldn't affect one of Raven's demos as they didn't record any on E3M8), but it is something to note.

[kb1]

SotSR pushed the frames table around, by changing frames. That'll surely put SOME demos out of sync - those that are affected by frames far down in the table.

The released source, which is for SotSR, mentions some frame changes (can't remember which), so those demos should be easy to sync. I will eventually be working on Heretic support, at which time I'll find it essential to support earlier demos as well as SotSR. The work I'm doing now will provide these answers eventually, but Heretic support is way down on the priority list at the moment, so please don't expect any progress from me for a while.

Fonze said:

...Also, some functions within the .exe have other functions streamlined in that do not appear within the source. One of the sorcerer/D'Sparil effects in P_Enemy, for example, has a secret A_Pain built in. ...

I think what you're describing is compiler inlining of functions, which definitely does occur in places in the executable.
I'm thinking that HHE was for an earlier Heretic, but the frame table is in the same place in both .exe files, so it appears to work for both, though incorrectly. I think, due to the way HHE saves data, it gets lucky in that it manages to produce a playable .exe most times, even when it is targetting a different .exe. Doesn't seem possible, but I've seen it do so. Strange. Amazing. Terrifying.