Doom+ version discussion [from Plutonia 2 bugs thread]

[Split off from here.]

entryway said:
You cannot play p2 comfortably with vanilla or chocolate because of HOMs on every each map and savegame limit.

People have PrBoom/+ (or many other limit removing engines) as an alternative for this if they find disappearing sprites or HOMs to be unacceptable.

Demos recorded with doom2+ should play with doom2 or should crash doom2.

Which is the problem. The demo version marker is supposed to guarantee that a demo will work with the engine the marker stands for as long as the correct levels are loaded. Doom version 1.9 is the latest version of the plain engine, limits included. If, unlike when they were recorded, demos get terminated before they are completed, they aren't for that version. If something else can play them, they should be marked for it and not for what they fail in.

This also means compatibility level 2-4 should only be used with levels that also run in Doom. For limit removing it's much more reasonable to use something like compatibility level 7 if one wants plain behavior, or even the default behavior with the appropriate compatibility settings enabled, especially for levels that exceed Boom's limits.

Once you change the version number the backward incompatibility issue goes away, and the fact that intercepts overflows occur differently becomes innocuous. And, of course, Doom+ finally becomes truly usable without the intercepts handicap.

esselfortium said:
I've also heard a few reports of VPOs in Pl2, including at least one as a result of an archvile blast.

You're saying that in a thread where the very purpose is discovering bugs for a future rerelease. You also haven't seen the many VPO situations removed during development.

myk said:

Which is the problem. The demo version marker is supposed to guarantee that a demo will work with the engine the marker stands for as long as the correct levels are loaded. Doom version 1.9 is the latest version of the plain engine, limits included. If, unlike when they were recorded, demos get terminated before they are completed, they aren't for that version. If something else can play them, they should be marked for it and not for what they fail in.

You want to have additional unnecessary demo versions on empty place. And probably you want to force all authors of all compatible ports to support 1.12 version of doom2+ (and 1.13 of udoom+, and 1.14 of prboom compatible mode, etc). Of course nobody will care about it and all these demos will be exclusively for doom2+ which I do not use and hence not be able to watch them at all (currently I can easily with doom2, prboom/+, eternity, chocolate, etc). Also I know you want that prboom could not record doom2 compatible demos by the same reasons. You only want playback abilities from prboom, and ability to record compatible demos, but with difference demo version ('o' instead of 'm' for example) and it is just another unnecessary work (for converting) when somebody wants to show some VPO on Plutonia2 for example, but can't record compatible demo. Also it is compulsion of people to use corresponding port instead of favorite port without any real reasons. Probably it's one of reasons of low popularity of EE. Just because it can't record compatible demos (without hacked version)

entryway said:
You just want to have additional unnecessary demo versions on empty place. And probably you want to force all authors of all compatible ports to support 1.12 version of doom2+ (and 1.13 of prboom compatible mode, etc).

It wouldn't "force" things any more than your conceptions do. Mine would break them less, however.

Version 1.13 wouldn't be necessary (it makes more sense to reserve it for Doom+ longtics). Boom's Doom compatibility mode seems good enough for most purposes. I generally use it nowadays for most limit removing play, since I noticed Doom+ was messed up.

A full limits removing mode definitely wouldn't hurt, since one wouldn't want to leave the engine without that capability. But since it's 100% impossible to play such demos with the DOS binaries, at that level fidelity becomes less relevant. The engine is already capable of that, anyway, except the specific compatibility settings are a pain in the ass to use with consistent demo recording. All it needs is an easier way to enable it.

Of course nobody will care about it and all these demos will be exclusively for doom2+ which I do not use and hence not be able to watch these demos at all.

Heh, "no one will care because entryway doesn't." In reality, you don't want to clean up the mess that the numbered compatibility system is, which gets in the way of adding anything like v1.12 support. People can still do it, though, based on Chocolate Doom (or PrBoom/+). Small modifications to Strawberry Doom would do it, in fact.

Also I know you want that prboom could not record doom2 compatible demos by the same reasons.

Not really, but it would make perfect sense to have it use Doom's limits while doing so. It would help people record Doom compatible demos, as opposed to not being sure whether they really do run in Doom.

Also it is compulsion of people to use corresponding port instead of favorite port without any real reasons. Probably it's one of reasons of low popularity of EE. Just because it can't record compatible demos (without hacked version)

Yeah, I bet that's why no one uses ZDoom and its offshoots, eh? The Eternity Engine is geared toward making mods, not recording demos. It has not taken flight yet because WADs for it are scarce. I heard various projects are in development. It they are released and are liked, the engine will gain popularity. It's to ZDoom what FireFox is to IE, more or less, so it has a good chance to grow.

myk said:

Which is the problem. The demo version marker is supposed to guarantee that a demo will work with the engine the marker stands for as long as the correct levels are loaded. Doom version 1.9 is the latest version of the plain engine, limits included. If, unlike when they were recorded, demos get terminated before they are completed, they aren't for that version. If something else can play them, they should be marked for it and not for what they fail in.

Any demo being recorded specifically with the idea that it can playback in vanilla doom2 will A: Be recording on a WAD that is proven to be vanilla compatible, and B: will either use vanilla itself, -complevel 2, or even doom2+. If it crashes in vanilla, well, there you go: You aren't playing a vanilla compatible wad.

If somebody wanted to record a demo for a wad that uses only vanilla features, but is limit removing (due to high visplane or whatever), what's wrong with them using an engine that (as far as gameplay behavior is concerned) is completely identical to vanilla? Doom2+ is basically vanilla without all the annoying limitations. I don't particularly look at VPO, sprite limits, or HOMs as 'classic' or something.

Also, why would you try and playback a demo on vanilla for a wad that isn't compatible with it?

Personally, I don't look at Plutonia 2 as a vanilla compatible wad at all. I warped through all the maps, attempting to save. A good portion of them froze because of the save game limitation. The only reason I won't be playing through Plutonia 2 on the vanilla engine that the team painstakingly designed this wad around is because I refuse to go through several maps back to back without being able to save my damn game. Doom2+ solves this problem, while being pretty much identical to vanilla in every other way. This is why I would like to see a FDoom+.

I like the feel of the original engine; not the limitations (again, I refer to VPO, save games, and HOMs. So don't even try and start with some witty remark like "Why don't you go play ZDoom if you hate limitations")

I would be so happy if chocolate-doom had options to remove the VPO limit much like the savegame limit.

Mike.Reiner said:
Also, why would you try and playback a demo on vanilla for a wad that isn't compatible with it?

It is not always clear whether something recorded on a limit removing engine will play back in Doom. Even when a WAD is vanilla compatible, a very rare VPO can pop up, PrBoom's intercepts overflow emulation can fail, and so on. Additionally, and perhaps more importantly, the guy recording isn't always sure if what he's recording is Doom compatible, so he may be unable to inform others the level or the particular demo is incompatible.

The only guarantee is to apply the limits while recording, which one would want to do only within a WAD that's tested for vanilla when one is concerned about it playing back in vanilla. Using the version marker properly merely adds a safeguard. The limit-removing version (such as v1.12 or PrBoom locked on vanilla settings) would still behave pretty much like Doom (with tiny differences, such as due to the increased intercepts limit).

You aren't losing the capability to play big levels vanilla style or anything, just strengthening inter-compatibilty. As things stand PrBoom/+ and Doom+ are backward compatible with Doom, but are also liable to generate Doom-incompatible demos not marked as such. The proposed fix is about changing a marker that Doom uses, mostly, not about making PrBoom/+ incapable of running in plain behavior without limits.

I would be so happy if chocolate-doom had options to remove the VPO limit much like the savegame limit.

That would be cool, but if done properly; addressing the intercepts problem I mentioned above and correspondingly upping the version number while recording that way.

myk said:

...

Ok. I will fight with you. Even if I know my English is unintelligible sometimes. So, my latest attempt to give you The Truth.

Firstly you should understand: it is impossible to create win32 fully compatible port at all. Doom has too many unsafe places which can't be reproduced or emulated. I mean uninitialized fields like crash field for stairs and any kinds of overflows.

The first example. I can easily create a level with intercepts overflow (the latest levels by Eternal Nightomb has this overflow permanently in one place) and there is very high probability of incompatibility if demo will be recorded with not Doom2, but, for example, with Chocolate. So why Chocolate-Doom tries to create compatible demos if it can't in principle?

The second example: I can do the same things with uninitialized fields. It's impossible to emulate this issue in port just with uninitializing too like Chocolate does, because memory is different in different applications, especially if the first is for DOS and the second is for Windows, plus Doom does not fill all the memory with a zero during initialization. Hence you can't be in the firm belief about compatibility with Doom if you are recording a demo with Chocolate on levels with raising stairs (actions 7, 127) and with probability of some things (monsters or player) to be squished there. So Chocolate must mark all demos on such levels as incompatible. Why Chocolate does not do it?

There are other examples with overflows and uninitialized fields. For example on intermission screen after map33. Doom2 tries to read and to use memory from very low addresses there. You absolutely have no ability to know what can happen in this case. Workaround by fraggle for this issue is just workaround.

The third example: Just start Doom95 and record an 'incompatible' demo with compatible header, because doom95 has raised limits.

So the only thing you want is a compulsion of users to new, absolutely unnecessary problems with newest versions of prboom+/doom+ (with 1.12 demo version) and demos which will be produced by these versions with all after-effects. Just for that. Because there are too many methods to record 'incompatible' demos: old versions of prboom/prboom-plus, hacked versions of Eternity, doom95, doom2+, udoom+ and even Chocolate-Doom.

The only way when your arguments make sense is returning to the past and rewrite doom license with prohibition to create ports with ability to create compatible demos, but you know it's impossible.

In your terms there is only one ability to create a 'port' with rights to create compatible demos: just do not apply VPO fix from doom2p.crk. Be sure, if you will pay me $10 for each incompatible demo produced by Chocolate you will go bankrupt till Plutonia 1.1 release. So I cannot understand why you like Chocolate and dislike doom2+ with such senseless strange reasons.

Mike.Reiner said:

Personally, I don't look at Plutonia 2 as a vanilla compatible wad at all.

You are absolutely correct. Plutonia2 is not for vanilla. It's just for limit removing ports, because you can't play through all the levels without saving and there are too many drawsegs overflows. But it is friendly to demos, because you can use vanilla for any compatible demos. At least authors of Plutonia2 want it with all one's might

entryway said:
So, my latest attempt to give you The Truth.

Be afraid, I have a Bible right here on my bookshelf ;)

So I cannot understand why you like Chocolate and dislike doom2+ with such senseless strange reasons.

Small glitches caused by portability are one thing, the misuse of a marker with a definite purpose is another. You can purposely make a WAD that works in one but not the other, but that's hardly representative of how WADs generally work. It's an artificial attempt to show some relatively extreme possibility. With testing and bugfixing ports can be improved to reduce differences. It's different from allowing someone to record a 20 minute demo with Doom+ using the v1.9 version mark, to have it terminate after 10 minutes on the computer of someone using Doom or Chocolate. Wasting their time when the v1.12 marker would have alarmed them immediately that another engine is required, which is exactly what the demo version is for.

Doom95 is of lesser relevance, and how easy to get VPOs on it also varies with the resolution used (they increased the limit specifically to address higher resolutions, not to adapt it to bigger maps). Used in most vanilla levels there is little difference. In fact, using PrBoom+ as it is now on vanilla WADs is generally fine. Occasional VPO situations and stuff can occur, but generally they do not. The real issue, even sometimes in regard to Doom+, is when limit removing WADs are used. How is that addressed? Apply the limits to vanilla compatibility and apply another version marker to behavior that's essentially the same without limits (or higher limits). The presence or absence of limits is a behavioral change.

At least authors of Plutonia2 want it with all one's might

Why do you think they went through the hard task of fixing all the critical vanilla bugs they found? Because they wanted it to work in true vanilla, not just limit removing. The levels would be larger and more complex had limit removing really been adopted. It's what I'd call "soft vanilla compatibility". It may be a bit glitchy visually, but it works. "Hard vanilla compatibility" would be a flawless behavior in vanilla. Both Gusta and Vince have historically shown a preference for soft compatibility to max out vanilla possibilities; AV25 shows some disappearing monsters, KS has some maps with HOMs due to many drawsegs. Soft compatibility is possible because using vanilla to record or watch demos is not mandatory, but players who are not really concerned about the glitches can do so when they desire.

myk said:

Apply the limits to vanilla compatibility and apply another version marker to behavior that's essentially the same without limits (or higher limits)

Too late. As I spoke, there are one billion of methods to record incompatible demos. There is absolutely no sense to change things now. Nobody (probably except you) will use such prboom+ and doom+. It's work for nothing.

There always was an ability to record 'compatible' demos with non-doom header by using boom_compatibility_compatibility (-complevel 7), but who did it? Why people prefer to use -complevel 2 instead? Think about it. The answer is simple. And why you want to take away this opportunity from my users in newest versions?

myk said:

Doom95 is of lesser relevance, and how easy to get VPOs on it also varies with the resolution used

It is not important. You can create incompatible demos with Doom95 easily and it is only thing you can operate. The same for chocolate doom. So, what are you doing here? Go to Chocolate's bug tracker and post a bug report. It should not use 'm' for doom2 demos.

entryway said:
There always was an ability to record 'compatible' demos with non-doom header by using boom_compatibility_compatibility (-complevel 7), but who did it? Why people prefer to use -complevel 2 instead?

That's simple. They were not aware of the issues, or ignored them, knowing there was some grouchy Ukranian making the changes to the engine, and some other guys who rarely show up. Now however, the issues have been aired. Things are not the same anymore. I'll always recommend using level 7 over 2-4 for plain limit removal, for example. It's people who make habits, and people and the habits change when they see things and they aim to improve them.

And why you want to take away this opportunity from my users in newest versions?

To solve issues. Actually, it takes away nothing. The engine should still be able to play back demos recorded this way (with a v1.9 tag but on a limit removing level) if this is implemented correctly. All new demos would however use correct version markers. The tiny difference could be intercepts, which would simply make all the formats more robust. Which, of course, you've been ignoring. Max intercepts 128 versus max visplanes 1024 and vissprites 1024 is garbage.

As you can see, my proposal tackles two issues, and does not really adversely affect anything.

It is not matter. You can create incompatible demos with Doom95 easily and it is only thing you can operate. The same for chocolate doom. So, what are you doing here? Go to Chocolate's bug tracker and post a bug report.

Like I said, that's an artificial essay in regard to potentially fixable bugs (at least in Chocolate, which is more important), and not something that seriously affects most levels. You're just complaining because I criticize PrBoom+ and Doom+ more than Chocolate, but ironically this is due to interest, not antagonism, and the fact that Chocolate is not really suitable on my particular oft-used Windows 98 system, by design. Doom+ is a superb idea in my opinion and have expressed so in the past, I just feel it's a loss to implement it half way. Your work has been outstanding, but there is a little critical bit to improve. But don't feel pressured here, if you have no interest in my view of this, I've been talking to a programmer friend with decompiling skills, who may be able to do the necessary change.

I might provide more bug reports for Chocolate Doom (which I do occasionally provide anyway), especially if I start using a computer with a more modern OS more often, but not now.

Your idea is about cleanliness, but the world is cruel and it cannot have an embodiment in real life, because of senseless and mess. Yeah, you have not heard me incorrectly - because of mess. You just want to create an additional unnecessary incompatibility between all versions of prboom/+ before 2.5.0.1 and after 2.5.0.1. You should know, 95% of doomers uses outdated versions. Even for recording. You cannot force them. It's because prboom+ has support even for old buggy versions of prboom with -emulate ver_num switch. So, the new system will not have wishful effect. Half-effect will lead only to the additional disorder.

myk said:

Like I said, that's an artificial essay in regard to potentially fixable bugs (at least in Chocolate, which is more important), and not something that seriously affects most levels.

You cannot be half pregnant. Port or can or can't to create compatible demos. The reality says there are no fully compatible ports, but there are billions of incompatible compatible demos. IMO it's absolutely stupid to change things today. Too late.

btw, it is absolutely easy to apply your wishes to prboom/+/chocolate. Just few symbol in sources should be changed for effect. Even you (I assume you are not a programmer) can do it with prboom or chocolate or doom2+ (I can say you an address to change from to) and you can release your own "correct" versions of ports. But what for? You even cannot persuade anybody to use cool -complevel 7

entryway said:
Your idea is about cleanliness, but the world is cruel and it cannot have an embodiment in real life, because of senseless and mess. Yeah, you have not heard me incorrectly - because of mess.

Heh, that's a bit generic, don't you think?

Let's get more specific: cruel to PrBoom perhaps, which is indeed a mess in some respects, as I've shown on previous occasions. Merely adding a compatibility option that is not the latest (2.6.0, &c) is a catastrophic event.

This plays against PrBoom. It's hard to improve it because it's a morass of stuff piled together. Legit proposals get dismissed because they become a hassle to implement and potential contributors are scared away by the coded chaos. Life can be more or less of a mess, depending on how well people and their environment are organized, as you may know.

Improve the system, and future additions will be less tasking.

You just want to create an additional unnecessary incompatibility between all versions of prboom/+ before 2.5.0.1 and after 2.5.0.1.

No, because you can make (suppose 2.6.0) backward compatible; able to play anything previous versions played. Recording changes a bit, but mainly in the way versions are accounted for.

You should know, 95% of doomers uses outdated versions. Even for recording. You cannot force them. It's because prboom+ has support even for old buggy versions of prboom with -emulate ver_num switch. So, the new system will not have wishful effect. Half-effect will lead only to the additional disorder.

It's not necessary to force anything. It's good enough if the right versions are used in essential places. Such as to create demo packs on the forums, or the like. Like I said above, keeping it the same won't work either. What of people who see the issues I point out and agree with me? They'll think, "hmm, PrBoom is a mess..."

You cannot be half pregnant.

You're wrong there, my man. You are half pregnant if you have one embryo instead of a possible two. I'm an uncle to two twins, incidentally :p

What you were arguing was rather amusing, to be honest: "Hey, don't bother fixing stuff, because imperfections exist anyway". I'm personally addressing issues I consider important, not nitpicking in sake of some cosmetic perfectionism. You may see that I'm right, eventually.

I value that you may not have time and interest for what I propose, but save yourself the out-on-a-limb arguments. I'm sure I have a point, and you're not obligated to do anything. I will, however.

In any case, this is a five-minute hack for doom2p.exe if you want

D:\games\Doom2\fc /b DOOM2P.EXE DOOM2PP.EXE
Comparing files DOOM2P.EXE and DOOM2PP.EXE
00063A4D: 6D 70
00063B17: 80 E9
00063B18: FA C3
00063B19: 6D 34
00063B1A: 74 02
00063B1B: 0D 00
00086FDF: 00 80
00086FE0: 00 FA
00086FE1: 00 6D
00086FE2: 00 74
00086FE3: 00 0A
00086FE4: 00 80
00086FE5: 00 FA
00086FE6: 00 70
00086FE7: 00 74
00086FE8: 00 05
00086FE9: 00 E9
00086FEA: 00 2E
00086FEB: 00 CB
00086FEC: 00 FD
00086FED: 00 FF
00086FEE: 00 E9
00086FEF: 00 36
00086FF0: 00 CB
00086FF1: 00 FD
00086FF2: 00 FF

It must record demos with 'p' version (0x70) and it must play both 'm' and 'p' (0x6D and 0x70)

Not tested.

Quite cool, although that doesn't cover the intercepts issue, which means being unable to handle hundreds of monsters in any area. One hundred monsters with the low limit are about the same as 800 with the higher one. You can't have big levels packed with many bad guys without serious overflow possibilities :(

Unless it were added anyway, allowing some demos to desynch; any "m" demos that have intercepts overflows, that is (optimally vanilla demos, that have a lesser chance for an overflow in the first place). A small sacrifice for the improved performance. The primary use of the hacked engine would be "p" demos, so...

myk said:

Quite cool, although that doesn't cover the intercepts issue, which means being unable to handle hundreds of monsters in any area. One hundred monsters with the low limit are about the same as 800 with the higher one. You can't have big levels packed with many bad guys without serious overflow possibilities :(

It does not depend only on monsters. Try to shoot revenant (things #317) on nightomb.wad from (1880, 1400) position in prboom+. There is 100% overflow.

Mostly it happens because of linedefs. In case of nightomb.wad you can reproduce it without monsters at all. Doom's algo is stupid a little, because it enumerates much of linedefs in MISSILERANGE range (2048 units) before sorting and checking first line for one-side.

Yeah, I use my lighting WAD that has 256 linedefs across to test. It's an automatic crashing overflow (the limit is exceeded by 100%). That's how I noticed that GhostlyDeath raised the limit in Strawberry Doom.

Though I also did get consistent terminal overflows in a monster-packed Deeforce WAD once monsters started dying, in a level that's otherwise quite fine for Doom+.

myk said:

Yeah, I use my lighting WAD that has 256 linedefs across to test. It's an automatic crashing overflow (the limit is exceeded by 100%). That's how I noticed that GhostlyDeath raised the limit in Strawberry Doom.

In case of lighting.WAD all is correct with algo, because you shoot through 256 lines and all of them should be in array. With nightomb it's less obvious, because you can shoot directly in a wall, but oops

Yeah, that must explain the overflows in WADs that are otherwise pretty simple. With linedefs you can at least measure their effect through testing, but things can move around, and if a 100 demons end up lined up and packed together in some hallway and killed, you'll easily get an overflow if you shoot across the area, especially once they add up with any two-sided lines or whatever.

-