Separating rate of fire from frames per second. There is no easy way to do this, is there?

Unity Engine
1

Since invoke is frame dependent, I take it you can’t depend on it for rapid fire in an FPS for rapidfire weapons, Huh?

I’m sure if weapon is below 10 rounds per second, it’ll be fine. But anything more than that i’m guessing I’ll need to count the time between frames, create the appropriate amount of rounds, and move them accordingly.

sounds like a pain, but I figured I’d stop here first and ask if there’s something more simple that I’m not seeing.

Any suggestions?

2

You’ll for sure have to offset them. A system that was able to spawn bullets immediately after x milliseconds (or as near as possible that it wouldn’t matter) would have to run off the main thread and somehow be guaranteed to be woken up as often as possible. That’d be a bigger mess than just spawning and offsetting.

I mean I believe this is it, right?

bulletTimer += Time.deltaTime;
while (bulletTimer > timeBetweenBullets) {
    bulletTimer -= timeBetweenBullets;
    Instantiate(bullet, spawnPos + (spawnForward * bulletSpeed * bulletTimer), spawnRot);
}
1 Like
3

Oh no, I just thought of something that gave me a lump in my throat.

not only do I have to do all that mess to ensure I got a proper fire rate, but I also have two move it in accordance with the player so that it doesn’t show up as chunks moving in a straight line.

and, I need to offset the audio.

That sounds like such a headache…

4

It’s not.

Just use a basic cooldown timer.

Fire the gun, add to the cooldown, subtract Time.deltaTime from cooldown, don’t fire until it is < zero.

As the audio interval approaches the frame rate you might want to do your own bullet fire sound mixing to ensure it is super-steady, if that matters to you. It’s trivial to do with this API:

https://docs.unity3d.com/ScriptReference/MonoBehaviour.OnAudioFilterRead.html

1 Like
5

I don’t think a basic timer is going to cut it since that’s also going to be frame dependent.

Im thinking I’ll need to have a value that each frame makes as many bullets as the delay can fit, then offset the bullets location and rotation to where the player would be in between frames AND how far they would move in the time before they should have been made and the next frame.

As for the audio I’ll need to read up on that.

I know next to nothing about audio.

6

This is getting on the right track, but I still need to toggle on the timer and reset it when the button is released, offset the bullets position and rotation according to the time stamp and delta time, and offset the audio.

All do-able. But a pain, and wanted to know if there was an easier way is all.

7

Newsflash: Unity is frame-dependent.

Here is some timing diagram help:

https://docs.unity3d.com/Manual/ExecutionOrder.html

Load up this project:

https://github.com/kurtdekker/proximity_buttons/blob/master/proximity_buttons/Assets/DemoTwinStickShooter/TwinStickPlayerController.cs

Go into the scene and jack the fire rate up as high as you want to test. I just tested it at 40 shots per second and it is solid. All the shooting timing logic is from line 120 to 137.

The only requirement to make it fire more than one shot per Update() call would be to change line 134 to a while (condition) statement instead of the if (condition) statement.

If you think their non-staggering is an issue, you can fix that too just by interpolating and advancing the shots. I don’t think the player would ever notice.

1 Like
8

lol i just put my logic in fixed update now fps doesnt matter with my setup!

9

lol fixed update isn’t frame-independent, it’s just a different framerate which is worse by default because it’s used for physics rofl

1 Like
10

I think that’s OP’s basic issue. Even if the firing-rate is below the framerate, unless it’s a divisor (like 10, 15 or 30 for 60fps) there will be an obvious pattern to the shots in sustained fire (with 40 shots/second at 60fps it will be “fire 2, skip 1”, which could give obvious gapes between pairs of shots).

The math to stagger isn’t that bad. Figure out how far the frame went past when the shot would have fired, giving an amount in seconds and a percent (the shot fired at 37% of this frame). Then go backwards (100-the percent) far along the player’s movement and rotation this frame. That gives the correct position&rotation. So we have to save this frame’s movement and rotation (which shouldn’t be too bad – do it when we compute it). Then give the shot extra movement based on the extra seconds. I’d set up a tester where the player runs and turns and spins fast, shooting all the while. When it looks decent, the math is correct (or, correct enough).