Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  
VGA

Projectiles not properly connecting

Recommended Posts

http://wikisend.com/download/557324/TestRange.wad

I was testing something and I realised that some of the baron projectiles get "swallen up" by the walls, they are not connecting. The explosion isn't visible and there is no sound played, that's what I mean. They disappear into the wall.

It may take 10-20 attacks for it to happen. I don't think this is related to this tiny test map, this is a vanilla bug? It does happen on Chocolate Doom.

Share this post


Link to post
VGA said:

http://wikisend.com/download/557324/TestRange.wad

I was testing something and I realised that some of the baron projectiles get "swallen up" by the walls, they are not connecting. The explosion isn't visible and there is no sound played, that's what I mean. They disappear into the wall.

It may take 10-20 attacks for it to happen. I don't think this is related to this tiny test map, this is a vanilla bug? It does happen on Chocolate Doom.

Not sure if this is the same issue or not, but missiles can explode "inside" thick walls, on the wrong side of the wall, or inside a column. If the missile's speed is fast enough that, during frame X, collision detection fails to detect a collision, but in frame X+1, the missile has already travelled a distance where the center of the missile is inside the wall, the missile impact can occur inside the wall.

Once inside, the engine looks for a wall that *might* impact with the missile. If there's more than one wall that comes together in that block, Doom chooses the first wall that the missile may have it. The engine doesn't even decide which side was hit accurately.

If the missile's center is inside the wall, the sprite might get clipped away. Also the sound might get blocked.

This is a big dilemma for engines that draw wall splats. A typical fix is to send an invisible trace backwards toward the missile's source, then turn around and do a real intercept test, to determine location and side of impact. It might even have to do more than one impact test, to paint portions of the splat on either edge of a wall intersection.

Share this post


Link to post

Makes sense. Also, I can see the problem more clearly if I am on that platfrom and shoot the grey low wall with the plasma gun. Most projectiles explode on the high ledge or reach inside the block.

ZDoom has fixed this. I see it happening in all other ports I tried though. Hmmmm.

Share this post


Link to post
VGA said:

Makes sense. Also, I can see the problem more clearly if I am on that platfrom and shoot the grey low wall with the plasma gun. Most projectiles explode on the high ledge or reach inside the block.

ZDoom has fixed this. I see it happening in all other ports I tried though. Hmmmm.

It's the classic speed vs. accuracy thing. Vanilla chose speed (arguably, rightly-so), for the sake of 386/486's. ZDoom chooses accuracy (arguably, rightly-so), for modern computers 100x as powerful. And, of course, other ports concern themselves with demo compatibility, which this change undoubtedly affects.

Share this post


Link to post

If a projectile's speed is greater than its diameter, it can clip through solid walls, like Mancubus fireballs do and even Baron fireballs can do occasionally.

Share this post


Link to post
VGA said:

ZDoom has fixed this. I see it happening in all other ports I tried though. Hmmmm.



Nothing 'hmmmm' about it. This is a pretty fundamental issue in the engine that can affect lots of things, not the least important of which is wallrunning.

To make it short, the original code is pretty spotty in deciding when to split a move that's longer than an actor's diameter into two - and of course it never even bothers doing more steps if necessary. Any port which wants to preserve this has little choice, and as you can see in ZDoom, even though it provides a wallrunning compatibility option, it doesn't really work that well.

So this is the kind of fix that's very hard to apply, if you also want to preserve the original behavior, broken as it may be.

@kb1: In this case it's actually not just speed vs. accuracy, but simply some badly written code that failed to check the conditions properly.

Share this post


Link to post

It's always fascinating, when modeling physics systems, that there's always a maximum speed-timestep product that's kind of a "universal constant" of your micro-universe, and Doom is no exception. If you exceed this product, e.g. by having too great a speed or too coarse a timestep, then the physics in your micro-universe will all break up, kinda like a "light speed" constant that you must not exceed, otherwise the very "glue" of your microcosm's' reality ceases to function.

Share this post


Link to post

This bug is bothering me a lot when working with linedef portals in Eternity, and is even more frequent when using moving portals, happening even with regular imp fireballs. I wish the only linked portals in Eternity were sector-based, they are just sufficient to create 3D levels...

Share this post


Link to post
Graf Zahl said:

...@kb1: In this case it's actually not just speed vs. accuracy, but simply some badly written code that failed to check the conditions properly.

Nah, I'm going to have to stick to my terms. I can't call the code "badly-written", given Carmack's time-frame, and how well the original code actually performs. If it were badly-written, we'd all be pissed off every time we played. As it stands, there's an occasional glitch, unless you isolate a test case.

We have the luxury to tear apart every routine, set up extensive analysis, profile against multiple setups, etc. Carmack had time to write it once, shoot a couple of fireballs at an imp, and move on to the next dilemma. (That's an exaggeration, but, yeah, Doom was written in crunch-mode, for sure.).

It's opinion, of course, but I tend to feel that this and other questionable things were written to work reasonably well, execute quickly, and be written quickly, to get the product out the door.

And, yeah, it's bad, but that just seems a bit harsh for my judgement. Now, that's not to say that, yes, it might operate poorly on things like printz's portals. What does ZDoom do to fix the issue? Move in smaller steps the faster the missile? Intercept calculation?

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
Sign in to follow this  
×