Block Rocking Bytes

[zokum]

Links and contact
Web site: http://doom2.net/zokum/brb

Download: http://doom2.net/zokum/brb/zokblok1-1.zip

Contact: IRC zokum@EFNet,Quakenet,OFTC or the Doomworld forums.

What this is

A simple test wad designed to test compability in ports with regards to blockmap-related hacks, compression, special effects and optimizations. The maps are all designed for Doom 2 version 1.9, DOS / latest Chocolate Doom.

This is not a map set designed to be played, it contains some very basic architecture in order to test the tweaked blockmaps quickly and reliably. As time passes and more research is done, more maps will be added with different tweaks.

Version history
1.0 Initial release, zokblok1.wad

1.1 Minor updates on docs and added endoom screen, zokblok1.wad. Uploaded 28.04.2018 00:01 CEST due to pebcak errors.

Tools used

The maps have mostly been created with Anotak's Doombuilder X fork and then built with ZokumBSP. Some of them have then been opened in slade, had the blockmap exported and redone by hand in a hex editor before being imported back in. One of the goals of this project is also to add support for these algorithms and tweaks in upcoming releases of ZokumBSP.

Maps

map01 - Zero headered plus size. Uses a blockmap larger than 65536 bytes. It is
        65622 bytes, 86 bytes bigger than the conventional max-size. The area
        with the overhanging block list is the complex stair like area.
map02 - Zero header removed.
map03 - Separate render and collission geometry-simplification. The affected
        wall is the one with alternating silver textures.

Compability list for zokblok1.wad
Maps will be added to the project as more techniques and discoveries are documented and testable. The end goal is a stress test wad for doom vanilla behviour compliance and documentation of algorithms doom tool writers can implement. The end result should be greater support for maps across all ports and the creation of bigger maps.

No problems
map01-03: Chocolate Doom, Crispy Doom, Doom Retro and Eternity Engine.
map01-02: Doom Legacy and GZDoom, Edge.

Minor problems
map03: Doom Legacy and GZDoom - No decals on separate geometry.

Critical failures
map03: Edge - Rebuilt nodes causes render of more segs, z-buffer problems.

Untested
map01-03: Boom, MBF, PRBoom+, Zandronum, Zdaemon and Zdoom.

Edited May 10, 2018 by zokum
Added Edge information.

[zokum]

This post used to be an indication of what the title of the project was referencing, along with a relevant Youtube video. Seing how several people got it immediatly, it's kinda redundant :)

Edited April 24, 2018 by zokum

[Linguica]

I got it.

[zokum]

I've updated the doomwiki article about the blockmap lump and added a small stub article about this project. I have also received reports that all of the maps in zokblok1.wad work fine in the Eternity Engine. I have personally only tested them in Chocolate Doom.

Edited April 24, 2018 by zokum

[Xaser]

I got the song stuck in my head immediately when reading the thread title. Success, I suppose. Also, damn you. :P

[VGA]

The requested URL /zokum/blockrocking_bytes/zokblok1.zip was not found on this server.

[zokum]

7 minutes ago, VGA said:

The requested URL /zokum/blockrocking_bytes/zokblok1.zip was not found on this server.

Must have been real tired, forgot to save in slade before i zipped and uploaded, and url was also wrong, i had only edited the text on the link, not the location, the forum interface is a bit wonky. Correct 1.1 uploaded 00:01 CEST 28.04.2018.

Edited April 27, 2018 by zokum

[VGA]

I loaded it in Doom Retro 2.6.9 and in Eternity. I think all 3 maps are fine in both? Well, I don't know what we are looking at exactly, but they seem to load fine.

 

EDIT: They seem fine in latest stable GZDoom, too

Edited April 27, 2018 by VGA

[zokum]

On map01, check the stairs, if they work fine, it's all dandy. On map02 shoot at the stairs to check em. On map03 check that the alternating walls work ok. Legacy had problems with decals on the alternating wall. I should perhaps point this out better in the docs so people know what to look for. Map01 is basically a proof-of-concept that blockmaps larger than 65536 (64kib) are possible. There might be ports with odd alloctions or faulty blockmap tests.

 

Thanks for the testing of Doom Retro :)

Edited April 27, 2018 by zokum

[VGA]

I can climb and shoot and see puffs on the stairs on all maps and on the weird wall section. On Doom Retro 2.6.9

[VGA]

On GZDoom on MAP03 bullet hole decals don't show on the wall with the different sections.

[Coraline]

Some potentially useful info (via EDGE-2.1.0pre-7800-g740de2002):

-------------------

MAP01:
P_SetupLevel: Load GL info (glBSP)
GenerateBlockmap: MAP (-1216,-320) -> (352,640)
GenerateBlockmap: BLOCKS 13 x 8  TOTAL 104
Blockmap size: 13x8 --> Lightmap size: 4x2
Created 21 seclists from 56 vertices (37.5%)

-------------------

MAP02:

P_SetupLevel: Load GL info (glBSP)
GenerateBlockmap: MAP (-1189,-335) -> (379,625)
GenerateBlockmap: BLOCKS 13 x 8  TOTAL 104
Blockmap size: 13x8 --> Lightmap size: 4x2
Created 21 seclists from 56 vertices (37.5%)

-------------------

MAP03:

P_SetupLevel: Load GL info (glBSP)
GenerateBlockmap: MAP (-1216,-352) -> (480,640)
GenerateBlockmap: BLOCKS 14 x 8  TOTAL 112
Blockmap size: 14x8 --> Lightmap size: 4x2
Created 23 seclists from 63 vertices (36.5%)

-------------------

 

So far, the first two maps render without error, but MAP03 does have a texture

issue, I've attached two shots. 

 

[zokum]

I think the nodes are being rebuilt to be easily usable in OpenGL. The collission-only linedef is now generating a seg, and this leads to z-buffer-problems when there are two segs directly on top of eachother. This is a hard one to fix cleanly, but I can add some tweaks to make it easy to detect this to avoid it happening. Ideally, gl nodes should use the segs as a base, not linedefs. Thanks for testing @Coraline.

[Grain of Salt]

I got Galvanize stuck in my head instead of Block Rocking Beats. Is this a prboom-plus issue?

[fabian]

All 3 maps render fine in Crispy Doom.

[kb1]

7 hours ago, zokum said:

I think the nodes are being rebuilt to be easily usable in OpenGL. The collission-only linedef is now generating a seg, and this leads to z-buffer-problems when there are two segs directly on top of eachother. This is a hard one to fix cleanly, but I can add some tweaks to make it easy to detect this to avoid it happening. Ideally, gl nodes should use the segs as a base, not linedefs. Thanks for testing @Coraline.

Wow, z-fighting is causing the colors to blend in a gradient?

 

@Coraline: What GL construct makes that happen? (It's kinda cool, actually.)

[zokum]

I'm not a hardware enginner, but here is my take on it:

I think it's fairly hardware-dependant. There are two textures in the exact same space. With walls being drawn in parallell to the same z-buffer it all depends on which texture is written first to the Z-buffer. There might be some inaccuracies caused by the texel stuf manifesting as these weird patterns. All this is probably undefined bahaviour. The OpenGL standard says nothing about what to do in these cases.

Edited May 9, 2018 by zokum

[Visplane Overflow!]

Well i have tested it and heres the results:

Choc Doom works fine without any problem.

GZDoom and its family (IYKWIM) struggle on MAP02. After shooting the stairs, i was able to walk to the wall like you expect it noclip. GZDoom on MAP03 somtimes (not often happens) Crash while shooting at the white walls without any message regarding it.

 

See how blockmap alteration affects the gamplay differently on different source ports.

 

Anyway good maps!