Menu
▾
▴
1 Attachments
#96 Support for internal blockmap creation
The attached implementation is based on Crispy Doom 5.8.0 from Fabian Greffrath.
I have modified the data types and indentation to match DooM Legacy.
The feature is enabled with the new "-blockmap" command line option similar to PrBoom+
(but there is currently no autodetect code as in PrBoom+).
A notice is printed on the console when the blockmap was generated internally.
The provided distinct patchset is for review. But this should be combined with the extended node patchset, because most maps with problems are large and trigger both limits.
Both patchsets together can be used as workaround for Bug #658
and for WADs with empty blockmaps like in NOVA III:
https://www.doomworld.com/idgames/levels/doom2/Ports/megawads/nova3
I have also tested Lost Civilization (several maps with clipping problems):
https://www.doomworld.com/idgames/levels/doom2/Ports/megawads/joi_lstcv15
and Eviternity Map 15:
https://doomwiki.org/wiki/Eviternity
$ doomlegacy -file Eviternity.wad -warp 15
(the door in front of you doesn't open without patches)
Header file and patches.
Last edit: Michael Bäuerle 2020-05-19
Updated version attached. It contains a patch from Altazimuth for Eternity Engine:
Fixes MBF's code, which has a bug where maxx/maxy are wrong if the 0th node has the largest x or y.
The blockmap generator was not as invasive as I feared. Seems to be a simple minded blockmap generator.
Of course, I mangled it heavily, mostly due to some of their code violating some of my programming and readability rules, like burying assigns in expressions.
It seems to work.
I put a control menu under Game options (advanced, 3rd page).
Vanilla = same old Blockmap
Large = on large blockmap (prone to errors), generate
Generate = generate always
Auto = Load, if get significant errors, then generate
Thank you for merging FR #96!
Quick test with Eviternity: It seems to work in general.
When I save a game, change the option and than reload it, the former option is used.
I think this is intended and correct.
But something looks wrong with the selection logic: After loading a game that restored a different setting, all maps now use this setting (new game or idclev cheat). I think the start of every map should use the configured setup again.
While testing new game with "Vanilla" configuration and a savegame of Map 15 with "Generate", I got multiple Segmentation Faults (on NetBSD/amd64 with SVN 1595).
Last edit: Michael Bäuerle 2021-10-18
Managed to play through Eviternity map15 without blockmap, so that must have been a node issue.
Unlikely, because the map was not playable without the code for extended nodes.
But if I remeber correctly, you have modified/improved the blockmap import code (for Lost Civilization) since the time I created this FR.
It must have been a node issue (or a dehacked problem) because I was able to play it on the version before the blockmap generator was installed. I was trying to test what effect the blockmap had, and I have not found any cases yet.
That means the bugs that were seen are still there.
I am trying to chase down one bug in a house in Avactor map4, that causes the floor to be missing. It seems that the sub-sector polygon has 0 segments.
The blockmap generator is marked as a NETVAR, because it would probably be bad to have two computers using different blockmaps. So.., that means it is saved and restored with save games.
Newgame is not restoring user setting for blockmap generator. Noted.
Segfaults: you are going to have to run a DEBUG version and point to a line number.
Patch w109_059_hwbsp, svn 1598, fixed a missing floor in Avactor.wad.
This was due to the bsp partitioning divline missing the subsector polygon,
and only clipping a single vertex.
There was a mistake in handling of this exceptional situtaion, which would look like a blockmap problem. There were numerous similar subsectors (probably 30 or more) seen in Avactor map04 alone, half of which would have been handled wrong.
Does this patch fix any of the problems that you saw as possibly being due to blockmap ?
At least the problem with Lost Civilization Map 4 (that I described at 2021-09-27 in the FR #95 thread) is still present with SVN 1598, if I configure the blockmap generation to "Vanilla".
While loading the blockmap there are many warnings like:
Blockmap offset[4046]: Overflow 0x30000, exceeds lastlist=0x2327A
I have now played all maps of Avactor again (SVN 1598 with the software renderer on my big endian machine). I noticed no blockmap problems.