What source ports fix the buggy blockmap?

[bofu]

You're at 12% health, no armor. You've got two shells left, and the archvile at the end of the hallway is heavily wounded, but you have no cover. You hope against hope that this salvo from your super shotgun will be enough to take down this archvile, because you won't get a second chance.

 

You run down the hallway at full speed. Only a point blank shot will work, you realize. The archvile raises his arms, and you feel the sweltering heat as fire starts to crackle around you. Finally, just before the archvile finishes casting its foul magic, you pull back the trigger on your super shotgun. Both barrels erupt in what will most definitely be a point-blank killshot.

 

Instead, your pellets pass harmlessly through the archvile's body without impacting it. It finishes casting its spell, and your incinerated corpse is thrown ten feet in the air. Somewhere, you hear the chortling of a dozen developers in your ears as the life leaves your body.

 

Of all the bugs in the Doom engine, the blockmap is probably the most ubiquitous one in terms of gameplay. Many Doomers have trained themselves to fire at diagonal angles to compensate, but that's really not something players should have to take into consideration. I know that GZDoom has overhauled the hit detection code and resolved this issue, but have any other source ports managed the same thing? Have there been considerations of implementing new complevels specifically to fix the blockmap bug? And would that even be possible? I would personally love to be able to not have to worry about the blockmap in in, say, DSDA-Doom, even if I have to choose a specific complevel for it.

[Shepardus]

ZDoom, Doom Retro, and International Doom are the ones I know of that have fixes for the blockmap bug.

[Julia Nechaevskaya]

These two blocks of code may be handy, it's all really needed: https://github.com/JNechaevsky/inter-doom/blob/master/src/doom/p_maputl.c#L415-L522

But beware, this is a direct path to demo desyncs! For single player game (i.e. not demo playing, not demo recording, not network game) this is fine, though.

Edited August 15, 2022 by Julia Nechaevskaya

[bofu]

13 minutes ago, Julia Nechaevskaya said:

These two blocks of code may be handy, it's all really needed: https://github.com/JNechaevsky/inter-doom/blob/master/src/doom/p_maputl.c#L415-L522

But beware, this is a direct patch to demo desyncs! For single player game (i.e. not demo playing, not demo recording, not network game) this is fine, though.

 

I don't know enough about code to do anything with this, but if someone wants to mess around with it, I'd be real interested in seeing if this could be implemented in a new complevel (since a new one would prevent the demo desync from happening).

[PKr]

2 hours ago, Julia Nechaevskaya said:

These two blocks of code may be handy, it's all really needed: https://github.com/JNechaevsky/inter-doom/blob/master/src/doom/p_maputl.c#L415-L522

But beware, this is a direct path to demo desyncs! For single player game (i.e. not demo playing, not demo recording, not network game) this is fine, though.

Didn't know I needed this, but thanks a lot! Added it to Woof, since I play single player and don't record demos anyway (unless testing stuff). Seems to be working fine! 👍

[Julia Nechaevskaya]

No problem! It seems to be vanilla-compatible code, since whole P_BlockThingsIterator function is completely vanilla. I've done various tests before and can conclude few things:

• Technically, this fix require some extra CPU power, because more BLOCKMAP blocks now will be checked every calculated tic. Not really much, and framerate drops probably will be notable only very low-end systems in extreme scenes or slaughter maps with lots of monsters/projectiles (i.e. actors which are using BLOCKMAP checking).
• Hit-scan weapons, notably SSG, now missing much less often. Enemy shots presumably less often as well.
• As a bad side, some enemies will become thicker. Not a big deal commonly, but on some places like in NUTS.WAD, player no longer can fit into this way for final running to exit switch, path will be blocked by Spider completely (screenshot).

So yeah, everything have it's own price. :) It's a neat fix to have as an option, but it have own foreseen and unforeseen consequences.

 

[Dark Pulse]

20 hours ago, bofu said:

You're at 12% health, no armor. You've got two shells left, and the archvile at the end of the hallway is heavily wounded, but you have no cover. You hope against hope that this salvo from your super shotgun will be enough to take down this archvile, because you won't get a second chance.

 

You run down the hallway at full speed. Only a point blank shot will work, you realize. The archvile raises his arms, and you feel the sweltering heat as fire starts to crackle around you. Finally, just before the archvile finishes casting its foul magic, you pull back the trigger on your super shotgun. Both barrels erupt in what will most definitely be a point-blank killshot.

 

Instead, your pellets pass harmlessly through the archvile's body without impacting it. It finishes casting its spell, and your incinerated corpse is thrown ten feet in the air. Somewhere, you hear the chortling of a dozen developers in your ears as the life leaves your body.

 

Of all the bugs in the Doom engine, the blockmap is probably the most ubiquitous one in terms of gameplay. Many Doomers have trained themselves to fire at diagonal angles to compensate, but that's really not something players should have to take into consideration. I know that GZDoom has overhauled the hit detection code and resolved this issue, but have any other source ports managed the same thing? Have there been considerations of implementing new complevels specifically to fix the blockmap bug? And would that even be possible? I would personally love to be able to not have to worry about the blockmap in in, say, DSDA-Doom, even if I have to choose a specific complevel for it.

If it's what I'm thinking you mean by this, this isn't technically a bug with the blockmap, it's a bug with where the game thinks Things actually are.

 

 

The basic fix for this, IIRC, is that rather than use the center of the Thing for checking which blocks the Thing is in, it instead uses the bounds of the Thing to do so. This results in more Blockmap checks, but it also guarantees that the collision will be processed, because now it's not possible to shoot into a blockmap block where the monster "isn't."

 

As for what ports fix it? That's a trickier question. My hunch is probably PrBoom and up. It's at least easily testable, if you use the suggested levels to check for it, or build a quickie level with which to do so.

 

 

[bofu]

6 hours ago, Dark Pulse said:

If it's what I'm thinking you mean by this, this isn't technically a bug with the blockmap, it's a bug with where the game thinks Things actually are.

 

 

The basic fix for this, IIRC, is that rather than use the center of the Thing for checking which blocks the Thing is in, it instead uses the bounds of the Thing to do so. This results in more Blockmap checks, but it also guarantees that the collision will be processed, because now it's not possible to shoot into a blockmap block where the monster "isn't."

 

As for what ports fix it? That's a trickier question. My hunch is probably PrBoom and up. It's at least easily testable, if you use the suggested levels to check for it, or build a quickie level with which to do so.

 

 

I know about the real causes of the bug, but it's colloquially referred to as the Blockmap Bug even if it's a result of faulty thing placement.

 

Boom does not fix this. You can watch quite a few streams/playthroughs recorded in the Boom family of ports where shots go through enemies. Fixing it in any of the current complevels would cause demo desynchronization, so if Boom/PrBoom+/DSDA-Doom/Woof did add it, they would probably need to do so in a new complevel, which I would support wholeheartedly.

[Dark Pulse]

That's why I said PrBoom. It's presumably got those complevels that do fix the bug, but well, if it doesn't, then I'd imagine that it's even more advanced ports than that (but I'd also be very surprised if there's not at least one complevel that doesn't fix it).

[Shepardus]

None of the PrBoom+/dsda-doom complevels fix the blockmap bug.

[bofu]

I decided to be the change I wanted to see in the world and got this working in my local copy of PrBoom+ via an option.

 

 

Preserves demo compatibility, too. The setting is ignored when in MP or when playing/recording demos, like free look and other settings. Works in any complevel, too.

 

 

 

[Dark Pulse]

1 hour ago, bofu said:

I decided to be the change I wanted to see in the world and got this working in my local copy of PrBoom+ via an option.

 

Preserves demo compatibility, too. The setting is ignored when in MP or when playing/recording demos, like free look and other settings. Works in any complevel, too.

I'd hope you'll submit it as a pull request?

[bofu]

16 minutes ago, Dark Pulse said:

I'd hope you'll submit it as a pull request?

I'd like to, or at least get it in front of a coder who can clean it up. But I don't think they want to add new gameplay features to PrBoom+, even hidden behind an option.

[PKr]

7 hours ago, bofu said:

I'd like to, or at least get it in front of a coder who can clean it up. But I don't think they want to add new gameplay features to PrBoom+, even hidden behind an option.

If you want to share the prboom+ with collision detection with others then I guess your best bet would be to create a separate fork of prboom and give it a different name to distinguish it from prboom.

 

Not sure how reasonable it is to create a separate source port for 1 change though...

[fabian]

We are currently on the way to accept this in Woof. 

[bofu]

2 hours ago, fabian said:

We are currently on the way to accept this in Woof. 

I'm very excited for this. It's a good option to have on or off per user preference. I think the implementation is going to be a lot cleaner than what I threw together, too. (And the Woof code is a bit easier for me to work with - compiles a lot easier, too!)

[bofu]

There's currently a PR in this for Woof. I didn't write it (which is for the best, believe me!) but have been looking it over along with @Julia Nechaevskaya. Very impressed with how the code in International Doom handles this, and it's easily adaptable even for someone with minimal programming knowledge like me.

 

Issues for feature requests have been raised in both DSDA-Doom and PrBoom+ projects. That being said, PrBoom+ is in maintenance, and there are also concerns about introducing wild gameplay changes (though I am going to be doing some testing involving demo playback/recording to try to alleviate concerns there).

[Ralphis]

Odamex has had it for about 10+ as an option. sv_blockmapfix is the variable, which is off by default. Many servers run with it enabled though

[wesleyjohnson]

Have not seen this with DoomLegacy.

It has is a fix in P_CheckPosition that checks adjacent blockmap units (out to MAXRADIUS) because things may overlap into other blocks.

It sorta sounds like that may be the same thing (or NOT).

 

Do you have a test wad yet, that we could use to test if a port has the problem, and for testing the fix ?

I cannot remember having seen anything like this, in playing DoomLegacy for 20 years, so maybe DoomLegacy has it fixed too.

 

[bofu]

5 minutes ago, wesleyjohnson said:

Do you have a test wad yet, that we could use to test if a port has the problem, and for testing the fix ?

I cannot remember having seen anything like this, in playing DoomLegacy for 20 years, so maybe DoomLegacy has it fixed too.

 

 

I do, actually.

 

The attached WAD has a few maps where you can actually see the blockmap visualized via floor/ceiling textures for testing purposes. In MAP01, you can reliably miss the zombieman in front of you if you fire without moving, while in MAP03, the same is true for the spider mastermind even if you move within the square you start in without aiming toward the center of its sprite.

blockmaptest.zip

[wesleyjohnson]

Tested with DoomLegacy.

Map01:  zombieman died with two shots

Map03: spider felt it, turned around and killed me.

Then I found the shotgun.  I shot it from where I picked up the shotgun.  It felt that too, and turned around and killed me.

If I shot at the left leg, it had no effect.  Shots to the left knee were ignored.   Shots to the body were effective.  Shots to the right knee joint were effective.

 

Edited September 16, 2022 by wesleyjohnson

[bofu]

4 hours ago, wesleyjohnson said:

Tested with DoomLegacy.

Map01:  zombieman died with two shots

Map03: spider felt it, turned around and killed me.

Then I found the shotgun.  I shot it from where I picked up the shotgun.  It felt that too, and turned around and killed me.

If I shot at the left leg, it had no effect.  Shots to the left knee were ignored.   Shots to the body were effective.  Shots to the right knee joint were effective.

 

 

Was this with or without changing aim? The shots to the legs missing sounds like the blockmap issue. When I use Doom Retro or enable Woof's blockmap fix, I can't shoot the Spider Mastermind without turning a bit (or just strafing until I'm right behind it)

[ludicrous_peridot]

Would be too lazy not to test with Tartar of MBF > SMMU > 2002-grade Eternity lineage; the damn zombieman is a Neo-type fellow as none of my projectiles hit him :) I am curious if this type of bug should be fixed though..? I'm just not sure, and while I appreciate that port maintainers decide for each of the port if it should go in, I wonder what is the general feeling about it and if it's there in the Unity port?

 

How did the story with "concerns about introducing wild gameplay changes" end by the way?

 

Also thank you very much for the test wad.

[bofu]

3 hours ago, ludicrous_peridot said:

Would be too lazy not to test with Tartar of MBF > SMMU > 2002-grade Eternity lineage; the damn zombieman is a Neo-type fellow as none of my projectiles hit him :) I am curious if this type of bug should be fixed though..? I'm just not sure, and while I appreciate that port maintainers decide for each of the port if it should go in, I wonder what is the general feeling about it and if it's there in the Unity port?

 

How did the story with "concerns about introducing wild gameplay changes" end by the way?

 

Also thank you very much for the test wad.

 

PrBoom+ and DSDA-Doom said no, flat out. It's true that this changes gameplay a bit, as it does make Nuts.wad unbeatable because you can no longer squeeze past enemies (it impacts thing detection). That being said, the intention was only ever for this to be an option the player could use if they wanted, not hardcoded behavior.

 

I also don't buy the argument that for the average player, it changes gameplay too much. These are ports that have jumping and freelook options, and I think those change gameplay far more considerably.

 

I've been testing a few megawads with and without the option on. I have not seen a single case of something feeling "off." I guess if a map were built around the buggy blockmap, turning the option on would break that map, but you know what? In a map not built for jumping, jumping breaks that map, too.

[Graf Zahl]

1 hour ago, bofu said:

I also don't buy the argument that for the average player, it changes gameplay too much. These are ports that have jumping and freelook options, and I think those change gameplay far more considerably. 

 

I've been testing a few megawads with and without the option on. I have not seen a single case of something feeling "off." I guess if a map were built around the buggy blockmap, turning the option on would break that map, but you know what? In a map not built for jumping, jumping breaks that map, too.

 

The most notable thing being "off" is that you can BFG the Spider in one shot. As long as you deal with smaller monsters you are unlikely to notice much - but I would expect highly experienced players to 'feel'  the difference. It certainly was noticable enough that it warranted adding a compatibility option in ZDoom.

 

[Xaser]

I'd love it if the blockmap fix were available as a mod option somewhere (umapinfo? options lump?), rather than a user option or complevel thing. It does change gameplay pretty considerably in a few aspects (1-shot Spiders, being able to punch arachnotrons, etc.), and shipping the gameplay option in a wad solves the problem very neatly. I'd really rather just be able to design my maps around the fixed behavior, 'cause I like it. :P

[Devalaous]

...werent you ALWAYS able to oneshot the Spider Mastermind? I know I did it recently in NEIS, and I did it back on the Xbox 360 and PS3 ports at least.

[Graf Zahl]

You can do it, if the stars align properly, but the changes of it are pretty slim with the original blockmap code.

 

[bofu]

It's probably a lot more reliable with the blockmap fixed. The Spider Mastermind is a really wide enemy and always overlaps at least four blockmap blocks.

 

One fun thing is that you have a harder time squeezing past monsters with the blockmap fixed. In casual play, the average player isn't going to notice much besides whiffing shots less often. Speedrunners will hate it because it makes enemy hitscanners slightly more deadly and makes it harder to squeeze past enemies. That's why I like the idea of it being an option you have to enable in any port it appears in.

[ChopBlock223]

On 8/20/2022 at 1:33 PM, fabian said:

We are currently on the way to accept this in Woof. 

Oh that is fucking SWEET.

 

Some day I would really like to see improved hit detection worked into a complevel (maybe a new MBF one) so it can be part of demos, primarily to make melee fighting much better, but it's great enough to just have as an option like this.

 

Though I guess with how it can mess with speedrunners it may not be the most popular to bake into a shiny new featurebound complevel. Could improved hit detection for attacks be achieved while keeping things fast and loose for individual players/monsters colliding with each other, so it's still possible to squeeze?

 

13 hours ago, Graf Zahl said:

The most notable thing being "off" is that you can BFG the Spider in one shot.

Isn't that already the case in vanilla? You get right up in his face and his big fat hitbox takes every one of your tracers?

 

11 hours ago, Graf Zahl said:

You can do it, if the stars align properly, but the changes of it are pretty slim with the original blockmap code.

I must have done it a few dozen times, but maybe some of those were in ZDoom.