Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  
printz

Why do PrBoom and Eternity re-create the blockmap if it's longer than 65535 entries?

Recommended Posts

I see that both PrBoom+ and Eternity decide to create the blockmap (P_CreateBlockMap) internally if the lump has more than 65536 (0x10000) blocks. But why do they do it, if the lump exists already?

Share this post


Link to post

Does that mean they invalidate blockmap tricks by doing so?

Do you have a test wad, sounds interesting.

Share this post


Link to post

A quick example is exactly the map you showed me in the Eternity forum (Hellbound's full MAP29). I fixed the bug that prevented it from starting (get the latest build from here), but besides that, it has so many map blocks that it triggers the blockmap internal creation (see the console). I don't know of any special effects that may be cancelled. It's just that the map loader does work without needing to (also beware of demo compatibility with PrBoom Boom/MBF complevel when blocks are re-created).

Share this post


Link to post
printz said:

I don't know of any special effects that may be cancelled.

They are certainly at least theoretically possible. If you consider this:

doomwiki said:
Removing the blockmap from a level will not affect the rendering of the level or any line of sight calculations, but all collision detection will be nonfunctional.

You could purposefully prevent a particular linedef from being included in blockmap, and then it would be rendered but not collided with, or do the opposite, include a linedef only to blockmap but not to segs, making it invisible but collidable with.

Share this post


Link to post

Sorry, I meant that I don't know of any potential special effects in that particular map, in case VGA asked me for such map examples.

Anyway the main question was: an entry is merely 2 bytes in the lump. So why are lumps limited to 128k like this in these ports? Answer: I assume it's because of the limits of the vanilla BLOCKMAP format, using 16-bit ints everywhere.

New question: what's up with the big BLOCKMAP lumps? Are they in an extended format?

Share this post


Link to post

The general assumption was that any blockmap with such dimensions cannot exist in the original format and must be considered broken.

Don't ask me about the specifics here, though.

There is no extended Blockmap format. It was never needed, because recreating a blockmap is dirt-cheap and can be done on the fly without worrying about overhead.

Share this post


Link to post

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this  
×