Change to 180 TPS

[Kurtsley]

Addresses #997, #1216 so far.

The following is a list of what appears to have been fixed, many are very lightly tested and the changes could very easily have affected things in other parts of the game that I don't yet know about. This is just a running list to help me keep track of what has been done.

Battlescape

• Walking speed seems to be a bit faster, closer to the original.
• Explosive hazard type doesn't leave smoke behind anymore, it stayed around way too long. Was this a feature?
• Explosions now expand faster to more closely match the OG game.
• Explosions seem to be the correct radius now, although this needs more testing. I have only tried a couple items.

Cityscape

NA

Both

• Projectile speed has been increased, it seems much closer to the OG game. TICK_SCALE was set to 18 instead of 36 in this case. This has not been tested in cityscape, likely will cause issues somewhere.

Problems

• Rate of fire is now too fast. Should seperate speed from ROF if that is what is happening.

[FilmBoy84]

Looking good and thanks for working on this complex task

Regarding smoke and explosions - they should leave behind residual smoke as this is present in the OG

However, the smoke dissipates faster than that of a smoke grenade - which is likely affected by the tick counter and the value for dissipation

Regarding explosion speed, can you confirm the effects of the More-Options toggle for "Explosions damage instantly" still work correctly. When off, it should follow the OG behaviour with damage being applied after the explosion has reached maximal radius. When on, it should apply damage to a unit as soon as the expanding radius hits it - this was an optional fix to avoid a situation with the OG where a unit could run out of an explosion unscathed. By applying damage as soon as the expanding explosion hits the unit, they take damage under the normal rules for armour/pen immediately and cannot avoid being harmed.

[Kurtsley]

I reduced the length that the smoke from explosions sticks around.

I'm starting to think, as has been stated before, that most of the issues are related to values being set according to a 144hz monitor. The original developer set the tick rate to his monitor refresh rate of 144. This PR is attempting to set the tick rate to three times the game fraterate instead of the original 1:1 ratio that was used when writing this originally. It comes down to going through every single instance where the tick rate is being used in logic and deciding if it an animation or time issue. With the battle AI, most decisions are based on ticks per second. For example, the think interval is ticks per turn / 4. I would assume that the game wants the AI to make decisions every quarter second, so this value should not be touched. Grenade priming also works like this, it is based on time.

I think any value that works with the animation of sprites and is based on ticks may need to be looked into. So far, I haven't touched much beyond changing the tick multiplier and messing with the explosions. From what I can see, the explosion radius isn't a tick issue, dividing by 1.5 instead of 2 seems to fix it. I will need to look at damage next. The HE cannon does seem pretty weak, but the power is correct. The rate of fire is still correct, it just had to be divided by 5 instead of 4 to match the 36fps assumption.

TLDR: There will be no magic solution, basically everything needs to be tweaked to work with the new tick rate.

[FilmBoy84]

Many thanks for your continued work on this; agreed, navigating the mess of calcs linked to both TPS and FPS and correcting them (or separating them) has always been the scary side of this issue

Are we definitely sure on the Original Game being 18fps and 36tps or is that reversed at times (for example, in slow speed simulation)?

@JonnyH @Skin36 if you are able to advise on the exact values the original game assumes for each when your time allows, it would be really appreciated 🍻

Do we know who did the original work linking calcs to an assumed 144FPS? I can't seem to find on the tracker (so may be pre-github)

[JonnyH]

Git blame suggests the original 60->144 "change" was 76dda03

Before that the numbers I had there were 100% made up - it was still when stuff was being reverse engineered so I tweaked some things to "look about right" for the vehicle movement. Anything that might have been correct at that time is likely due to luck rather than intent :)

[JonnyH]

Once we have a consistent time base, we might "finally" decouple the frame rate and tick rate. But that's a separate change :)

I think the best way is to rework the main {(tick gamestate) (handle input and UI events) ( render)} loop with something more similar to timers - we have 2 events, the update tick, triggered every 1/180 seconds, and the imput/ui/render, which should probably be aligned to display refresh. The simplest way of doing this would be to have both on a thread, so they block and just queue up if the tick would have happened while the thread it busy. The render would then know it can access the current state without worrying about asynchronous access.

The input and UI updates would be coupled with the render, as interacting at a subframe latency probably doesn't actually make sense. While this might cause jitter of +- 1 frame's worth of ticks, apoc not being a super accuracy-based competitive twitch-reflex game likely means it doesn't really matter either.

Though we might need to think of what happens if the system cannot keep up - I don't want (for example) the render events to completely starve the queue, but an ordered event "queue" of those should correctly interleave so everything just goes slower when the system isn't able to keep up, which is probably fine for a single player game. Though might need to ensure the queue size is bounded.