First of all, I mean this in general. Within vanilla Doom, ZDoom, other source ports, etc.
If I were creating a custom projectile, how fast could it travel before I could run into issue with it? Any sort of problem, clipping through walls, loss of accuracy... I don't know the inner workings of Doom so depending on how projectiles work there are a lot of ways it could go wrong.
I'm thinking along the lines of having all weapons fire projectiles, so even a hitscan weapon that shoots bullets would shoot a projectile, just a really really fast one.
How fast can a projectile fly?
-
Arctangent
- Posts: 1235
- Joined: Thu Nov 06, 2014 1:53 pm
- Contact:
Re: How fast can a projectile fly?
About 60 for a large, regular projectile - somewhere around that point and you get weirdness with vertical movement.
However, as a general rule of thumb, a projectile shouldn't move much faster than twice its radius. At that point, it becomes possible for the "steps" a projectile takes to have spaces in-between each other, allowing for the projectile to fly right through things. A small amount of this space doesn't matter all too much for actor-on-actor collisions, since other actors generally won't have hitboxes small enough to fit inside that space, and I think it might not matter at all for actor-on-line collisions ( though don't quote me on that ), but too much of a disparity can cause issues.
That all said, there's a [wiki]FastProjectile[/wiki] class that actors can inherit from that eliminates these issues in most, if not all circumstances. FastProjectiles don't come with all of the features of normal projectiles - for example, they can't bounce last I checked - but if you're just replacing hitscans with really fast projectiles, this shouldn't be much of an issue.
However, as a general rule of thumb, a projectile shouldn't move much faster than twice its radius. At that point, it becomes possible for the "steps" a projectile takes to have spaces in-between each other, allowing for the projectile to fly right through things. A small amount of this space doesn't matter all too much for actor-on-actor collisions, since other actors generally won't have hitboxes small enough to fit inside that space, and I think it might not matter at all for actor-on-line collisions ( though don't quote me on that ), but too much of a disparity can cause issues.
That all said, there's a [wiki]FastProjectile[/wiki] class that actors can inherit from that eliminates these issues in most, if not all circumstances. FastProjectiles don't come with all of the features of normal projectiles - for example, they can't bounce last I checked - but if you're just replacing hitscans with really fast projectiles, this shouldn't be much of an issue.
Re: How fast can a projectile fly?
Ah, see, the "steps" thing is exactly what I was worried might happen.
-
Matt
- Posts: 9696
- Joined: Sun Jan 04, 2004 5:37 pm
- Preferred Pronouns: They/Them
- Operating System Version (Optional): Debian Bullseye
- Location: Gotham City SAR, Wyld-Lands of the Lotus People, Dominionist PetroConfederacy of Saudi Canadia
- Contact:
Re: How fast can a projectile fly?
FastProjectiles are theoretically unlimited since they'll do as many collision checks as are required every tic to fill in the gaps, but they can be a performance killer with lots of very small, very fast projectiles (e.g., real-life bullets which are smaller than 1 DU and go at over a thousand DUs per tic) which is what this is for.
For fancy physics stuff, you could try adding them manually to a FastProjectile-derived class, since virtually the entire FastProjectile's movement code is editable in ZScript. (Gravity, for instance, can be added by calling "vel.z-=GetGravity();" every tic.)
For fancy physics stuff, you could try adding them manually to a FastProjectile-derived class, since virtually the entire FastProjectile's movement code is editable in ZScript. (Gravity, for instance, can be added by calling "vel.z-=GetGravity();" every tic.)