Talk:Map size limit (blocks)

This should probably be tested in -nomonsters mode.  If you still hear monster sounds after running into the void for a while, then this limit isn't the only phenomenon at work.    Ryan W 03:54, 16 September 2006 (UTC)

A recent look at BSP's source code reminded me of something. I don't believe this page is correct if blockmap compression is allowed for. The basic idea is that multiple blocks can have the same offset, and so point to the same line list. As long as the exact same lines are present in each block, this will work and provide a fully functional blockmap even in vanilla. In the four linedef case shown here, only 9 blocklists are needed at most: (empty), (L1), (L1, L2), (L2), (L2, L3), (L3), (L3, L4), (L4), (L4, L1). These would take up 48 bytes, and plus an additional 8 bytes for the file header, would leave room for up to 65507 block offsets. This gives a potential level size of over 32000 x 32000 (by which point you've probably smashed a few other limits multiple times already).

Of course this is all rather silly as no actual level will have 4 linedefs, and the practical size limit is dependent more on the number of linedefs and the complexity of their arrangement than the physical bounds of the level (as empty blocks are cheap, especially with blockmap compression, and blocks loaded with linedefs are expensive).

If I figure out an elegant way to word this all I'll slap it in the article. Goyuken 04:08, 16 October 2007 (UTC)

Maximum block count in vanilla

I've just found my notes from 2006 where I "derived" the 4-sided example.  I can't make head nor tail of them.  Therefore, if anyone ever thinks about rewriting this, please don't bother asking me to explain myself (as one editor has already done).  Also Static limits#Blockmap might need to be changed to match.  Sorry!  :>     Ryan W (talk) 04:39, 20 April 2015 (UTC)

Redirect

I am not sure that turning this into a redirect was within consensus, and hasn't been done properly either. --Quasar (talk) 22:19, 5 May 2018 (CDT)

The current content can arguably move to Blockmap and Static limits without losing anything.  I agree on the process points — misinformation is undesirable, the citation belongs in the target article, and redirects are rarely categorized (though precedent suggests we might do so someday if limits had their own subcat).

My intuition (as a non-programmer of course) is that most limits could have standalone articles based on algorithmic details and history.  Where have players seen the limit in stock maps?  Can it be exploited as an effect, or at least as a troll (e.g. aborting with MAXPLATS)?  Were any classic PWADs memorably affected?  Did limit-removing formats eliminate it right away, or raise it (same question about period mods then), or ignore it for a while?  Can a modern vanilla mapper avoid it deterministically (e.g. lost soul limit), and if not, what tools or experiments are recommended to remediate?  That said, I understand not wanting to leave brief stubs around for the 24 years these improvements take.  :>    Ryan W (living fossil) 09:21, 19 May 2018 (CDT)

This was never resolved so I've undone it for now. If someone wants to merge the contents properly I have no objection. --Quasar (talk) 10:25, 25 May 2020 (CDT)

This article has multiple issues and errors. The image is also wrong as it doesn't take into account blockmap compression which has been common since the 90s. Terms are mixed and the whole article is very confusing to read. The limit of the blocklist is that no list entry may begin after the 65536th byte. In a blockmap where the largest list is say 60 lindefs, the blockmap limit would then be 65534 + 60 * 2 + 2 = 65656 (each linedef takes two bytes, end marker two bytes). A bigger lists would increase the maximim possible size of the blockmap. Zokum (talk) 21:36, 19 January 2021 (CST)