Chocolate Doom

[axdoomer]

3 hours ago, PVS said:

axdoomer
I mean, if you record demo for this map on Chocolate Heretic - it will be playback with desync on Chocolate Heretic. Similarly, if you record on vanilla Heretic 1.3 - vanilla Heretic can't playback this demo without desync.

 

HereticProblem.zip

Yeah, but if they don't desync the same way in both engines, it means that Chocolate-Heretic is not emulating Heretic.exe correctly. The point is, it's OK if they desync (the desync won't be fixed), but they must desync the same way in both engines.

 

I took a look at two of yours demos. They will desync the same way when played back on the same engine, but they don't desync the same way that they do on Heretic.exe when played back with Choco.

 

Sometimes the map errors that cause this are invisible. There could be corrupted data inside the PWAD that makes an overflow, etc. I suggest you open an issue on Github where people will discuss about this issue.

[PVS]

I understood what you're talking about. The fact that different engines (vanilla vs choco) in different ways playback the same demo - I saw from the beginning. Even more, at first I found this problem (for me) from one more engine, the third one, I also sometimes work with the Heretic code as a hobby, but I'm more a Heretic fan than a programmer. This third engine - shows its own version of the playback with desync, in comparison with the vanilla and Chocolate :)

In the usual situation, I mean - if this is an ordinary problem demo with desync - I agree, that we should observe completely the same playback on vanilla vs Chocolate, but it seems to me, in this case - there must be another reason. For me it even turns out that the vanilla Heretic 1.3 reproduces these demos in different ways, depending on the system on which I run it. For me Heretic 1.3 always equally and stable playback with desync these test demos - only under normal DOS7, under Win95 and WinME - It shows for me different playback variants.

Maybe I found something: in these 2 problem maps I see REJECT lumps with zero length, I found some information about this and I think this could be a problem for the engine. axdoomer, most likely, we see for this maps a Heretic "Reject Overflow", what do you think, is it possible?

I realized that for such questions - it is better to use Github, but for my old PC it's impossible, this site does not work correctly on my old browser, this is only my problem, of course.
 

Edited July 8, 2017 by PVS

[axdoomer]

6 hours ago, PVS said:

For me Heretic 1.3 always equally and stable playback with desync these test demos - only under normal DOS7, under Win95 and WinME - It shows for me different playback variants.

Maybe I found something: in these 2 problem maps I see REJECT lumps with zero length, I found some information about this and I think this could be a problem for the engine. axdoomer, most likely, we see for this maps a Heretic "Reject Overflow", what do you think, is it possible?
 

 

I guess the way the demo desyncs has to do with the OS, just like there it's possible to use magic values in Chocolate-Doom to emulate the behavior caused by memory overruns from badly constructed donuts in Doom. The default magic values emulate DOS 7.1 (Windows 98). 

 

Others would know more than me about this, but I don't think behaviors caused by zero-length REJECTS are possible to emulate.

 

I'm reading the DoomWiki and it says:

"For demo compatibility, Chocolate Doom and PrBoom plus attempt to emulate this behavior on small overflows by predicting what would be in memory after the REJECT lump, but it is nearly impossible to do on larger overflows, and many demos on maps with very short reject tables would desync even in vanilla Doom."

Edited July 9, 2017 by axdoomer

[PVS]

I'm test problem with this 2 Heretic maps more deeper. I'm replace only Reject lump in this maps using the standard min-length Reject lump generated by node builder program. Demos recorded for this new test wads - playback normally on vanilla and Chocolate Heretic. Now I am sure that the problem for these maps is in these incorrect Reject lumps.

Also, I see that Reject can be a problem not only for demo recording/playback as well as for a single game mode. I can see this well on the example of the second problem map (Sym.wad), where in a single game I notice that monsters sometimes do not see the player, they run around him and do not cause damage, i.e. it turns out - that map does not work correctly in single game mode if game engine has a problem at this moment with not correct Reject.

I did not know that the Chocolate project already has a solution for this problem, now I see it in 2.3.0 source code - you do this for Doom and Strife games. I think, the Heretic also needs this decision, perhaps even better - to do it right away for all games, maybe for Hexen also to be found such problem vanilla maps with non-correct Reject lumps.
---------------

Chocolate Hexen compatibility.
I see a problem with map-11 from the IWAD: demos recorded on Hexen 1.1 playback with desync on Chocolate Hexen, demos recorded on Chocolate Hexen playback with desync on Hexen 1.1. Attaching my test demos.
 

HexenMap11.zip

[axdoomer]

I've opened a new bug report, but I'm pretty sure zero-length REJECTS are impossible to emulate. Let's see if at least adding this to Heretic and Hexen is going to improve something. I could help emulating small overflows, when the REJECTS is missing a little bit of data.

[PVS]

Thanks, maybe it will be added in Heretic too.
I do not quite understand what you mean under "emulating Rejects overflows", you probably mean another solution to this problem? What I see in the Chocolate Doom project more like as additional fix for Reject lump with small size, not any emulation, in my opinion.

I'm test Chocolate Doom, took a random map for Doom2, cut Reject lump to zero - this Reject fix normal work, map itself work normally and demos, recorded on this test wad - playback correctly. Also, I see that PrBoom+ can playback normally this test demo recorded on Chocolate Doom.

I added this Reject fix to the Heretic, this is also works fine here. I do not see much sense in Heretic demos, recorded with this fix, because they are not compatible with vanilla, only for a normal single game mode it makes some sense, in my opinion.
 

[SaladBadger]

Apparently Chocolate Doom doesn't emulate an oddity where the game always loads SKY3 in Doom II regardless of which map you're loading, apparently due to a rewrite of the function in question. I checked vanilla, and it seems to error out when trying to load the first map in a wad lacking SKY3, so I suspect this should probably be looked into.

[Jon]

I don't fully follow the error behaviour. Can you please file a GitHub issue?

[fraggle]

It sounds a bit like this bug, which I think we're emulating correctly (this commit is the most recent tweak to the logic). But maybe I'm misunderstanding.

[SaladBadger]

Its unrelated, I believe. What the game is trying to do is get the ID of the texture SKY3 any time you start a new game in Doom II, and it sets that as the current sky texture ID. It then proceeds to check if you're on a earlier map, and swaps it out for the right one. As a result, if you load up a wad that happens to not define SKY3 for whatever reason in its TEXTURE1 lump, the game errors out, since it tries to get the SKY3 texture ID even if you're not on map21 or above. The relevant code from the Linuxdoom source, and here's a sample wad. If you load this wad up in plain old Doom 2 1.9, it will crash if you try to start a new game, even on MAP01, but Chocolate Doom loads you into MAP01 just fine (of course, it will error out if you try to load MAP21 or above)

 

[fraggle]

Thanks for clarifying. Can you please file a bug, then? Thanks.

[SaladBadger]

Alright, I have filed a report

[kb1]

@PVSYes, when a map has no reject, or too small a reject, vanilla reads undefined memory, meaning that sight depends on the contents of whatever happens to be in memory. In DOS, this usually doesn't cause a crash, and, if the Reject table is only a bit too small, it may not even go noticed.

 

Cause it's random memory, demos become unreliable, but, amazingly, this causes less problems than one might expect, if some assumptions are right:

 

If you can assume that, #1, memory is often initialized to 0, and, #2, it's more likely that a given sector cannot see another sector, you get these results:

 

1. If the memory bit being read = 0, the engine will do full sight checks, which should be accurate.

2. If the memory bit being read = 1, and the 2 sectors actually cannot see each other, this is also an accurate result.

 

Stated differently,

 

If bit = 0 and visibility = False, no problem.

If bit = 0 and visibility = True, no problem.

If bit = 1 and visibility = False, no problem.

If bit = 1 and visibility = True, possible desync.

 

The failure can only happen when a seer in one sector should be able to see a target in another sector, but a read into "random" memory yields a 1 bit. So, that's a theoretical 25% chance, possibly made even lower by the frequency of memory being initialized to 0, and the good chance that most monsters are behind doors, or in different rooms.

 

Don't get me wrong - it's gonna desync. I just find it kinda interesting how good this issue can evade detection for a good portion of a demo play. I've seen these kinds of demos succeed, I've seen them get real far before failing, and I've also seen them fail quick, but less often.

 

So, you want to add padding for Chocolate Heretic/Hexen, or were you considering something in addition to that? (Just curious).

 

[PVS]

kb1, this is interesting technical information for me, thanks.

Yes, in my opinion, this "Reject fix/padding" can be added to the Heretic in a similar form as it is now present in Doom/Strife games in Chocolate project. Of course, I understand, that Doom has a huge number of wads and a huge number of players vs Heretic/Hexen, perhaps for this reason it makes more sense and motivation that this fix now work for Doom game. But I do not see any technical problems if this solution will work in Heretic/Hexen too, even though this task is of low priority and will rarely be used in these games. Also, maybe it's worth adding the option - to disable this Reject fix/padding, that will rarely be used too, maybe only for tests or technical interest, but such a possibility will correspond to the overall project philosophy, in my opinion.
 

[kb1]

9 hours ago, PVS said:

kb1, this is interesting technical information for me, thanks.

Yes, in my opinion, this "Reject fix/padding" can be added to the Heretic in a similar form as it is now present in Doom/Strife games in Chocolate project. Of course, I understand, that Doom has a huge number of wads and a huge number of players vs Heretic/Hexen, perhaps for this reason it makes more sense and motivation that this fix now work for Doom game. But I do not see any technical problems if this solution will work in Heretic/Hexen too, even though this task is of low priority and will rarely be used in these games. Also, maybe it's worth adding the option - to disable this Reject fix/padding, that will rarely be used too, maybe only for tests or technical interest, but such a possibility will correspond to the overall project philosophy, in my opinion.
 

You *may* want a way to disable the padding, just for old demo's sake. But, demos made with too short reject are not reliably playable anyway, except in rare cases. Having a short reject means that the engine is reading memory that it does not own, or memory belonging to something else in the engine. In this latter case, it won't "hurt" anything, except the reliably of the demo. But, in the former case, a engine not running in DOS can crash when the game tries to read this memory, so fixing the problem makes a lot of sense to do.

 

If you do fix the problem, consider changing the version number of the demo, so ports will know how to play the demo. This is very important.

[Cipher]

Really small question, now that I'm using the 3.0 beta--When I launch Chocolate Doom with one of the Final Doom iwads, on the automap screen, it still provides the level names from Doom II. I'm using a third-party launcher (Rocket Launcher), if that matters.

 

Short of making different folders with copies of Chocolate Doom and the iwads, is there a way to avoid this? Obviously not a huge deal of any kind, but it'd be nice to know.

[VGA]

Sounds like maybe you are still using the doom2.wad as an iwad and the final doom wads as pwads. You should load for example TNT.wad as an iwad.

[Cipher]

23 minutes ago, VGA said:

Sounds like maybe you are still using the doom2.wad as an iwad and the final doom wads as pwads. You should load for example TNT.wad as an iwad.

It's probably just the way the launcher is interacting with it then, if that's not standard behavior for the way Chocolate groups them. I'll play around with it!

 

(I only wondered because the launcher distinguishes iwads from pwads, but I was still getting the issue.)

[VGA]

Most launchers have the ability to show you the command line they are using, does this one have this, too?

[PVS]

Chocolate Hexen 2.3.0 (Win32):
1) Deathkings of the Dark Citadel. For me not possible to launch DM map 36, Chocolate go to quiet crash without visible errors in stderr.txt or stdout.txt. Vanilla Hexen normal open this map.

2) I discovered for myself the problem of the original game and Chocolate Hexen. For example: I'm -warp on Map 7 and Skill 3 from command line -> if I die on first map (without passing the first teleport) -> player always reborn on Map 1 and Skill 1. If I'm -warp on Map 1 and Skill 3 from command line, die on first map -> player always reborn on Skill 1. This is happens only for startup from command line, because if run game on skill 3 from main menu and die on first map -> player normally reborn on Skill 3.

In my opinion, for this reason, two bad situations are possible for Chocolate Hexen:
- player warp on Map 1 and Skill 3 (any skill > 1) from command line (used some PWAD's, for example) -> if he die on first map, player may simply not notice that he continues to play on skill 1;
- not possible record correct first attempts demos (FDA), where the deaths of a player is common, including deaths on the first map.

I see that Hexen+ resolve this situation, if warp on map from command line -> Hexen+ always forces creation of temp save game (base and reborn slot) and if player die on first map -> engine will use this reborn slot automatically and player always reborn on correct map and skill.

In my opinion, it would be good to fix this moment in Chocolate Hexen.
 

[theleo_ua]

Reported issue with chocolate hexen (probably all games affected): 

 

KP_INS and KP_DEL keys are not recognized by game: https://github.com/chocolate-doom/chocolate-doom/issues/958

 

Question: is it possible to implement functionality which differ original and KP keys, so I can bind one event (for example fly down) to INS key, and another event (for example stop flying) to KP_INS key?

Thank you in advance

[Jon]

46 minutes ago, theleo_ua said:

Question: is it possible to implement functionality which differ original and KP keys, so I can bind one event (for example fly down) to INS key, and another event (for example stop flying) to KP_INS key?

 

This is only possible if SDL distinguishes the two, since that's the interface that sits between our code and the hardware. So if it does, there's no reason why we wouldn't support that; however, if this doesn't already work, that suggests to me that it SDL likely doesn't.

[theleo_ua]

17 minutes ago, Jon said:

 

however, if this doesn't already work, that suggests to me that it SDL likely doesn't.

Tried on chocolate hexen 2.3.0-win32 and it doesn't work (both with numlock and without)

 

So, if I understood you corrrect, if this is SDL issue, but this works in GZDoom and Doomsday (I can bind different events to that keys on those ports), so this means that GZDoom and Doomsday doesn't use SDL for hardware input?

[theleo_ua]

Reported issue with chocolate hexen (probably all games affected): Music is not playing after help menu (F1): https://github.com/chocolate-doom/chocolate-doom/issues/961

 

First part of the bug is reproduced in vanilla, but second part of the bug is not reproduced in vanilla

[Herzon]

Sounds like a tasty source port! *badumtis*

[Master O]

On 12/5/2017 at 5:17 PM, Herzon said:

Sounds like a tasty source port! *badumtis*

 

*Throws tomatoes at Herzon.*

[Krawa]

Chocolate Doom master server has a problem?

No servers are shown there.

https://master.chocolate-doom.org/ 

[Jon]

Oh, we rebooted the hosting server a few days ago, maybe the chocolate server hasn't restarted.

[Cacodemon345]

Suggestion, can you (fraggle) add support for Doom v1.11's increased visplane and drawseg's limit?

Basically, emulating Doom v1.11 behaviour?

[fraggle]

1 hour ago, Cacodemon345 said:

Suggestion, can you (fraggle) add support for Doom v1.11's increased visplane and drawseg's limit?

Basically, emulating Doom v1.11 behaviour?

Sorry, this has been asked for before many times and I've declared it out of scope for the project.