Chocolate Doom

[axdoomer]

PVS said:

Chocolate Hexen: for me not work in game "Move backward" action assigned to the middle mouse button.

You're right, it's broken. Report issues here.

EDIT: I didn't test against vanilla.

[PVS]

axdoom1
In this time normally use github not pissible for me. Tell me guys, if my posts here are not necessary.

CapnClever
1. -nomonsters, -respawn command line parameters for playback vanilla demos now work for me, but maybe you forgot about "timedemo"? There need the same fix, in my opinion.

2. About demo auto-detect: use the same hex numbers as the vvHeretic for player 1 byte - it's the right idea, but for "nomonsters", "respawn" and "longtics" vvHeretic use 02, 20, 10. After recording demos in Chocolate Heretic I see results: 03, 21, 11 (like +1) for this modes. You think it is better? In my opinion, it is better to use the same numbers as the vvHeretic, just to make it equally. Of course, technically it is not important and will work.

I tested on the Chocolate Heretic 20161115.

[CapnClever]

PVS said:

Chocolate Hexen: for me not work in game "Move backward" action assigned to the middle mouse button. In Chocolate Heretic this work fine.

Can someone test this for yourself?

I've confirmed this as well and, looking into that part of the code, there's at least one other discrepancy between Hexen and other Chocolate ports. I'll fix it once I finish determining what ought to be changed.

PVS said:

1. -nomonsters, -respawn command line parameters for playback vanilla demos now work for me, but maybe you forgot about "timedemo"? There need the same fix, in my opinion.

Yep, I missed that, my bad. I'll fix it soon.

PVS said:

2. About demo auto-detect: use the same hex numbers as the vvHeretic for player 1 byte - it's the right idea, but for "nomonsters", "respawn" and "longtics" vvHeretic use 02, 20, 10. After recording demos in Chocolate Heretic I see results: 03, 21, 11 (like +1) for this modes. You think it is better? In my opinion, it is better to use the same numbers as the vvHeretic, just to make it equally. Of course, technically it is not important and will work.

This would only be confusing to someone specifically using a hex editor to dig through the files, and if they're working at that level then I'm pretty sure they can also figure out why the discrepancy works on their own: that's precisely how I reverse-engineered this change in the first place. You can call this lazy, but my opinion is that the difference is inconsequential as long as both of them work identically in each other's format (and they do).

[PVS]

Yes, this byte technically it is not important there, as well, this +1 allows to easy identify that demo recorded by Chocolate, maybe this has some sense.

I found another interesting situation, for example: if playback demo on vanilla Heretic (demo recorded by vvHeretic and have this byte 20 'respawn') - under certain circumstances this modified byte can get into the savegame. If the load this savegame and try record demo - vanilla demo have this modified byte 20, no matter what mode you are using for recording. On vanilla (maybe in vvHeretic too) possible record nomonsters demo with this respawn byte 20, and if try playback this new demo on Chocolate or vvHeretic with auto-detect - of course, we have desync, because the wrong mode will be auto-detect.

This is a very rare situation, I'm sure, it does not big matter for Chocolate or any other port, but for my small hobby/project - this is important and there is a need to resolve this situation. I think, very difficult to understand what I wrote here (my bad english), I just tried to tell this, maybe someone will be interesting.

[CapnClever]

If you can find a reproducible method to cause the above problem, I'd be happy to fix it... but make sure that the first step involves Chocolate Heretic. I can't guarantee that vvHeretic is bug-free, nor am I interested in fixing it if it is: my understanding is that vvHeretic was created by directly hacking the original EXE, and that kind of coding wizardry is not in my skillset.

[Michael92]

Does Chocolate Doom associate IWADs with correspoding -gameversion parameters by itself or needs to be manually set in batch files? For example 1.9 for Doom 2, ultimate for Ultimate Doom, hacx for HACX etc?

[CapnClever]

Game version is determined automatically when possible. Above all this means keeping the original filename of the IWAD, so if you can keep them as-is, that'll do.

There's some work being done into compatibility outside of 1.9 versions, which will make the -gameversion parameter a little more significant. As an example of a practical usage with 1.9 versions, you can choose to run Doom II using Final Doom gameversion, which changes some emulation.

[PVS]

How about Heretic v1.0 emulation? This task present in the project team plans? It is not have a priority, of course.

CapnClever said:

If you can find a reproducible method to cause the above problem, I'd be happy to fix it... but make sure that the first step involves Chocolate Heretic. I can't guarantee that vvHeretic is bug-free, nor am I interested in fixing it if it is: my understanding is that vvHeretic was created by directly hacking the original EXE, and that kind of coding wizardry is not in my skillset.

Ok, if you are interested then you can follow this steps:
1. start playback demo which contain a non-standard player1 byte (for example take byte 20 'respawn');
2. without waiting when the demo is over -> start a new game (ESC -> New Game);
3. save this game (in the first slot, for example). Now, in this savegame will be save 'parasite' byte 20, it is possible for Chocolate Heretic, Vanilla and vvHeretic;
4. start record demo from this save slot: -recordfrom 0 newdemo (record standart demo, not -nomonsters, -respawn, etc.).

If you look this newdemo.lmp - you will see, that standart demo contains player1 byte 20. Possible record such demo on Vanilla and vvHeretic, yes - now it is not possible record such demo with wrong byte on Chocolate, because you manually write player1 byte in auto-detect function. But, if such demo recorded by Vanilla or vvHeretic - only Vanilla can playback this demo, because Chocolate or vvHeretic will be auto-detect wrong mode and will try to play this record as 'respawn'.

As I said earlier - this is a very rare situation, and no one would follow this stupid steps, but technically - this is possible and it can be seen in Heretic code, this byte value is not important - it may have any value. I do not think that this issue is big important, Chocolate Heretic now can write not correct byte only in savegame, but him write correct byte in demo.lmp, it's enough.

I'm resolve this issue for my project, because sometimes this strange bytes I've seen in my test demos, but could not understand the reason why this is happening. Only now I realized what is the problem, this is important in the following situation: Chocolate Heretic, Vanilla and vvHeretic - start play demo from command line -> play this demo -> and exit, other embodiment not assumed, but how about situation - if you not need shut down the game engine? For some time I'm trying to make a modification for the very old version of jHeretic port which was would fully compatible with the original Heretic demo format. In jHeretic I do not need restart the game engine, I can play 10 demos -> start new game -> save/load game -> record 10 demos -> etc., all in real time, without the need to restart the engine. I see many 'parasite' and 'stupid' situations for demo record/playback, because the engine working in real time. It's not important for Chocolate project, but maybe you can better understand, what I'm talking about.

***
About demo auto-detect: I see that vvHeretic can automatically playback net demos, I test and found values that it uses, something like this:

#define DEMOHEADER_DEATHMATCH 0x04
#define DEMOHEADER_COOPERATIVE 0x08

I've added it to my project, works fine, for me now automatically playback net demos, and record required bytes for this, like in vvHeretic. If you want to add support auto-detect net demos in Chocolate - try these values.

[CapnClever]

PVS said:

1. start playback demo which contain a non-standard player1 byte (for example take byte 20 'respawn');
2. without waiting when the demo is over -> start a new game (ESC -> New Game);
3. save this game (in the first slot, for example). Now, in this savegame will be save 'parasite' byte 20, it is possible for Chocolate Heretic, Vanilla and vvHeretic;
4. start record demo from this save slot: -recordfrom 0 newdemo (record standart demo, not -nomonsters, -respawn, etc.).

If you look this newdemo.lmp - you will see, that standart demo contains player1 byte 20.

Couldn't reproduce using this method: player one byte is still 0x01 when looking at the demofile from step 4.

You know -recordfrom doesn't work correctly in vanilla, right? The load only sets difficulty/episode/map, ignoring the state of the current map. Even if -recordfrom worked as expected, there's nowhere for a savegame file to store miscellaneous information like -repsawn or -nomonsters. I suppose persistence could become a problem if you fashioned a source port that allowed demos to be recorded and played back multiple times within a single game session, but that's simply not the case with vanilla nor with Chocolate.

PVS said:

About demo auto-detect: I see that vvHeretic can automatically playback net demos, I test and found values that it uses, something like this:

#define DEMOHEADER_DEATHMATCH 0x04
#define DEMOHEADER_COOPERATIVE 0x08

I'll look into it, thanks.

As for Heretic v1.0 emulation, it's not on my to-do and no one else (to my knowledge) is all that interested in Chocolate Heretic/Hexen specifically. I don't know of any comprehensive documentation detailing the differences between versions, either, so it could possibly be a massive undertaking.

[PVS]

Hm, I checked my test demos that record some time ago and see - for Chocolate Heretic test I used latest stable version (2015). Now testing recent unstable version - I do not see this issue, in savegame I see correct byte. Seemed to me that I tested unstable version, my mistake, sorry...

CapnClever said:

You know -recordfrom doesn't work correctly in vanilla, right? The load only sets difficulty/episode/map, ignoring the state of the current map. Even if -recordfrom worked as expected, there's nowhere for a savegame file to store miscellaneous information like -repsawn or -nomonsters. I suppose persistence could become a problem if you fashioned a source port that allowed demos to be recorded and played back multiple times within a single game session, but that's simply not the case with vanilla nor with Chocolate.

You not understand me correctly, it does not matter how -recordfrom work, it load the savegame and start record demo, this is sufficient for my example. If you try with vanilla, vvHeretic or latest stable Chocolate Heretic (2015) - you will see not correct byte in savegame in HEX, and from this savegame - he gets in new demo file. But ok, i's not important now, recent Chocolate Heretic builds not have this problem.

[fraggle]

PVS said:

I found another interesting situation, for example: if playback demo on vanilla Heretic (demo recorded by vvHeretic and have this byte 20 'respawn') - under certain circumstances this modified byte can get into the savegame. If the load this savegame and try record demo - vanilla demo have this modified byte 20, no matter what mode you are using for recording. On vanilla (maybe in vvHeretic too) possible record nomonsters demo with this respawn byte 20, and if try playback this new demo on Chocolate or vvHeretic with auto-detect - of course, we have desync, because the wrong mode will be auto-detect.

FWIW, there's now a -strictdemos command line argument that will disable all demo format extensions, so that demos will be recorded exactly as vanilla, if that's what you want.

Since the extension bits are a small convenience that doesn't break compatibility with the original format, I'm okay with having them enabled by default.

[PVS]

I think this is the good decision, when present a choice of which mode to use - this is the right way, in my opinion. This may also help in situations about which we do not know at this moment.

About demo auto-detect: I'm also use it by default and do not see here any problem. Only for information: this byte modification can cause problems in some LMP-tools, maybe only for old tools, but one of this lmp-tool I always use to check Heretic demos, this program always gives an incorrect result if players byte not 01.

I would like to ask - for you interesting information about demo recording/playback on Chocolate engine itself? I will explain - my interest is associated with Heretic/Hexen games and demos in original format on it. Recently I started testing for demo desync problems Chocolate Heretic/Hexen too and see some problems for your project. For example this Heretic-N record:
http://82.66.133.154:85/Heretic-N/Demos/Max-bp/h5f3-803.zip

This demo go to desync on the latest unstable Chocolate Heretic builds, but have normal sync on the latest stable version (2015). On this time I have one more example for Heretic, but need playback 50 min to desync problem. Also, I found some problem demos for Chocolate Hexen.

If information about demos is not very important for project - you tell me, so I did not bother unnecessary for you information.

[fraggle]

Any demo desyncs against Vanilla Heretic/Hexen are certainly interesting - please do file bugs. For obvious reasons, historically Heretic/Hexen haven't had as much testing as Doom has had, so I quite expect there to be bugs like this that we should fix.

Ideally we should add something like statcheck testing for Chocolate Heretic/Hexen but it's difficult since there isn't an analogous DOS tool (to statdump.exe) to use for comparison.

[PVS]

I know, Doom always will be unrivaled, but not for me, I'm Heretic guy :) I will try to help with Heretic, because I have desync again, in the third demo. Common in these three situations that a player attacks Minotaur on E2M8, E3M7 (and E5M3 on my expamle in the previous message). I think, problem for latest Chocolate Heretic builds maybe somewhere in Minotaur, Heretic have good map for test this assumption - E5M8, there we have only Minotaur. This other records from Heretic-N, all have desync in Chocolate:
http://82.66.133.154:85/Heretic-N/Demos/Speed/h5s8-250.zip
http://82.66.133.154:85/Heretic-N/Demos/Speed-bp/h5b8-608.zip
http://82.66.133.154:85/Heretic-N/Demos/Max/h5m8-400.zip

Checked about 5 other E5M8 speedruns - not sync on the latest Chocolate Heretic build (for me build 20161203), but you have normal sync for this demos on the stable version (2015). I record some test demos for to try to localize - where it in Minotaur can be a problem and see: when Minotaur attacks and hit me with 'Floor fire attack' - demo start to go in desync (in this topic is not allowed to add attachment?), "-strictdemos" parameter not help me resolve this.

I think, you can try to check Minotaur, maybe only in A_MinotaurAtk3, maybe all Minotaur code and its dependencies. Seemed to me, somewhere in there you could lose compatibility and perhaps this is the only one mistake, because I playback full Episodes MAX demos on the latest Chocolate Heretic build, there player used all weapons, artifacts, goes through all maps with all monsters - 50 min all works fine, but in the end of the demos player meets with Minotaur, and immediately demo goes into desync. If you want to see this full episode demos, you can be found them in this messages:
https://www.doomworld.com/vb/post/1693044
https://www.doomworld.com/vb/post/1693470

I hope, this information will help you guys, but I could be wrong, of course. I have some information about Chocolate Hexen desync, will try to explain it later.

[Danfun64]

Do they desync in vanilla? If they do, then its possible that they were recorded in Chocolate Heretic. If they don't, then Chocolate is at fault.

[fraggle]

Interesting - this is (somehow) the first time I've encountered the Heretic-N archive. I've uploaded a copy to archive.org.

It would be good if we could get the Heretic-N archives incorporated into statcheck so that we can do automated regression testing (like we do with Compet-N). The catch is that we'll have to manually verify every demo, but maybe we can do something to help automate that.

[PVS]

Danfun64
Any demo from Heretic-N must be compatible with vanilla, if demo not require extended features. I remember a few strange demos in the database, but their quantity is small.

fraggle
Heretic-N is old, I do not know exactly when Vincent Catalaa created this base, but I have him demos dated 1998. Last page from Vincent there, but he long time not updated its archive:
http://lsvc.free.fr/Heretic-N/
JCD created a separate and updated database in 2014, he is the last Heretic speedrunner, whom I know. Heretic's guys quantity very few, if you look 'Players' table - of less than 20 for all-time. Chocolate team have Heretic guys? You welcome! Many tables still empty, until today...

Another question: Chocolate Heretic can playback net demos? I tried two ways for playback coop demos: with '-playdemo + -solo-net' parameters and '-playdemo + -server'. In both cases - demo start to play, but soon I have "Consistency Failure" engine error. Some coop demos you can find here:
http://82.66.133.154:85/Heretic-N/Demos/Coop/

[fraggle]

2.3.0 is out.

[Csonicgo]

fraggle said:

2.3.0 is out.

Awesome news. I take it this will be the last Win9x capable version (without KernelEx or other file modifications)?

[chungy]

No.

[ReX]

I'm curious about something. The name of the zip file for Windows suggests it's for Win32. I just tried v2.3.0 on a Win7 64-bit system and it seemed to work as intended. Is the nomenclature just an artifact, or is v2.3.0 primarily intended for 32-bit systems only? I've poked around the included text files a bit, but haven't been able to find an answer.

[fraggle]

64-bit Windows can run 32-bit binaries.

https://en.wikipedia.org/wiki/WoW64

[chungy]

It might be worth renaming the zip files to something less confusing. *-win.zip perhaps, or *-windows.zip. or just leaving out that moniker entirely (granted, chocolate-doom-2.3.0.zip might be interpreted as a source archive if somebody is looking at a file listing only, but I don't think there's a big danger of that...).

[fraggle]

It's just a filename, and I think the downloads page is pretty clear.

Although Richard Stallman at one point tried to push for "w32" instead of "win32" because he didn't like the idea that using Windows would be "winning". Pretty funny.

[chungy]

Yeah, but it led to ReX's brief confusion about what OS the binaries are supposed to run on. :)

[ReX]

chungy said:

... ReX's brief confusion about what OS the binaries are supposed to run on...

I imagine the simplest way to avoid confusion in the future is to say something in the text file to the effect that the program will work on both types of system. [Of course, regular users of Chocolate DooM probably already know this.]

But thank you, Fraggle, for the response.

[VGA]

The confusion comes from Rex not knowing that x64 windows can run 32bit code. The naming is just fine. That's how I always see it in all kinds of software.

win32 or x86 for the 32bit version and win64 or x64 for the 64bit

[axdoomer]

Most people don't even know what 'win32' means, so they don't ask themselves the question.

If you replace it with 'x86', even less people will ask themselves the question, because they'll have more chance to have no idea what it means.

The point is, if the person doesn't know what it means, then that person will run the executable without asking any question.

[ReX]

VGA said:

The confusion comes from Rex not knowing that x64 windows can run 32bit code.

You are probably correct. But I think I was confused mainly because GZDooM comes in a 32-bit version and a 64-bit version, and (if I recall correctly) there is some incompatibility.

At any rate, all is well now, and Chocolate DooM runs fine on my 64-bit OS.

[Edward850]

ReX said:

You are probably correct. But I think I was confused mainly because GZDooM comes in a 32-bit version and a 64-bit version, and (if I recall correctly) there is some incompatibility.

You recall incorrectly. There is never an issue running 32bit programs on 64bit Windows. Only the inverse is incompatible (you can't run 64bit programs on 32bit systems).