Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

wesleyjohnson

Members
  • Content count

    1288
  • Joined

  • Last visited

5 Followers

About wesleyjohnson

  • Rank
    Senior Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. wesleyjohnson

    Doom Source Ports family tree (simplified, for Wikipedia)

    I would categorize that as code borrowing, not feature implementation. Implementing Boom generalized linedefs would be feature inherited from Boom. The code we borrowed actually came from PrBoom, but if you are only going to show feature inheritance, then that indirect source would not have to be shown. I think that the feature inheritance is probably more important to an end user than code borrowing. I expect only source port developers would be interested in a tree that showed all the code borrowing too.
  2. wesleyjohnson

    Doom Source Ports family tree (simplified, for Wikipedia)

    That just about what I expected. But it shows the truth, that the relationships between ports is not simple, nor elegant, nor pretty. I assume that is showing features inherited (not code borrowed, or else there would be alot more lines), so I have to question what features Chocolate Doom could have contributed to Eternity Engine. But, in general .. yes that is more like what I remember
  3. wesleyjohnson

    Doom Source Ports family tree (simplified, for Wikipedia)

    One major problem with this chart is that it condenses a port to a single instance. Unlike people, these ports do not inherit property, titles, or genes. The code from a particular ancestor can have changed beyond recognition. They really have a time axis, and should be displayed as bars, and having a lifetime. The 3d floors of DoomLegacy were inherited by some other ports. Is that not also an important inheritance. This tree does not show DoomLegacy contributing anything to the other ports. Software does not have just one or two parents. It seems to me that a simple geneology tree here is more irrelevant than it is right.
  4. wesleyjohnson

    Doom Source Ports family tree (simplified, for Wikipedia)

    Inadequate to the point it is misleading of the port anymore. Perhaps something other than lineage would be more useful. Lineage usually would indicate an ancestor that it resembled by default, except for notable enhancements. That is clearly not the case for many of these source ports. Maybe, some should stand alone, as no longer resembling any ancestor. Or, instead, the amount of commonality between ports could be indicated by a line and the amount of uniqueness could be indicated by filling in the circle with some color.
  5. wesleyjohnson

    Doom Source Ports family tree (simplified, for Wikipedia)

    Doom Legacy What does derived mean after 20 years of borrowing from other ports. I had to lookup in the logs to even find out that DOSDoom was an ancestor. The early logs indicate that the developers spent considerable time restoring functionality of the original doom. I cannot identify any actual feature that was inherited from DOSDoom. Maybe the options pages. Everything interesting came afterwards. The option variables, the console (from quake), freelook, ... DOSDoom has 4 mentions in the source code. PrBoom has approx. 200 mentions in the source code (and the code is close to identical on many places). Boom has approx. 750 mentions in the source code (and some actual code borrowed). I think with 1.47 we may be more derived from MBF than from DOSDoom. That lineage chart only represents what DoomLegacy was in 1998. To represent the current version you have to account for the changes due to 20 years of development, and especially the cross sharing of wad capability. We share Boom wad capability, inherited from Boom. With 1.47 there will be MBF wad capability, inherited from MBF, PrBoom, and Eternity Engine. Those dotted lines seem mightily important to me.
  6. wesleyjohnson

    DoomLegacy 1.46.2

    Had planned to release 1.47 for months now, but was fighting with some last minute questionable features. It contains MBF support, and some bug fixes. Not all the bug fixes I wanted because the MBF code introduced so many new bugs, which I had to fight with. The MBF integration has turned into a 9 month debugging session. Also want to get the network code compatibility secured, as there will be some differences from 1.46 networking. I think I still have to add a new network message in order to satisfy one of the bug reports. It seems that a fragglescript attached to a key press, does not get sent to the other players. Instant desync. The SVN contains the current version 1.47 (as the version number has already been bumped).
  7. wesleyjohnson

    Ultimate Doom tree driven into ground

    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.
  8. wesleyjohnson

    Ultimate Doom tree driven into ground

    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.
  9. wesleyjohnson

    Ultimate Doom tree driven into ground

    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.
  10. wesleyjohnson

    Ultimate Doom tree driven into ground

    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.
  11. wesleyjohnson

    Ultimate Doom tree driven into ground

    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.
  12. wesleyjohnson

    Ultimate Doom tree driven into ground

    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..
  13. wesleyjohnson

    Ultimate Doom tree driven into ground

    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.
  14. wesleyjohnson

    Any help on fixing this bug in ReMooD?

    Cosmetic stuff ... Not very good reasons for such a bad opinion. DoomLegacy only stretches the title pics to fit, not the play screens. Midi missing one instrument on Windows is due to the bad default midi player instruments shipped with Windows. Been over that before. No problems with midi on Linux. DoomLegacy is being supported on Linux, and some other operating systems. I am developing on Linux 4.4.38. DoomLegacy 1.47 is being readied for release, probably in the next month. Will play Heretic and MBF wads too. Exactly what OS. Crashing on Linux could be due to running an old binary with newer incompatible libraries. Get source and compile it yourself. Then it will match your libraries.
  15. Jumping discussion: If a mapper specifies a jump height then it does not matter at all what all the ports have as their defaults. It does not matter if it matches any of them. If the mapper does not specify a jump height then the port can use its default. Jump height should be an integer, related somehow to a height range. This then can be used to index a table of fixed point impuses to apply as momentum. Using a table this way makes it easy to tune the jump heights. Then just share that table with all the port authors. The mapper does not care about momentum impluses. They have a ledge at 14 units and want to specify that the jump can get the player up there. If the specified number is the actual jump height needed, then that saves the mapper from having to translate their needed jump height to some arbitrary index. What I would do in DoomLegacy is to have additional tables for difficulty. So at EASY, I give them a little more jump height.
×