Bug in blockmap line traverser

Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies

BBCode is OFF
Smilies are ON

Topic review
   

Expand view Topic review: Bug in blockmap line traverser

Re: Bug in blockmap line traverser

by ketmar » Wed Jan 01, 2020 7:00 am

i mean that i don't really care. the code is so trivial that i see no reasons to attach any license to it -- it is just a DDA people doing for decades. what i meant is that anybody is free to take it and use it however they like, there are totally no strings attached from my side. that is, slap any license on top of it -- i have zero objections.

Re: Bug in blockmap line traverser

by Graf Zahl » Wed Jan 01, 2020 6:49 am

In this case GPL would have been fine, the code it needs to interface with is original id/Raven code which is GPLv2+.

Re: Bug in blockmap line traverser

by ketmar » Wed Jan 01, 2020 6:20 am

ah, and by the way. i believe that such small snippet is not copyrightable at all, but just to play safe -- it is all mine original code, and i am putting it to Public Domain/WTFPL (whatever suits best). credits not required too.

Re: Bug in blockmap line traverser

by ketmar » Mon Dec 30, 2019 5:02 am

it can still miss the destination tile for long traces by one (that's why i am setting stepX/stepY to zero, and that's prolly why the same thing was done in the original code), but it shouldn't be the big problem anyway, because long traces should hit something long before the error accumulated. and if they didn't, chances are nobody will notice the miss anyway, for it being too far. ;-)

still, i am not sure why exactly it goes off-rails: it *may* be due to FP roundoff (see "#if 0" part, which fixes it in some cases). anyway, it fixed LOS in MAP31, but still didn't fixed my lightmap issues. yet i tried to check 9x9 blockmap tiles in lightmap tracer, and the artifacts are still there (yet smaller), so it seems that there is some more bugs in play.

yet i didn't noticed LOS anomalies yet, so it is at least not worser than the original code, and i think that it is way more readable (this is fairly standard code for "voxel raycasting", used almost everywhere, with added "pass through the corner" check).

p.s.: i am also clipping the line to blockmap area (that's why the code says that negative coords should not occur). dunno if current GZDoom code does this. original ZDoom code used in Vavoom seems to simply reject the whole trace if one of the endpoints is out of blockmap bounds, which is totally wrong (because the same code is used to find out which linedef was hit with hitscan attack).

Re: Bug in blockmap line traverser

by Graf Zahl » Mon Dec 30, 2019 4:44 am

I'll try this out myself when I find a bit of time.
I cannot really say I was ever too happy with the strange math in the original version.

Re: Bug in blockmap line traverser

by ketmar » Mon Dec 30, 2019 4:41 am

this code seems to work with k8vavoom so far. so i think i'll go with it for now, until somebody will come with something better.

Re: Bug in blockmap line traverser

by ketmar » Sat Dec 28, 2019 3:27 pm

here's DDA code i came up with. it seems to work, but i'd like to have another pair of eyes on it.
Spoiler:

Re: Bug in blockmap line traverser

by Graf Zahl » Sat Dec 28, 2019 11:11 am

ketmar wrote: as Graf said, that code is one of the most important engine functions. how did id managed to screw it up so badly?! (obvious rhetorical question ;-)
Don't ask me. Don't forget that the original did not even have the corner case and lost a lot more traces - to the point that they completely replaced their sight checking code.
Your bug is harmless by comparison - it can only trigger in constructed scenarios or right at map starts or when exiting a teleporter. As soon as the player moves the condition required to trigger it are no longer present.

Using this algorithm for something so far less fault tolerant as creating lightmaps is of course a bigger issue than a 1 in 10000 chance of a sight check not returning a proper result.

Re: Bug in blockmap line traverser

by ketmar » Sat Dec 28, 2019 11:00 am

>Obviously that needs to report the opposite.
actually, this will only reverse the problem. now some enemies will be blind sometimes. of course, the player will eventually move to the position where LOS check will succeed, and it is prolly better to have some enemies with very poor eyesight than enemies with superman-like ESP powers. ;-)

p.s.: also, the same code seems to be used to fill interceptions array with lines and things. while it is usually used on a short distance, and most of the time it never leaving the blockmap tile where the player is, it can cause troubles too.

as Graf said, that code is one of the most important engine functions. how did id managed to screw it up so badly?! (obvious rhetorical question ;-)

Re: Bug in blockmap line traverser

by Graf Zahl » Sat Dec 28, 2019 10:43 am

Well, that won't happen anymore with the next version. Ketmar's problems nonwithstanding, the far bigger screwup here was to let a lost check return successfully seeing the target. Obviously that needs to report the opposite.

Re: Bug in blockmap line traverser

by Enjay » Sat Dec 28, 2019 10:31 am

Indeed, starting GZDoom with gennodes 1 and warping to map 31 causes a cry of "schutzstaffel" to come through the wall to my right but without generating new nodes, the SS guy doesn't wake.

In the past, in several maps, I have noticed enemies being awake and wandering when I thought they had no good reason to be doing so. Whether it was due to this issue or something else, I can't say - but it could be related.

Re: Bug in blockmap line traverser

by ketmar » Sat Dec 28, 2019 9:54 am

(sighs) for k8vavoom it is quite essential. i tried to use this code to calculate lightmaps with raycasting, and got alot of light leaking artifacts. back then i thought that it was some floating point precision issue, and simply switched the tracer back to BSP-based. but now i see the real cause of the leaking light bug.

and k8vavoom can trigger lightmap recalculation when some geometry changed, or a light source was moved (like a lamp on a lift -- it goes down with the lift, and the engine should recalc static lightmaps), so using faster tracer is better there.

fun fact: this is part of Doom II MAP31. with the original MAP31, the bug is not there. but if you'll run any nodes builder on it (so nodes builder will recalc blockmap), the bug will appear. and it always appears in k8vavoom, because k8vavoom always rebuilds blockmap from scratch...

(wow, alot of "k8vavoom" search spam in this post! ;-)

Re: Bug in blockmap line traverser

by Graf Zahl » Sat Dec 28, 2019 9:47 am

Yes, I have had the same thought every time I looked at the code - but so far have managed to get around its issues without doing it each time it came up. This is one of the most crucial routines in the entire engine, nothing to toy around with.
Fortunately this issue requires some strict grid alignment to trigger so it's really rare and unlikely to happen when the player is moving around.

Re: Bug in blockmap line traverser

by ketmar » Sat Dec 28, 2019 9:42 am

it looks like this whole thing should be replaced with a proper DDA implementation. i'll try to do that in k8vavoom, and will back to you if i'll succeed.

p.s.: as a possible workaround, you can introduce a cvar to switch to a bsp-based caster, so people can choose between faster, but partially broken implementation, and slower, but better working one.

Re: Bug in blockmap line traverser

by Graf Zahl » Sat Dec 28, 2019 9:08 am

So, what happens is that the second iteration precisely hits the right border between two blocks. And nothing in there deals with this case.
The problem is, I cannot fix this particular edge case without making things worse.

For now I just did what I said earlier - return failure for the sight check.A true fix will require a lot more thinking.

Top