Reasonable subset of demo compatibility checking?

[wesleyjohnson]

Having spent a considerable amount of time trying to find such bugs in DoomLegacy, I have to agree with kb1 and Maes. The best laid plans often do not provide usable answers. I will probably have to use kb1's toolkit sooner or later (not yet, I got other stuff to work on!).

I would not leave such debugging in the code.
I would put it in, then diff against the original and save the diff as a debugging tool. Patch can put the debugging instrumentation in place, and take it out again. When the base code changed too much, Patch leaves files around the conflict. Done this many times, and it is easier to maintain when it is needed, then having it in there all the time.

[kb1]

wesleyjohnson said:

Having spent a considerable amount of time trying to find such bugs in DoomLegacy, I have to agree with kb1 and Maes. The best laid plans often do not provide usable answers. I will probably have to use kb1's toolkit sooner or later (not yet, I got other stuff to work on!).

Wesley, my offer still stands. When you're ready, send me a PM, and we'll work on desyncs.

I was kinda hoping that Maes would be my cheerleader, heh heh :). But, we both got sidetracked, and never had a chance to finish syncing Mocha Doom, though we did get it playing original demos pretty good. We stopped before we could try out my new toolkit. I think you'll be pleased with the speed that we get results. And, it's just kinda neat to see the output, and know exactly what Doom is doing each tic. I find it fascinating to look through.

jeff-d: Gez's suggestion is very good. Demo sync fixes are documented pretty well in PrBoom(+), but to implement some of them, it might be easier to implement Boom support than to backport some of the fixes to a vanilla-like port. I'd check out the timing on the startup sequence (170 tics vs. 200, IIRC), and lost-soul movement for starters. Of course, my toolkit would find your desyncs as well.

DaniJ: I suppose you could collect a small set of demos that focus on certain known aspects of compatibility. But, the problem is that, any port difference can trigger a desync. I don't know how you could reduce a collection of demos into a subset that catches all possible issues. I suppose you could have a demo that includes all monsters, all wall angles, trigger types, sector types. What I have found is that, typically, if your port has a desync issue, it will appear pretty soon. Not always, but, typically. That's because, all in all, there's only so many thing types, actions, triggers, etc.

Still, it would be interesting to try to create a "desync-rich" map.

[jeff-d]

kb1 said:

jeff-d: Gez's suggestion is very good. Demo sync fixes are documented pretty well in PrBoom(+), but to implement some of them, it might be easier to implement Boom support than to backport some of the fixes to a vanilla-like port. I'd check out the timing on the startup sequence (170 tics vs. 200, IIRC), and lost-soul movement for starters. Of course, my toolkit would find your desyncs as well.

My port goes out of sync on the built-in doom.wad & doom2.wad as soon as the first monster puts in an appearance. The trouble is that since the demos were already broken, I implemented all of the subsequent mods (Boom compatibility, DEHACKED, MAPINFO etc) without bothering to keep the demos even close to working! (In those days I didn't have access to all you helpful peeps, hence a lot of my code is a clean room reimplementation of the Boom specs). So I've given myself a bit of a hill to climb if I really want demos to work. The Aliens TC demo works fine for level 1 (no monsters) and goes out of sync on the second level as soon as we see the first baddie.

[kb1]

jeff-d said:

My port goes out of sync on the built-in doom.wad & doom2.wad as soon as the first monster puts in an appearance. The trouble is that since the demos were already broken, I implemented all of the subsequent mods (Boom compatibility, DEHACKED, MAPINFO etc) without bothering to keep the demos even close to working! (In those days I didn't have access to all you helpful peeps, hence a lot of my code is a clean room reimplementation of the Boom specs). So I've given myself a bit of a hill to climb if I really want demos to work. The Aliens TC demo works fine for level 1 (no monsters) and goes out of sync on the second level as soon as we see the first baddie.

From what you tell me, I think there's a good chance that your port is probably close to being able to play demos in sync - you might be surprised. It only takes one difference to put a demo completely out of sync. And, after a second or so, it will look completely wrong.

I started working on my port a long time ago, for many years before I started to care about demo sync. I made literally hundreds of idiotic changes - hard-coded differences to core action routines, info.c hacking, you name it.

Luckily, with the toolkit I keep trying to "sell", it works equally well at finding one desyncing issue, as it does with multiple issues. Basically, when a desync is found, you fix it, then start over, until an entire demo plays. Then you start on another demo.

I was really hoping someone would want to permanently host it (24k zipped), along with a couple of web pages describing the process, and how to implement it.

I would also want to host some output files, which are significantly bigger, but zip well.

At this stage, using the toolkit basically requires my help, as it is implemented in my home port, but not in any downloadable port. It's the comparison against a known syncing port, that allows desyncs to be fixed.

Eventually, I, or someone else, could implement it into a PrBoom+ or something, allowing it to be a downloadable executable. However, all that is really needed are the output files from a known syncing port.

[fabian]

fraggle said:

AlexMax said:

My question is, what demos would that consist of?

http://www.doomworld.com/vb/doom-speed-demos/35214-spechits-reject-and-intercepts-overflow-lists/

I think PrBoom+ actually has automated tests to test these demos. Not sure though.

I'd like to set up tests like these for Chocolate Doom as well, though I would like to do something more in-depth and precise than what statdump comparisons do (for the reasons I've listed above). Something like a hash of all the positions of all items in the level for every tic would probably be a good expected result.[/B]

Maybe these as well:

http://classicdoom.com/odddemos.htm

[kb1]

When I saw the bump, I was excited that I might be able to break out my sync debug tools for some demo sync debugging sessions with AlexMax, GhostlyDeath, wesleyjohnson, or jeff-d. I've been wanting to get that code going again for some time now. Shucks :(

Offer still stands, by the way. Specifically:

If these requirements can be met...
* I still have some time
* You're serious about bringing vanilla demo (and network, and live play) support to your port.
* You have a few hours to invest.
* Your port's source code vaguely resembles vanilla Doom's source code structure.
* You don't mind throwing my name in your credits file

...I offer my toolkit, and some of my time to assist you in achieving this goal.

I am excited about it. It's kinda neat to watch - like a demo, but with words. It shows how Doom works, in a way that's just not possible looking at the source code.

Interesting? Drop me a PM.

[Linguica]

kb1, I'll host the files on DW if you want. But why not make a project page for the tool on Github or somewhere similar?

[kb1]

Linguica said:

kb1, I'll host the files on DW if you want. But why not make a project page for the tool on Github or somewhere similar?

Oh, wow - cool! Ok, give me a couple of days to make a couple of web pages and make them purdy. Awesome! You know, it'll be missing one important half - the properly running port! When I was offering to help, I was offering the "toolkit" that you had to your port, whose output would be compared to a known working port, which was my home port, that I haven't yet released the source to.

So, I or someone will have to add the toolkit to a PrBoom, PrBoom+, or something. Or, you know, send me their output to compare, and I do the compares, which was what I was initially offering to do.

But, if we create a port that has the toolkit built in, anyone can do their own comparisons, which would be nice.

Something like a PrBoom+. Yeah, I'm thinking PrBoom+. Maybe that'll be Phase 2, or an "exercise left to the reader" (and then uploaded so we can all benefit:). Ok, I'll let you know when I'm ready.