Ultimate Doom tree driven into ground

[wesleyjohnson]

DoomLegacy now has MBF code, and one of the effects of this is that when playing an older game such as Ultimate-Doom, you can see some MBF features operating, such as corpses sliding down the steps.

 

I have been trying to implement some control that would allow selecting a gamemode, such as Ultimate-Doom gamemode.  There are several ways this could be used, but the default would be that if you play the Ultimate-Doom IWAD, it should default to the Ultimate-Doom gamemode.   Of course a user could use Boom gamemode to play Ultimate-Doom, or turn on specific MBF features too, if they wanted.  This is still a work-in-progress.

 

I am testing Ultimate-Doom, E3M1, and I see this tree, it is wandering about the surface as I move.  After considerable investigation, it turns out that it has been driven into the ground by crushing logic triggered by a nearby lift that came up.   This is what the older P_ChangeSector code is doing.  The Boom version P_CheckSector, does not do this.  I have been trying for several weeks now to discover what is wrong with the older P_ChangeSector, and is it a bug in our implementation (which is not pure original code).

 

1) Does anyone remember if this is this a known bug of the older P_ChangeSector code ?   I remember something about a tree driven into the ground, but cannot remember exactly what, nor find it by searching.

 

2) What is the desirability of a pure original gamemode for playing older wads such as Ultimate-Doom without any Boom enhanced code.  I could just keep using the Boom replacement code as it does not seem to have visible effects (unlike some of the MBF effects).  I could make it use the old P_ChangeSector ONLY for old demos, and keep using the Boom P_CheckSector for playing.

I was not really trying for ChocolateDoom purity anyway, but I am sure there are alot of opinions on this point, and I might as well hear them.

 

3) This gamemode control is probably not going to work out anyway, and I will probably have to settle on some other way to turn off MBF effects when playing older Doom wads.  But, I still will have to deal with this problem.   So, that begs the question.  What is desirable for such a control?  I seem to want to start with the original gameplay, but be able to add specific behaviors from Boom and MBF, even when playing Ultimate Doom.   The problem is in the user interface.  To be turning so much stuff off, but be able to selectively turn it back on, it is leading to having a separate config file for each gamemode.  This is getting really complicated fast.

 

[Giomancer]

I'm not a demo person, so I can offer no real opinion there.

 

As for a compatibility/gamemode control, I say screw it. For purists, there's Chocolate or PrBoom. I think you should go ahead and add the effects you want from Boom/MBF as long as you're consistent and fix the bugs that occur—such as this tree!

[fraggle]

Hey, just as some feedback: your opening post in this thread is quite rambling and it's difficult to follow what it's about. You seem to be talking about several things at once, specifically:

 

Is there a known bug in vanilla Doom, possibly related to the thing-crushing logic, which can cause trees to slide around the map? I don't think so, as far as I know. Maybe someone else has heard of this.

 

The other thing you're asking about is really a question of philosophical direction of your project. Is it worth preserving old (arguably broken) game behavior in the name of purity? The answer is "it depends what you're building". What is the guiding philosophy behind Doom Legacy as a project that allows you to make these decisions? For comparison, consider how other source ports approach this question:

• Chocolate Doom: The purpose of the project is to produce a source port that accurately reproduces vanilla Doom while making no effort to fix anything. This preserves demo compatibility but also gives a "pure" experience for users who want that. The decision is therefore easy to make.
• PrBoom[+]: The project is arguably a demo-focused source port which can play back as many different types of demos. The decision is therefore easy to make.
• GZDoom: The project is about providing a stable, modern, bugfixed version of Doom while making no effort to preserve vanilla demo sync, since it relies on game behavior bugs which are considered broken. The decision is therefore easy to make. 

Different behaviors are important to different users but I don't have a clear understanding of Doom Legacy's project philosophy or who it's aimed at. It's up to you to choose but I would encourage you to make the decision. It's worth considering that preserving many different behaviors does increase code complexity and will ultimately make the codebase more complicated and harder to maintain. If the project is more at the GZDoom end of the scale it might make more sense for you to simply declare, "Doom Legacy does not aim to preserve buggy behavior or demo sync" and be done with it. 

[Edward850]

21 hours ago, wesleyjohnson said:

you can see some MBF features operating, such as corpses sliding down the steps

This isn't an MBF feature.

[Linguica]

The only thing I can think of, is that the Doom engine does certain floor/ceiling movement checks by looking at the *bounding box* of a sector, not just the sector itself, and this can lead to utterly weird bugs where things that are not even touching a sector appear to be affected by it somehow.

 

 

[wesleyjohnson]

Thank you for the reserved responses.  I was rather expecting more of the "cater to our way" responses (remember the windows installation intervention).

 

The original post actually does not ramble, it is just very brief (and still went on for a whole page).  I kept it just to the basic info needed.  I doubt that more connecting paragraphs would of helped much.   The tree bug is the direct consequence of the first two paragraphs.

 

The behavior of the tree only happens if the Boom-support code is disabled.  The Boom-support has always been enabled for as long as I have worked on DoomLegacy, so this effect has never shown itself before.   I was sure that there would be a least two responders that insisted on reproducing some original effects faithfully, and I needed to know what that original effect actually was.

 

Catching the tree in a bounding box is exactly what is happening. 

It seems strange that the game was played by so many without seeing this wandering tree, but I cannot see how the older code was avoiding that happening.  The same code is in PrBoom, and it is only enabled for playing back old demos.

 

As for the MBF sliding corpses, I can attest to spending the time copying such MBF code into DoomLegacy.  It wiggles corpses sitting on ledges to tease them to fall off.  When it does not succeed, the effect turns itself off after a while.  It looks strange in Ultimate Doom though to see corpses gaining speed.  Prevously, a corpse may slide at first,  but if it stopped it stayed stopped.

 

I will wait awhile.  I suspect someone will show up with more insight, and possibly strong opinions..

 

 

[wesleyjohnson]

Scifista has an explanation that is close, except that the tree is not overlapping sectors.  The tree is just within the bounding box.  That gets it tested against the sky height.  The tree is 96 high, and the sky is 64 above ground.  The logic then pushes the tree down, without checking that it is against something.  I think that this logic would be better if it checked if the mobj was onground, and if it was, not moving it.  But, what would that break.

 

That PrBoom does not use this code for play, and only for demo playback, probably means that the Boom code is acceptable.

 I should probably just do the same.  I should only use this old code for Demos and not regress to it for gamemode reasons.

 

I still wonder how much players want their Ultimate Doom to play as the original did.  They can turn off most of the MBF behavior now, but to play Ultimate Doom that way they have to go through about five pages of options to turn them all off.

 

[fraggle]

46 minutes ago, wesleyjohnson said:

 

The original post actually does not ramble, it is just very brief (and still went on for a whole page). 

 

I was describing my subjective experience which was that your post was hard for me to follow. You can take that feedback however you want, but maybe it's worth considering that if you don't get many useful replies it's possibly because others had the same experience.

[fabian]

2 hours ago, wesleyjohnson said:

I will wait awhile.  I suspect someone will show up with more insight, and possibly strong opinions..

 

I don't even have an idea what tree you are actually talking about?

[kb1]

I do have strong feelings about what direction I would tend to take, and I ask that you read my entire response, and try to get into my head a bit, and understand my motivations for such a direction:

 

I believe you should:

• Save your entire project
• Use a subset of PrBoom+ code to get:

1. Exact vanilla Doom demo compatibility working as a complevel
2. Exact Boom and MBF compatibility, with their own complevels

• Add back all Legacy-specific code, either as

1. ...it's own complevel
2. ...a combo of the above complevels and Legacy, such-as Doom mode, Doom+Legacy mode, Boom mode, Boom+Legacy mode, MBF mode, MBF+Legacy mode
3. ...or with individual settings

For a long time, on these forums, I've been discussing my SyncDebug code that could probably be of great assistance to you, in achieving this level of demo+gameplay compatibility without having to do a big complete rewrite. I have not released it yet, because of the same reasons: I have no damn time. However, I've been making progress in my my Doom stuff lately. For SyncDebug, all that's missing is the description of how to insert the code into your port...everything else is done.

 

But, please, let me try to explain the motivations behind my recommendations:

• First of all, I do enjoy me some vanilla demo compatibility, but that's not why I am suggesting you go down this route. Legacy has, since its humble beginnings, always had some custom gameplay feel to it. On the other hand, Boom and MBF code kinda expect to be placed on top of vanilla code. For the most part, it doesn't really matter. But, for routines like P_CheckSector and P_ChangeSector, combined with MBF's thinker lists (that contained a bug fixed in PrBoom+, if I'm not mistaken), you run the risk of having code that is virtually impossible to debug, as it would require the monitoring of thousands of variables across many tics, coupled with exact, repeatable DoomGuy movement (use a demo instead). I remember having a VERY subtle bug in KBDoom's PIT Sector code that caused the long, twisty lift in E1M5 to fail to properly lift that drove me crazy. I can't remember what was wrong, but it was very hard to find.

• I fear that by not reverting back to vanilla demo compatibility, you end up in alternate universe syndrome, if you know what I mean. I worry that you will always be playing "catch-up", being plagued by subtle compatibility issues. In your original post, you seem to be considering a half-measure approach to solving the issue, which I fear is going to leave you with an engine that works "most of the time, on most maps" with a constantly moving target.

• When I finally get to release the Compatible Doom Extensions first draft (I'm very close now), and if you intend on trying to implement the extensions, you may have more problems down the road, if you don't bite the bullet and tackle this issue head-on.

Again, please understand that I am not trying to impose my will here. I've studied a lot of the predominant source ports in detail in the past, including Legacy, and I've noticed some of the things that Legacy has handled a bit differently. Nothing wrong with that...unless it chokes up other efforts, like Boom/MBF extensions. I am extremely busy with all aspects of life, and my Doom work has slowed to a crawl. Having said that, if you wish, I will make time to finish the SyncDebug code documentation and provide you some assistance getting a vanilla-compatible mode running. I actually owe that to someone else at the moment as well.

 

What I do know is that, if you follow this path I am suggesting, you will end up with toggle-able vanilla demo-sync-level compatibility in DoomLegacy, with a rudimentary complevel platform to add a selectable Boom and MBF complevel on top of, which should be able to handle proper demo-sync. DoomLegacy modifications can then be implemented however you see fit.

 

NOTE: I keep mentioning the importance of "demo-sync", because you can practically guarantee that, if demos play in sync, you have corrected any issues with P_CheckSector, P_ChangeSector, or most all Doom functions. Demo-sync is just too fragile to allow bugs to be concealed.

 

You know, I had similar issues with KBDoom a few years back. I had hacked up a bunch of functions, adding features, without a care for demo sync. After a while, Doom started feeling less and less Doomy. Eventually, I had lots of cool features I didn't want to lose, but I couldn't stand the feel of the gameplay. I had to build SyncDebug to allow me put the Doom back into KBDoom, without losing all my custom stuff. Since then, SyncDebug works much better, and KBDoom enjoys pretty tight demo-sync, and a handful of neat mod features to boot.

 

If you'd like to go down this path, harass me via PM - pressure me to get those docs finished, and I'll be happy to assist.

 

By the way, Doom always had some corpse sliding, but MBF can greatly exaggerate this, even causing corpses to "oscillate" endlessly in places. Look for "torque" in the MBF dev. notes. Again, study PrBoom+ and see how the "torque" option toggle turns this code on and off.

 

[VGA]

On 3/6/2018 at 10:05 PM, fabian said:

 

I don't even have an idea what tree you are actually talking about?

The haunted tree of E3M1!

[wesleyjohnson]

Ultimate doom E3M1.  When you push the eye, and the lift starts to raise, turn about 1/4 to the left.  There is one big tree there.  The other big tree is way over by the door, there are only 2 of them.

This tree will wander about in the rendering.   The rendering wanders because because the tree is actually 1/3 into the ground.

I will assume nobody has seen this before, so it must not be a well-known-quirk or anything like that.

 

I spent most of last night, putting traces in the code and trying to catch where this tree gets driven into the ground.  I have decided that it is not in P_ChangeSector, although that routine has the code that could do it, the check for onground is adequate.  Strange that using P_CheckSector instead will stop the effect from happening, like there is a variable being set, and I cannot find it.

 

What I did find was that P_ZMovement is where the tree actually gets driven into the ground.  It has some of the same height checks and an assign.  It is getting called by the thinker code.  Why this tree is getting entered into the thinker list, I do not know yet.  I would not have thought that a tree could be a thinker.

 

KB1: That plan is doomed already.  DoomLegacy is so close to PrBoom code already that it is disturbing.  That would be a multi-year effort that would lead right back to this same situation, because I doubt that I could carry such a thing out without making much of the same decisions that have already been made, and the same code changes.  The same bug would reappear.  Also, I want nothing to do with complevels.

 

A bug like this is almost inevitable, if you work on a project long enough.  Your little bugs will, given time, get together and gang up on you.  I am sure that is the case with this one, it is several interacting minor differences, that have combined into a gotcha.

 

I am starting to wonder if turning off Boom-compatibility for playing Ultimate Doom is such a good idea.   Does any other port turn off Boom-support to play Ultimate Doom.

That is really what this question is about.  Does Boom-support interfere in any way with Ultimate Doom play.  If it does not, then it is just alot of work, and probably bugs, to try turning it off for older Doom wads.  The same for MBF.  Most of its features already has individual enables, it is just a matter of the little things that are enabled by this MBF-support flag (which is called EN_MBF in DoomLegacy).

In PrBoom, I see the MBF-support flag, but it only ever seems to be controlled by the read demo logic.  That is one reason I do not like the complevels.  Trying to answer a question like this br reading the PrBoom code gets difficult once it gets near the complevel code.  It is not easily comprehended, and I don't play that port enough to have any compentence in what can be done with complevel settings.  I don't use them.

 

Got to go, have been summoned.

 

 

 

 

[Linguica]

46 minutes ago, wesleyjohnson said:

 

Ultimate doom E3M1.  When you push the eye, and the lift starts to raise, turn about 1/4 to the left.  There is one big tree there.  The other big tree is way over by the door, there are only 2 of them.

This tree will wander about in the rendering.   The rendering wanders because because the tree is actually 1/3 into the ground.

 

 

I tried this in Chocolate Doom just now and I have no idea what you are talking about.

[chungy]

There is no other port, and not vanilla either, that would do that. It must be a bug introduced in Legacy.

[kb1]

2 hours ago, wesleyjohnson said:

...wandering tree...

 

Legacy has 3d floor support, and therefore new over/under logic, right? This quickly gets complicated in reference to lifts. Imagine a barrel stacked on top of another, on a lift. The top barrel gets lifted by the bottom barrel, which gets lifted by the lift. That type of code has been tricky in each and every port that has tried to implement it. Boom/MBF does not attempt to add over/under code, so there could be a discrepancy there.

 

However, my first suspect would be the MBF thinker list changes. Maybe try to revert that back, and see if the tree settles down.

 

 

2 hours ago, wesleyjohnson said:

...plan is doomed, multi-year effort, no complevels, and the bugs will still be there...

No, no, ok, and no :)

I mentioned complevels because you suggested adding a way to toggle Boom and MBF support on and off. I don't think you should have to. To answer your question, Boom and MBF support *rarely* interferes with Ultimate Doom play. Exceptions include that torque code which is supposed to prevent monster corpses from "hanging on to ledges by their tippy-toes", and a few "smarter monster" options, like "monsters avoid walking off of lifts", and "monsters remember their targets when reloading savegames".

 

Ok, you mention that you've got a lot of PrBoom code. That's a good thing: PrBoom code is pretty solid. Let me agree with you that, yes, the PrBoom complevel code is entangled. And, yes, you can safely avoid implementing it, if you carefully choose the proper branch in each case.

 

But, let me make my point: It will not take you multiple years. It should not take a week. SyncDebug is a set of C modules with headers that are completely self-contained, requiring no outside references into your engine. You do have to make calls into it at various places in your engine. These all take the form:

#ifdef SYNC_DEBUG
  syncdbg_function(x, y, z);
#endif

Once this is done, you run your engine and let it play DEMO1. A file will be written. You compare that file against a known good file, and it points you directly to the first inconsistency. Most often, it identifies which function is inconsistent, and often what is inconsistent within that function. You find and fix the bug. Rinse and repeat. Put it this way: Maes and I, via email of all things, got vanilla demo sync working in his friggin' Java port! Imagine that for a minute: Perfect demo playback using a pure Java engine! I have to credit Maes for ultimate Java mastery. We used a much more primitive version of SyncDebug. I've since refined it big-time.

 

Here's the kicker: If you achieve vanilla demo-sync, you're virtually guaranteed to have eliminated 99.9% of any gameplay bugs. SyncDebug *will* figure out the wandering tree issue, I am sure of it. It'll find it quickly. When it identifies a bug, replacing the function with a PrBoom version is a safe bet, as long as you get everything the PrBoom function requires. Typically, PrBoom code is typically pretty clean and self-contained, other than the complevel stuff, but that should not be too much of an obstacle.

 

I estimate 40 hours absolute tops, from where you are now, to having a vanilla demo-syncing engine with Boom+MBF extensions, and no goofy trees.

 

Why achieve vanilla demo-sync?

1. You're currently in an unknown state, with difficult to find bugs.
2. Achieving demo-sync puts you into a known working state, by forcing those bugs to surface and get fixed.
3. Seeing working demos, when your port starts is undeniably awesome :)

Note: You'll have to play enough demos that your engine encounters each type of monster, door, lift, weapon, etc., before you can proclaim success.

 

Once demo-sync works, you can re-implement Legacy extensions that you may have had to temporarily comment out.

 

No, you do not need complevels here. For example, my port KBDoom is basically a vanilla-demo-sync port with Boom and MBF extensions, and enough Legacy code to get 3d floors working. Instead of complevels, I simply have an "olddemo" variable. Because of this, I do not currently support Boom or MBF demos, just vanilla, and KBDoom demos. I DO NOT explicitly turn off Boom or MBF when playing a vanilla demo, but I do internally set olddemo = true, which does cause my engine to take vanilla pathways vs. Boom/MBF code.

 

So, once again I offer my services in helping you get demo sync working via SyncDebug, which I guarantee will greatly accelerate your efforts in finding and fixing wandering trees and the like. All I ask is that you be committed to seeing it through - I have very limited time, so I need it to be spent wisely, you know?

 

Why find and fix one bug, when I've got a tool that can find all of them? (a lot of them, anyway). If you say Yes, I'll be motivated to (forced to) finish the SyncDebug documentation, which is long overdue.

 

You've been fighting with this for a long time. Let me see if I can help.

 

 

[wesleyjohnson]

Found it, and have contrived a fix, though I am still wondering if the fix will break anything else.

 

It was caused by an DoomLegacy specific mobj flag, MF_ONGROUND.  It was being cleared unconditionally in the HeightClip function, to support an older DoomLegacy feature, where monsters and players could stand on top of another monster.  This meant that they were standing on something but it is not the floor.

The older SectorChange function got the tree in its bounding box and cleared the flag.  The Boom version excludes the tree, and does not clear that flag in the tree.  That is why the tree is affected as soon as the Boom support is turned off.  Having that flag cleared left the tree not-on-the-floor, and triggered some code in ZMovement that updated that status, which included updating the z position (driving the tree into the ground).  In PrBoom code that ZMovement code is using a direct test against the mobj z position, but in DoomLegacy it tests the MF_ONGROUND flag instead.

 

The fix is to not clear the MF_ONGROUND flag except when the mobj z position is off the floor.   Then, even with the older SectorChange function that processes the tree in its bounding box, it at least does not clear the MF_ONGROUND flag, stopping the effects right there.

 

No, I cannot see any way that a demo sync test would have caught this.  It had nothing to do with demos.  The only "demo" connection was that this old SectorChange function was only enabled in PrBoom for old demos, and DoomLegacy had copied that behavior already.  The MF_ONGROUND flag and the feature that it supported do not even exist in any other port.

 

KB1: It took 3 months alone to integrate MBF code with existing DoomLegacy.  Every single function has to be examined with respect the DoomLegacy influences.  I really do not like the way PrBoom code is written, and have rewritten every function borrowed from PrBoom so they are DoomLegacy functions.

There is much more to DoomLegacy than just supporting some special linedefs, and 3d floors.  You would be proposing to rip out everything that makes DoomLegacy a unique port.   Who needs another PrBoom variation, even if it did support DoomLegacy linedefs.  I play DoomLegacy now because it has the features (like free-look, jumping, 3d floors, save game directories with 99 savegames) that I want.  PrBoom does not have those features and I have great difficulty playing it.

 

For almost every complevel control, DoomLegacy has a corresponding control.  I ran across the one for the MBF torque (sliding corpses).  I just have to find out which option page it is on, so I can turn it off when playing Ultimate Doom.   That is really the problem, play Ultimate Doom one day and mess up your options for the other wads you play later.

 

 

 

 

[kb1]

On 3/10/2018 at 6:20 PM, wesleyjohnson said:

No, I cannot see any way that a demo sync test would have caught this.  It had nothing to do with demos.  The only "demo" connection was that this old SectorChange function was only enabled in PrBoom for old demos, and DoomLegacy had copied that behavior already.  The MF_ONGROUND flag and the feature that it supported do not even exist in any other port.

 

KB1: It took 3 months alone to integrate MBF code with existing DoomLegacy.  Every single function has to be examined with respect the DoomLegacy influences.  I really do not like the way PrBoom code is written, and have rewritten every function borrowed from PrBoom so they are DoomLegacy functions.

There is much more to DoomLegacy than just supporting some special linedefs, and 3d floors.  You would be proposing to rip out everything that makes DoomLegacy a unique port.   Who needs another PrBoom variation, even if it did support DoomLegacy linedefs.  I play DoomLegacy now because it has the features (like free-look, jumping, 3d floors, save game directories with 99 savegames) that I want.  PrBoom does not have those features and I have great difficulty playing it.

 

For almost every complevel control, DoomLegacy has a corresponding control.  I ran across the one for the MBF torque (sliding corpses).  I just have to find out which option page it is on, so I can turn it off when playing Ultimate Doom.   That is really the problem, play Ultimate Doom one day and mess up your options for the other wads you play later.

I don't have the time tonight to fully explain why SyncDebug would have absolutely caught the descrepancy - that's what it does. It's not demo-centric (although it will tell you how to fix demo-sync, if desired). I absolutely am not proposing that you "rip out DoomLegacy". All of DoomLegacy's special features would stay. If we did what I was proposing, this is what would be different:

• Every DoomLegacy-specific change would be identified, and made switchable by a single global boolean "legacy_features_enabled" or whatever. This also makes it very easy to add documentation for each change from vanilla, because they are found and identified.
• When legacy_features_enabled = True, your port runs with all gameplay Legacy features that you currently enjoy.
• When legacy_features_enabled = False, your port would exactly emulate vanilla gameplay, allowing it to play old demos.
• Boom and MBF (PrBoom) code already can emulate vanilla, if implemented carefully.
• SyncDebug will continue to function, if enabled, and can be used to catch any gameplay changes in the future, for regression testing.

Installing SyncDebug involves dropping a half-dozen new files into your project, and adding a couple dozen #ifdef function calls into SyncDebug at various places in the code. Based on how far your code deviates from vanilla and PrBoom, it should take no more than a few hours.

 

Once installed and enabled, you run a demo, and it finds the first descrepancy. If that's caused by Legacy code, you place an "if legacy_features_enabled, do Legacy code, else do vanilla code" statement. Then, you run it again, and it finds the next descrepancy.

 

At the end, you have a port that can play vanilla demos, and you have a flag that can totally control all Legacy features. But, playing demos is not the point. The real value is that you have a known-good-starting-point. You have a port that can be compared to other ports. From that point on, each Legacy feature is clearly identified, and its effects are controllable. You gain the benefit of all the bug fixes that have been found over the years, and you have a code base that can easily accept code fragments from other ports (because it has been made compatible).

 

I believe that you're at a point now, where so many things have been adjusted, tweaked, and modified, that you're having difficulty with lots of tiny differences. I believe that's why implementing MBF was so difficult - because it no longer fits within all the Legacy enhancements.

 

What I am offering is a top-to-bottom identification of each of those differences, and a full comparison of Legacy gameplay to original gameplay, which will allow you to verify your Boom and MBF implementation, your differences to vanilla, and the ability to control access to each. I offer a differential comparison, not on the code level, but on the gameplay level.

 

SyncDebug install will take a few hours. Identifying descrepancies and adding "legacy_features_enabled" toggle will take 2-30 minutes per descrepancy, depending on how detailed you want to be (do you want to add comments, explaining the Legacy behavior, do you want to add the vanilla code for old demos, do you want to fill out a coding log, etc.)

 

I've already spent too much time explaining my proposal - I have to get back to work. What I can say is that, you've got nothing to lose, except a few hours of your time. If you backup your source, you can always go back. And, if after a few tries, it doesn't look like it's working, we can always call it a day.

 

Believe me, I don't really have a lot of time. I would not be offering my services if I thought that what I was proposing would be a long drawn out process. And I wouldn't offer if I had any doubt that it wouldn't work. I am astonished at just how well it does work. I guarantee you'll be pleased at the results.

 

I know you know your code. But, I also know from experience that understanding the full effect of simple changes that I've made are difficult to fully understand.

This effect is multiplied when you've got a lot of these changes. I can help clear that up. I am excited about SyncDebug - that's why I'm motivated to put it to the test.

 

It's up to you. Either way, good luck!

 

[kb1]

@wesleyjohnson Did you read your PMs? Have you given this any more thought?

 

EDIT: We have since discussed this in detail. I'll be releasing the SyncDebug system soon, for anyone that's interested.

Edited March 16, 2018 by kb1

[wesleyjohnson]

I have the SyncDebug zip offered by KB1.  As this is a busy time, it may be a while before I do too much with it.

 

KB1:  The DoomLegacy source tree is in the SVN at SourceForge, located at   https://sourceforge.net/p/doomlegacy/svn/HEAD/tree/legacy_one/

 

I am only visiting this site about once a week right now, so it may take a while for me to notice personal messages.

 

KB1 says no to the idea of multiple config files, and no to turning off boom_enable.   Thanks for the replies.  I note that there was a total lack of any enthusiasm for the idea that I was working on.   I will scrap that idea and work on something simpler.    First, I will probably disable this MF_ONGROUND flag a little more firmly.

 

[kb1]

On 3/17/2018 at 11:02 PM, wesleyjohnson said:

KB1 says no to the idea of multiple config files, and no to turning off boom_enable.   Thanks for the replies.  I note that there was a total lack of any enthusiasm for the idea that I was working on.   I will scrap that idea and work on something simpler.    First, I will probably disable this MF_ONGROUND flag a little more firmly.

 

From a player's viewpoint, I think the multiple configs and enables would be a bit confusing, and I haven't seen other ports need that level of separation.

 

I am hoping that the SyncDebug stuff will help get you towards a known-good state. From that point on, the re-introduction of things like the MF_ONGROUND flag and others will feel like a more controlled process, and will promote your ability to isolate specific new features, and see their individual effect more easily.

 

Please keep me informed when you can.

[wesleyjohnson]

Have a test version with SyncDebug installed.  Have found a couple of bugs.  It is surprising close to the reference printout.  Have gotten to where it will be more difficult to make it match the reference.  For instance the bobbing code is very different in DoomLegacy.

 

Have installed cable modems and routers, here.  So my connection speed is supposedly better, but not as great as advertised.  Have discovered the need to upgrade some Linux platforms, and that will absorb a few days work, as the hardware is old and the usual assumptions do not work.

 

Have noticed that anytime I use the DoomLegacy test version with the code to disable Boom support, that it is creating render errors on multiple wads.  How, I don't know.   Unless that can be resolved, there is no chance the code to disable Boom support will be committed to the SVN.

 

[kb1]

I'm curious: What kind of rendering errors?

[wesleyjohnson]

Been working on DoomLegacy, trying to get it ready for the 1.47 release.  That is I am trying to find any important bugs introduced by adding the MBF capabilities.

To that end, I have a version of DoomLegacy with the SyncDebug (TM) debugging system (from KB1) installed.  He has been helping me with SyncDebug output.

I have made some changes to SyncDebug, which KB1 has incorporated into his product.

 

We have found some things that influence the demo sync.  The fixes have not been big nor even memorable.  I cannot remember what they are even now.

At least DoomLegacy does now seem to complete some demos in UltDoom and Doom2, though not perfectly.  I was not aiming for perfect demo sync, although KB1 is much more enthusiastic about reaching that goal.  I am, at this time, just trying to find bugs important to the 1.47 release.

 

There is a nagging position error in the LSB that gradually makes the player position vary from KB1's reference position.

I have been unable to find that.

I have taken the P_TryMove, P_CheckPosition, PIT_CheckThing, PIT_CheckLine functions from prboom, and wedged them into a copy of DoomLegacy.

I am running them in parallel with the DoomLegacy functions, and comparing the results and some internal variables, looking for significant differences.

Of course, it puts out page after page of error reports, which turn out to be problems with two functions working on the same data set and interfering with each other.

I think I finally got them tamed so they don't stomp on each other's data (I make separate copies of everything for the PrBoom functions, and only keep output from the DoomLegacy functions).

The end result of all this is that it can run through entire demos without reporting any difference between the DoomLegacy and PrBoom functions.

 

I did notice some MBF specific code was missing from a DoomLegacy function, so I have to include that now.

I will get 1.47 released, really soon now (some time this year, I hope).

 

 

 

 

 

[kb1]

Good job, wesleyjohnson! Yes, we've been working on some demo sync stuff. To me, having vanilla demo sync provides the best "mathematical proof", so to speak, of classic Doom gameplay and feel. It provides a way to trace a port's enhancements back to vanilla implementation.

 

DoomLegacy is tracking very closely to vanilla these days. Thanks for letting me work with you, and for your enhancements to SyncDebug. For the position error stuff, I'm wondering about compiler settings and math roundoff error. I'll know more once I analyze your latest output, this weekend.

 

By the way, this is the 3rd port to get use out of SyncDebug, so I am pretty comfortable with releasing it soon - I just need to finish up the documentation.

[wesleyjohnson]

The rendering errors when disabling Boom support were weird.  Not the kind of thing I could describe in detail.  Also too long ago now to remember accurately.

I think I fixed one of the causes, but then saw more.

 

[kb1]

5 hours ago, wesleyjohnson said:

The rendering errors when disabling Boom support were weird.  Not the kind of thing I could describe in detail.  Also too long ago now to remember accurately.

I think I fixed one of the causes, but then saw more.

 

Do the errors occur on non-Boom maps? I could see something like 242 deep water maps rendering strangely with Boom disabled, but that's one of the few things. As you know, Boom didn't make a lot of direct rendering changes, but, indirectly, you've got deep water and custom colormaps, sky above and below, slime-trail fix, visplane hashing/splitting/joining, Medusa fix/texture rebuild, and the large blockmap support/rebuild stuff, which shouldn't affect rendering I don't think. Legacy's 3D floors are way more invasive, render-wise than Boom. Probably a tiny oversight. Process of elimination, using a repeatable test case should help locate it.