Skip to content
This repository has been archived by the owner on Jun 23, 2023. It is now read-only.

Extensible demo format + "PR+UM" signature #107

Merged

Conversation

XaserAcheron
Copy link
Contributor

@XaserAcheron XaserAcheron commented Jul 12, 2020

Hey y'all,

There's been some talk about extending the demo format + signature in the Doomworld thread recently, so I figured for convenience's sake, I'd make a PR for anotak's implementation of this. It's gotten some eyes on it in the past, code-review-wise but we may as well get the ball rolling on getting it submitted for real.

More comments on this (plus a quote from Graf showing support for the idea, in case that was in question) on DW here.

prboom2/src/g_game.c Outdated Show resolved Hide resolved
prboom2/src/g_game.c Outdated Show resolved Hide resolved
@XaserAcheron XaserAcheron changed the title Extensible demo format + "PRB+" signature Extensible demo format + "PR+UM" signature Jul 18, 2020
@XaserAcheron
Copy link
Contributor Author

Just merged in some changes from Altaz that should address all the concerns -- apologies for the delay; GitHub chose not to notify me about this for some reason. o_O

prboom2/src/g_game.c Show resolved Hide resolved
prboom2/src/g_game.c Show resolved Hide resolved
prboom2/src/g_game.c Outdated Show resolved Hide resolved
@Altazimuth
Copy link
Contributor

It's been a bit since the last comments. Is there any additional hold-up left on this?

@fabiangreffrath
Copy link
Collaborator

It's been a bit since the last comments. Is there any additional hold-up left on this?

It's controversial, to say the least. And the project owner @coelckers has yet to give a sign of acknowledgement.

@Altazimuth
Copy link
Contributor

Altazimuth commented Nov 12, 2020

I was under the impression all the issues that caused any controversy have been ironed out, and I probably wouldn't wait on Graf. I don't recall him acknowledging this project for at least half a year.

@XaserAcheron
Copy link
Contributor Author

This PR is basically the thing that is stopping this port from being accepted as an "official" successor to prboom-plus mainline, and there are no unaddressed issues here. What's the hold-up?

@fabiangreffrath
Copy link
Collaborator

This PR is basically the thing that is stopping this port from being accepted as an "official" successor to prboom-plus mainline, and there are no unaddressed issues here. What's the hold-up?

I somehow feel addressed by this complaint, because apparently I am the only one left with commit rights who is still actively interested in this port.

First of all, this patch is very intrusive, given that it all started with the insertion of a single 0xff byte right before the actual demo signature to indicate that this is a UMAPINFO demo.

Second, this implements what someone else - who is not the author of this fork and thus not the author of the UMAPINFO reference implementation - wants UMAPINFO demo headers to look like. This, without a single sign of acknowledgement by the original author.

Third, there is still an open question regarding the nesting of demo signatures and the necessity of the MBF demo signature. There are questions asked by @Ferk and @kraflab in July and I requested elaboration just yesterday, because - frankly - I fail to understand this part of the code as well.

I understand there is probably not much that can be done about point 1 if we want to keep this level of complexity. Same for point 2 which is nothing that anyone of you could be blamed for. What I'd really like to have, though, is confirmation (a) that UMAPINFO demos can be recorded and played back with any complevel and thus embed demos in any other format, (b) that this is forward and backward compatible with The Eternity Engine, and (c) that UMAPINFO demos will be detected and rejected by non-UMAPINFO ports (such as Chocolate).

@kraflab
Copy link
Collaborator

kraflab commented Nov 16, 2020

Would it help if we split this into two pieces?

  1. Define / implement the next generation of the demo format, with a flexible and extensible header.
  2. Add umapinfo support to that new format.

In particular for (1) it would probably help if there was a (non code) specification of the format to look at to answer the questions raised about compatibility and make sure everyone is on the same page. Maybe that exists on the forum already and could just be linked.

@fabiangreffrath
Copy link
Collaborator

@kraflab nice idea, though I somehow expected (2) before (1).

Copy link
Collaborator

@fabiangreffrath fabiangreffrath left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I gave this patch another review.

In general, the part in G_BeginRecording() looks good to me, but raises a question as to when the special UMAPINFO treatment gets triggered (if UMAPINFO lump found and loaded vs. if demo start map has UMAPINFO changes applied).

Then there is a either misconception about MBF using 0xff as its demo version number, or I am missing something.

Third, there is a copy/paste bug in the G_ReadDemoHeaderEx() part that needs to be addressed - and that leaves me wondering how much this code has actually been tested in real life scenarios.

Please address these issues before we can proceed, thanks!

demostart = demo_p = malloc(1000);
longtics = 0;

if (umapinfo_loaded)
// ano - jun2019 - add the extension format if needed
if (gamemapinfo)
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is this changed from umapinfo_loaded to gamemapinfo here? AFAIUI, gamemapinfo is only set if there is UMAPINFO information available for the current map, whereas umapinfo_loaded is set a soon as a UMAPINFO lump is found and loaded. But what if we start a demo from a map without UMAPINFO changes and then migrate to UMAPINFO affected maps during the course of recording?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch -- it indeed oughta be umapinfo_loaded. I whipped up a test wad which contained UMAPINFO for maps 2, 3, and 4, recorded a demo starting from MAP01, and it skipped writing the extension header entirely. Got a fix incoming.

return NULL;

// we check for the PR+UM signature as mentioned.
// MBF and Eternity Engine also use 255 demover, with other signatures.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think MBF uses 203 as its demo version number. Please double-check and correct here if this is true or tell me if I'm wrong. ;)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed. :P

I_Error("G_ReadDemoHeader: Unable to determine map for UMAPINFO demo.");
}

episode = (episode * 10) + (cur - '0');
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be map here instead of episode, right?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yup. Fixed.

@XaserAcheron
Copy link
Contributor Author

Finally had some time to sit down and play around with this some more -- tl;dr: made all the requested changes.

I put together a quick test wad while I was at it to repro & fix the troubles:
umapinfo-test.zip

The wad contains a couple of maps, + a UMAPINFO file that defines maps 02, 03, 33, and 04 (but not MAP01), and sets up a branching path to MAP03/MAP33 via secret exit on MAP02.

I recorded umapinfo-test-demo-bad.lmp before the requested changes, and sure enough, it lacks the extension header. I was able to play it back on mainline PRBoom-Plus, where it desynced after hitting the secret exit switch in MAP02. Meanwhile, umapinfo-test-demo-good.lmp was recorded after the fix, and it's got the new header in place (non-forked PRB+ correctly aborts with an error). Both play back as expected on this branch, but it's the abort-on-old-versions behavior we're really after here.

@fabiangreffrath
Copy link
Collaborator

@XaserAcheron Thank you very much for taking care of the requested changes!

One last thing that still annoys me is the completely redundant parsing of the ExMy/MAPxy level name. I know, the reason is that it should be possible in the future to have non-standard map names defined by UMAPINFO. However, the current implementation does not support this and even UMAPINFO's own G_ValidateMapName() [1] does not support it either. So, it is very unlikely to happen anytime soon and I'd rather prefer to have this entirely removed and delayed for a v2 format specification.

Anyway, it seems to work as intended now and I am not going to argue about this PR anymore.

Merging, merry (late) Christmas everybody! 🎄

[1] https://github.com/XaserAcheron/prboom-plus/blob/7882c46da75554f9ffa996acded647904d867167/prboom2/src/g_game.c#L2692

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants