zokum Posted November 16, 2018 (edited) Warning: This is a technique for Doom compatible maps. If you're mapping for Boom, Eternity, 3dge, (insert favourite port here), etc, you might not need this. This has only been tested in Chocolate Doom. Block Rocking Bytes, version 1.2 update!http://doom2.net/zokum/brb/zokblok1-2.zip Map01 to map03 information The maps have not changed since the last release. Map 04 information The term oversized map has been coined for maps that would generate a too big blockmap with conventional techniques. The term outside in this context refers to the area outside the normal play area where the players and monsters roam. In this case the map spans such a big area that the entire map would make the blockmap size about 111kilobyte. This is far larger than the conventional limit of about 65k with current tools. This map has a blockmap of less than 9 kilobytes, despite being about 20000 by 20000 game units big. The map is so large and open that in a few places you can reach max drawing distance limits. This can be fixed by making a more interesting map design where you can't stand in the southwest corner and see all the way up to the far northeast corner of the map etc. I am sure someone can build something way nicer than the 5-10 minutes I spent on making this and trimming it down so that draw distance problems weren't too bad. This is a technical concept map, not an architecture map. You get this oversized effect by tagging the outside architecture linedefs with the tag 999. This excludes these lines from the blockmap and also from the area the blockmap spans. There will be a linedef type added for this at some point to make it easier to remember and use in editors. If you look at the map, the blockmap only spans and has full collission detection for small earth area in the center of the map. Outside of this the collission detection should work fine vs floors and ceilings, but not walls. Care has to be taken when designing maps to avoid this becoming an immersion breaking problem. For an outer wall, you should be able to tag the outside edge, it's enough that the inner edges are collidable by being on the blockmap. ZokumBSP doesn't quite build reject maps for such large maps correctly, so for the time being just build with -rz, I will try to fix this. There is a very minor bug in the latest released ZokumBSP where it uses vertex 0 as the base values for leftmost, rightmost, topmost, bottom vertex. This can create a larger blockmap if vertex 0 is only used for excluded outside walls. This can be circumvented by having vertex 0 in the main play area of a map. This is already fixed in the source on GitHub. The command line i used was: zokumbsp -rz overs001.wad -o testing.wad This is something that I've been researching for only a few hours after having thought about it now and then for a few days, so there might be some problems that show up with this approach. Hopefully people can safely play around with this a bit and create som really great vistas in their maps. Edited November 16, 2018 by zokum : Forgot to add link to wad.... 3 Share this post Link to post
zokum Posted November 16, 2018 As always, this is also a test wad for port developers. Ideally all the data should be handled just like doom2.exe handles it, or better. I don't think this will be troublesome for ports, but experience has taught me that ports can have some odd code changes and optimizations. 0 Share this post Link to post