somehow show blockmap for live play (feature)

[runlow]

Somewhat related to #187

Since the block map bug is deliberately kept in and considered a part of the game - how about a debug cheat/option/shortcut for a view in which lines would indicate the blockmap in the game - an overlay of vertical lines infinitely extending from top to bottom for each corner of the grid (the point where its lines intersect)?

Similar to how chunk borders are shown in minecraft in its "debug view". It could maybe be toggled with a TNTBLOCK or IDBLOCK cheat.

Maybe it could also show the actual X shaped enemy hitboxes with lines in a different colour in 3d, as well as the hitscan rays - if that's doable/feasible.

The blockmap is already shown in the automap (when you press g when it's open) but it can be difficult to visualise the grid in a 3d environment, especially in combat (and that's what this bug is affecting).

The idea is that with this "debug view" one could test what conditions have to be true for the blockmap bug to kick in on a map and which invisible lines need to be avoided. One could visualise better where to punch/point chainsaw to not miss the hitbox.

I understand that in many/most cases it doesn't matter. This would be intended for the edge cases.

Use case: I want to take down a cyberdemon in two BFG shots in AV.WAD but can't get it to work. Rather than just checking the grid in the automap - typing TNTBLOCK. Trying different ways to position self relative to the grid. Finding the right place to position self on the map for the trick to work. Typing TNTBLOCK to switch off the wireframe overlay. No longer needing the grid overlay as knowing where to stand from now on. The grid is in my mind.

The idea is that since intentionally not fixing the bug - trying to work with/around it. Let me know what you think.

If this view is doable in PrBoom+ I can see it being useful. The idea is that it would not add anything new to the core game mechanic but rather show more clearly how it already works so that the bug can be worked with.

[JadingTsunami]

Press "G" in the automap to show the blockmap grid, as you mentioned. I don't see much benefit in including more than this, honestly.

[runlow]

@JadingTsunami is that what you do when you test how the blockmap grid affects BFG rays?

I'm trying to work out if you're saying that you see no benefit because: a) there are better simpler existing ways of figuring out how the "hitscan rays" will hit (which you use yourself) and what I'm suggesting is superfluous b) you haven't looked much into it or been too concerned about the issue to begin with and hence not seeing much point in what I'm suggesting because not too involved about the whole thing at the outset

As mentioned before - when you fight with monsters you can't (easily) look at the automap and at the level at the same time, even with overlay mode on and the automap open. Is that what some of you do though?

I agree that caring about such obscure glitches is pretty out there and pedantic but some of us care. In a way so are the complevels (fussy, meticulous). PrBoom+ is used by speedrunners who use such (and other) glitches. I'm not doing speedruns myself (much) but a lot of it interests me.

What I mean is: Do you say this because you don't worry much about the blockmap to begin with or because you found better ways of checking? Is what you recommend working for you for landing BGF shots or predicting which shots will land and which won't? If so - could you explain how you use the 'Press "G" ' method yourself? Do you align yourself in a certain way toward the grid first with -nomonsters and then later use that in combat?

Maybe - if you don't mind - if any of you think this is a bad idea - can you please state first if it's because you don't think much about the bug or because you know of (and use) better methods and you think one is better off learning to look at the automap while playing, and if hence what I'm suggesting - in reference to collision detection - is pointless blink in practice.

The way I see it - I can see how it can seem unfair that one is limited by a difficult to detect bug that has to be kept in for the sake of compatibility and for staying true to the original - but by providing a debug tool (if feasible) that makes the bug more apparent - one can learn more easily how it works and learn to work/navigate with/around it - which makes the whole thing a bit less unfair.

I may be wrong but - if you don't mind - please explain where my reasoning is flawed.

[fabiangreffrath]

I could live with the idea of showing blockmap borders in the player view. I see it in the same category of debug aids as the health bar on top of the monster sprites. Anyway, just like that, this feature would be limited to the OpenGL renderer, because I doubt that cou can draw such hair-thin lines with the software renderer. However, given that there is no OpenGL capable developer around (anymore), I see this request pretty far down the wishlist rather than an immediate TODO.

[kraflab]

This is something I wanted to look into for dsda-doom at some point (possibly not the exact solution requested here though). If I come up with something I'll bring it upstream.

[runlow]

@fabiangreffrath Not saying my idea for how it could work is great. There may be something simpler and better.

Now that I think about it - maybe I could just do the IDDT cheat twice on the automap so that it outlines things and then try to play that way. I'll test it.

Maybe the blockmap debug could colour a thing sprite depending on how far it is from a nearest X and Y grid line. Let's say Red channel being X offset and Blue being Y offset (so when the sprite is black it means it's perfectly standing at a blockmap grid line intersection). Or another combination of colours that would work better with doom's palettes.

No problem with it being far down the wish list.

Not sure I get why you dislike the health bar though and calling it "aids" :thinking: unless you mean that it only works in OpenGL, then I agree. Unlike the health though this is about a bug so it's not exactly the same. Please correct me if I'm wrong.

@kraflab never knew dsda-doom existed, thanks for mentioning it! Will definitely check it. Interested in what you'll come up with for this.

[fabiangreffrath]

"Aids" is the plural of "aid" which means "help", "support", "assistance".

[JadingTsunami]

To elaborate on my point from before, I see only incremental value in this over automap in overlay mode + iddt x2 + grid.

The simplest and most practically effective blockmap strategy would be to lure monsters near the center of a blockmap grid and always aim at "dead center" when firing. Getting as close as possible helps to ensure BFG blast tracers land on target.

When unsure you can always pause and check the automap to see current monster alignment. Doom's movement is so fast you'd probably have to pause to survey the situation anyway.

Tunnels and corridors with blockmap lines running centrally through them should be attacked diagonally where possible. I think other strategies would be fairly ineffective. If there is "more" blockmap area on one side than another, try to put monsters on that side when you're attacking them and stand on the "less" side when being attacked.

I'd think checking the arena beforehand in automap with grid mode enables the player to employ all these strategies. I could maybe see floor grid tiles helping with monster alignment, but I suppose it's not much different than visualizing the squares based on grid mode, especially with textured overlays after surveying the map area. And again players can always pause and check the alignment.

To me it seems more like a specialized, separate tool to enhance TAS than something a player would be able to use during live gameplay.

[runlow]

@JadingTsunami excellent points/advice. Upon reflecting - the player's own position in the blockmap is probably much more important than that of the things on the map as the rest can be deduced.

Consider this potential debug interface.

Since the blockmap grid is 256x256 units (for one "block") - when you're exactly in the middle of a "block" you are 128 on X and 128 on Y from the nearest line, within the "block" - 128 is the highest possible distance in both dimensions. The grid itself doesn't matter as much as how far you are from the lines. (if I understand it correctly)

Left bar is X distance, right bar is Y distance (from grid line) in this example of what it could look like which I've drawn and it's meant to represent that the player is exactly in the middle of a "block" ingame. When the value of "block" offset is lower - the top part of the bar would be in a darker colour and the number would decrease. One would have to be be "filling up the bars" for a center or "emptying the bars" for an intersection.

For facing in the correct direction - could have a horizontal compass which would indicate X+ X- Y+ Y- axes (similar to north/south/west/east)

Having the offset as part of the (debug) HUD would maybe make it so that this information could be used in real time/live gameplay more conveniently. Haven't looked much into how feasible it is to implement.

I don't know if this would be helpful at all in practice and you may be right. I'll try to do some tests.

[runlow]

Even simpler:

left   nearest X blockmap grid line distance
right  nearest Y blockmap grid line distance
top    nearest right angle (90°) distance in angles

Don't know if this would be better than just opening the automap and typing IDDT twice.