Better fix for visual glitch bug
samboy opened this issue · 2 comments
In #9 I “fixed” a visual gitch bug by, after failing to find anything in the very messy put-side-then-corner code which caused the bug (It looks to be an issue of having the corner in the wrong place, but fixing that may change a lot of maps, so I tread very softly even if the code is buggy), just having the writer check if this visual glitch is happening, and put in a less obnoxious texture than the pulsating FIREBLU1 texture if so.
While this improves things, the real fix should be in builder.lua:
- Look at a map
- If there’s a case where a blog/fragment (a 64x64 block can be split up in to smaller “fragments”) is adjacent to nothing, and the ceiling is
F_SKY1, then make sure we make that fragment a sky border withbuild_sky_border - Make sure this change alters only
MAP27via the automated tests. If not, find another fix.
OK, I have done it. I have added code to builder.lua so that:
- If a given block is a “sky border” (which I also sometimes call a “skybox”), we have a table entry in the block called
has_skywith the value true - After building an entire level, we look at every single block on the map. If the block is on an edge of the map (it has at least one void neighbor [1]), then we make sure the block is either a “solid” block or a “skybox” block.
- If a block is on an edge, and is not “solid” nor a “skybox”, then we mark it as a bug. I have some code which makes the block a sky, but that actually looks buggy in the old
MAP27, so we rebuild the entire map with a different architecture.
This solves the problem in a way that the sky of a map does not look buggy.
All of the tests have been updated and pass again; only MAP27 (and the deathmatch-only items in MAP28, MAP29, and MAP30) has changed. Closing ticket.
[1] I am aware that Andrew spells “neighbor” differently in the Oblige source code, but I’m American and this is how I spell this word.