b0c83af092
Complete replacement of the tactical-shooter project with the netfox-cs-sample (MIT) — a CS 1.6 inspired multiplayer FPS built with Godot 4 and netfox. ## What's new - Full CS-style gameplay: teams (T/CT), rounds, economy, buy menu - 6 weapons: Knife, Glock, USP, AK-47, M4A1, AWP - Bomb plant/defuse with 2 bombsites - Flashbang & smoke grenades - Proper netfox rollback netcode at 64 tick - Network popup UI for host/join - HUD, crosshair, round timer, scoreboard - All netfox singletons registered as autoloads (works in exported builds) ## Architecture - Listen-server (host from client, no dedicated server binary) - Multiplayer-fps game lives at examples/multiplayer-fps/ - Netfox addons registered as autoloads for exported build compat - Godot 4.7 with Forward+ renderer ## Removed - Old headless-server architecture (client_main, server_main, player.gd, etc.) - Custom netfox bootstrap with ENet fallback - Old ChaffGames FPS template (2,420 lines, 844 KB) - SimulationServer GDExtension stub - Godot-jolt physics (netfox sample uses default Godot physics) - Duplicate weapon_data.gd, anti_cheat.gd, round_manager.gd, etc. - Server browser API Python venv (87 MB) - test_range map and modular assets ## Preserved - Git history - Server config at config/default_server_config.cfg - Windows export preset - Build directory (gitignored) Co-authored-by: naxIO <naxIO@users.noreply.github.com>
40 lines
1.6 KiB
Markdown
40 lines
1.6 KiB
Markdown
# Interpolation caveats
|
|
|
|
While netfox runs netcode at a fixed rate, the game may render frames at a
|
|
higher, varying framerate. Interpolation smooths out the difference between
|
|
tickrate and framerate, when using [TickInterpolator].
|
|
|
|
Below are some aspects that may catch users off guard.
|
|
|
|
### Interpolate only visuals
|
|
|
|
A node's state may consist of multiple properties, some of which affect its
|
|
appearance ( e.g. position, rotation, scale ), some are only relevant to the
|
|
simulation - e.g. most objects look the same regardless of their velocity, even
|
|
though it's important for simulating their behavior.
|
|
|
|
Since interpolation matters only for the game's visuals, it's enough to
|
|
interpolate only the properties that affect the game's visuals.
|
|
|
|
### Rotation vs. Quaternion vs. Transform
|
|
|
|
Interpolating `rotation` may lead to glitchy results when an object makes a
|
|
full turn. This stems from the way `rotation` works - it represents the amount
|
|
of rotation per axis, in Euler angles. Using Euler angles to interpolate
|
|
rotations doesn't work well, as they can end up interpolating from -180 degrees
|
|
to +180 numerically. The expected behavior would be to go from -180 to +180
|
|
instantly, since they represent the same rotation. The same thing happens in
|
|
animation software as well, when trying to interpolate with Euler angles.
|
|
|
|
What to do instead:
|
|
|
|
* Interpolate the whole `transform`
|
|
* Interpolate `quaternion` - represents rotation, but better suited to
|
|
interpolation
|
|
|
|
For more, see Godot docs on [3D transforms]
|
|
|
|
[TickInterpolator]: ../nodes/tick-interpolator.md
|
|
[3D transforms]: https://docs.godotengine.org/en/stable/tutorials/3d/using_transforms.html
|
|
|