* WebSocket-based data transfer system
* Move resource downloads/uploads to the new transfer system
Should drastically increase the permitted practical size
* Transfer impl for Lidgren
* Async impl for receive stream
* Use unbounded channel for Lidgren
* Add metrics
* More comments
* Add serverside stream limit to avoid being a DoS vector
* Fix tests
* Oops forgot to actually implement sequence channels in NetMessage
* Doc comment for NetMessage.SequenceChannel
* Release notes
This means we don't have to JIT a bunch of UIs that you might not open, reducing memory usage and startup overhead.
One (1) UI is always JITed in another thread before prototype UIs are loaded, so as to warm up the JIT machinery. Said type is DropDownDebugConsole which always gets used anyways so there's no harm in it.
In total, these changes save more than a second of startup time for me.
* Added basic loading screen
* Make it look better!
* I forgor xD
* Fix test fails
* Add comment
* Removed unused import
* Only write to file if the number of sections changed
* Servers can now have their own settings
* Minor optionzation and rare colors
* Remove some of the cvars
* debug only loading messages
* Added a few more steps
* Only one section at a time
* nullable section name
* Lock out functions if finished
* Get rid of saving the ccvar
* Cleanup
* Forgot!
* A few tweaks
* Disable vsync
* remove colors
* remove outdated vsync functions
* Silly me xD
* What I get for trying to be clever... ;(
* Better seconds display
* Simplify drawing logic + it looks better
* Type does not need to be partial
* Make interface to expose to content
* Use correct define to gate showing debug info
Should be TOOLS instead of DEBUG
* Use appropriate exception type in BeginLoadingSection
* Fix exception when closing window during loading screen
Would try to stop the main loop before it exists.
* Rename CVars, put debug info behind CVar instead of conditional compilation.
* Add to RELEASE-NOTES.md
* Add UI scaling support
* Make ILoadingScreenManager fully internal
Didn't realize content can't touch it as it'd break the total amount of sections
* Don't re-enable vsync manually, GameController does it at the end of init
* Add command to show top load time usage.
* Improve verbosity of debug time tracking
More steps and some steps named better
---------
Co-authored-by: PJB3005 <pieterjan.briers+git@gmail.com>
* System font API
This is a new API that allows operating system fonts to be loaded by the engine and used by content.
Fonts are provided in a flat list exposing all the relevant metadata. They are loaded from disk with a Load call.
Initial implementation is only for Windows DirectWrite.
* Load system fonts as memory mapped files if possible.
This allows sharing the font file memory with other processes which is always good.
* Use ArrayPool to reduce char array allocations
* Disable verbose logging
* Implement system font support on Linux via Fontconfig
* Implement macOS support
* Add "FREEDESKTOP" define constant
This is basically LINUX || FREEBSD. Though FreeBSD currently gets detected as LINUX too. Oh well.
* Compile out Fontconfig and CoreText system font backends when not on those platforms
* Don't add Fontconfig package dep on Mac/Windows
* Allow disabling system font support via CVar
Cuz why not.
This is intended for content-side settings menus, so we can show users a "does this look correct" prompt after changing sensitive settings like graphics or UI, without risking an untimely config save *storing* broken CVar config.
Applies when vsync is not enabled.
Had to shuffle stuff around to GameController since it involves the game loop.
The implementation isn't great and undershoots the target FPS value (because the OS overshoots the desired sleep value). I tried using SDL_DelayPrecise too but this causes significantly increased CPU usage probably because it spinwaits and all that nonsense, so I decided against it.
I don't know why I bothered to do this. I just got the idea in my head. Kinda feels like a waste of time, but there's no point not committing it at this point.
* New HWID system prep
* Allow HWID to be disabled.
Both client and server can now request HWID to be disabled.
On the server via CVar, if disabled the client won't send it.
On the client via env var, if disabled it won't be sent to the client.
This involved moving legacy HWID to be sent in MsgEncryptionResponse instead of MsgLoginStart. This means the legacy HWID won't be available anymore if the connection isn't authenticated.
* Fix tests
* Fix another test
* Review
* Thanks Rider
This should significantly improve loading performance of large replays.
System can be controlled by replay.server_gc_size_threshold, which defaults to 50 MiB.
This is the engine-side of https://github.com/space-wizards/SS14.Launcher/issues/177
In profiles of RMC-14, encrypting network messages accounted for ~8% of main thread time. That's a lot.
Each NetChannel has an "encryption channel" which gets processed on the thread pool.
It is our suggestion for a long while to keep the TPS at 30 for servers. However the default was always 60.
I believe its better to have it as a default.
* Clamp audio tickrate
I am reasonably sure I saw a recommended 30TPS figure somewhere but I cannot find it again. At any rate I can't notice this but imagine it provides significant benefits for people on 144hz+ monitors.
* rn
---------
Co-authored-by: Pieter-Jan Briers <pieterjan.briers+git@gmail.com>
* Add VisibilityChanged virtual to Control
* Defer updating invisible OutputPanels on UIScale change
DebugConsole falls under this when not hidden, and it significantly improves perf of e.g. resizing the window when there's a lot of stuff in there.
* Avoid redundant UI Scale updates on window resize.
Window resizing can change the UI scale, due to the auto-scaling system. This system had multiple perf issues:
UI scale was set and propagated even if it didn't change (system disabled, not effective, etc). This was just wasted processing.
UI scale was updated for every window resize event. When the game is lagging (due to the aforementioned UI scale updates being expensive...) this means multiple window resize events in a single frame ALL cause a UI scale update, which is useless.
UI scale updates from resizing now avoid doing *nothing* and are deferred until later in the frame for natural batching.
* Reduce allocations/memory usage of various rich-text related things
Just allocate a buncha dictionaries what could possibly go wrong.
I kept to non-breaking-changes which means this couldn't as effective as it should be.
There's some truly repulsive stuff here. Ugh.
* Cap debug console content size.
It's a CVar.
OutputPanel has been switched to use a new RingBufferList datastructure to make removal of the oldest entry efficient.
---------
Co-authored-by: metalgearsloth <31366439+metalgearsloth@users.noreply.github.com>
* Perf: Improve replay playback responsiveness
- new CVAR ReplayMaxScrubTime
- There is a time budget when applying replay ticks updates of only 10 ms
- Ensure we don't apply checkpoints that move us backwards in time by accident
- Prevent double-lookup of checkpoints.
* Fix merge error
* Fix it again, but for real this time
---------
Co-authored-by: ElectroJr <leonsfriedrich@gmail.com>
* perf: Replays use less memory for checkpoints (#28052)
- Simple change of the CVars and some stats
- Based on a Lizard replay, checkpoints move from on average every 70 ticks to every 350.
* Set a minimum number of ticks that must pass between checkpoints
* Fix stat collection, split _checkpointMinInterval, more CheckpointState
* update release notes
Reports of problems, double checked with Grafana. Great.
I am going to do manual test runs of this system against Miros again if I end up looking to improve the situation.
Some players continue to have "stuck at connected" issues connecting to
most servers, but apparently this issue has become more prominent in the
last two weeks or so?
It is almost certainly an MTU problem because there are at least two
servers on the hub that run a lower default MTU, and these players had
no problem connecting to them. For one of these reporters, I actually
increased the MTU to 1000 and they could no longer connect, and could
connect again once it was lowered to 900.
It's not clear what recent changes, either to the codebase or to the
public Internet that have been exercising this MTU issue more. For those
experiencing MTU issues, it seems that connecting to a less full server
results in higher probability of success.
Nevertheless, bringing down the default MTU and then possibly enabling
MTU expansion in the future would make this game playable for a small
but not insignificant bit of players.
This callback enables code to update its metrics only when required. Needed this for SS14 since online admin count stats are not something I want to update on an "arbitrary" basis.
Tons of consideration and commenting for how this plays in with stuff like dotnet-counters. Added the metrics.update_interval CVar to act as a fallback for this event when dotnet-counters and such is in use.
They tend to get cut off (or well did on wizden before pjb changed it to this exact value bigger along with another patch). Before you got around 2ish hours in a replay before it stopped. I doupt most servers will reach 6ish hours before this takes effect. But those servers can increase this value of needed.
