First PrBoom demo version?

[Quasar]

I need to know what version PrBoom started at, because I need to make some changes to WinMBF that may cause its demos to become not absolutely 100% compatible - mainly, this means fixing the bug in the clipping engine that causes Archviles and Nightmare respawns to glue monsters together. I know if Lee had known about this, he never would have released MBF with the problem, and it's pretty serious since it could affect player spawning, particularly in deathmatch. It'd be nice if I could avoid conflicting with existing PrBoom demo versions, but if PrBoom starts at v2.04 then I may have no room. The only thing I could do then is modify the header's demo signature.

This is assuming, of course, that the PrBoom(-plus) guys would ever have interest in adding a WinMBF complevel :) If there's no chance of that, then it won't matter if the demo versions conflict.

[Creaphis]

You should know this stuff far better than I do, but I seem to have PrBoom 2.02 on my computer. The "modified" timestamp is November 15, '98.

[CODOR]

According to TeamTNT, PrBoom 2.02 was released sometime at or after the release of Boom 2.02:

TeamTNT said:
Version 2.02 for Win95/98/NT now available
(No feature changes from Boom 2.02 other than working in Windows)

I don't know if there were any earlier versions; it seems to be the earliest version of PrBoom I have (I have at least the source for Boom 2.01 but apparently not 2.00, dunno about the binaries at the moment)...

[myk]

You'll ruin WinMBF as a port of MBF. If people want fixed MBF-like behavior they can use PrBoom/+ or Eternity with the corresponding settings. Instead, make sure that Eternity really supports MBF features, and encourage the PrBoom/+ developers to do the same. I know at least that OPTIONS lump support is missing in PrBoom/+.

Some port coders left out some MBF stuff, supposedly to allow MBF to have some unique things to encourage people to use it for them instead, but that's kind of stupid considering engines like PrBoom are a port (in the true "migrating to another OS" sense) of Boom and MBF, so there's no problem if they support them fully.

[entryway]

Quasar said:

This is assuming, of course, that the PrBoom(-plus) guys would ever have interest in adding a WinMBF complevel :) If there's no chance of that, then it won't matter if the demo versions conflict.

PrBoom supports ONLY dead ports

BTW, there is only one known desync between prboom+ and MBF
http://sourceforge.net/tracker/index.php?func=detail&aid=1740453&group_id=148658&atid=772943
I tried few times, but without a luck :(

[Quasar]

I'm only fixing critical bugs that crash the game or could cause serious problems. So far I've applied EE's fixes to the zone heap, threaded thinkerclass lists, etc. - stuff that has no impact on normal game play.

If you really think it would be offensive to the users to repair the clipping engine bug, then I'll leave it alone. But really, it's a very serious problem that can mess up Nightmare gameplay and Archviles. Other than this, I'm totally unaware of any other MBF bug I could fix that affect game sync.

Except maybe the extended locked door problem, but I wasn't intending to mess with that, since it's so rarely used anyway, and the error only allows the door to be opened with fewer keys, rather than preventing it from being opened. In other words, it's not a fatal problem.

[myk]

You would be better off changing the version number (making it WinMBF v2.04, if I am not mistaken). In fact, if you make such a change, you may as well take the opportunity to fix any other bugs you find (I don't see a problem, once you pass the purist line). You could also add an "-v203" command line argument or an equivalent CFG entry to enable true MBF compatibility as Killough left it, bugs and all.

[Quasar]

I'd rather have it work the other way around. That is, the default behavior would be pure v2.03 compatibility. To enable gameplay-affecting fixes would require setting an option. It's more work, but it would keep everybody happy I think. Then I only have the dilemma of whether or not to support recording demos while the fixes are enabled.

[myk]

Buuump!

Is this going to happen? Do you think you could build a fixed DOS binary (based on what Killough left) in the process?

PS: My suggestion is to support demo recording with the fix somehow.

[Quasar]

It may yet, but probably not in the next WinMBF release, which is upcoming very very soon - I just need to add Choco Doom's low-level video scaling so that you can play it in a decent resolution and it will be ready.

Changes in the new version will include:

• BOOM zone heap corruption problems fixed
  
• BOOM memory efficiency bug fixed
  
• BOOM co-op savegame bug (player corpses awaiting deferred removal causing crashes) fixed
  
• BOOM spechits underflow crash fixed
  
• MBF thinkerclass list corruption bug fixed
  
• MBF spectre fuzz fixed (Lee intended to fix this and released a patch, but the original patch is lost so I used SMMU's fix for it)
  
• New sound engine from Eternity
  

None of these changes impact compatibility or demo sync, and are only internal fixes that will bring the game up to EE's stability level. The sound engine does cause a slight change in presentation, but this is minor and is for the better as it keeps everything in sync with the low-level code from EE.