Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
zokum

Block Rocking Bytes

Recommended Posts

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 by zokum

Share this post


Link to post

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.

Share this post


Link to post

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

Share this post


Link to post

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

Share this post


Link to post
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 by zokum

Share this post


Link to post

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

Share this post


Link to post

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 :)

Share this post


Link to post

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

Share this post


Link to post

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

Share this post


Link to post

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. 

 

shot01.png

shot03.png

Share this post


Link to post

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.

Share this post


Link to post
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.)

Share this post


Link to post

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.

Share this post


Link to post

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!

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×