RMOD ToDo

[RaphaelIT7]

Since I want to make my own branch, I also got some ideas of things to finish.
Some of these, if not possibly all, changes may even end up in the upstream repo
(if you want all of them @dimhotepus pls tell me ^^)
I do want to make a game later, though I think changing up the engine first would be useful as a good foundation.
Though it'll probably never make it to Steam since there is no official license 😭 maybe one day...
I don't like being limited to server/client dlls with the normal sourcesdk :/

• Seamless changelevels
  If a map has a level transition, it could preload the next map and then teleport & swap out entities in one frame instead of needing a level transitition
  Wil require major changes since stuff like CollisionBSP can only have one exist at a time rn and other things like this.
  IDEA: What if we change things to allow multiple maps at once, like realms & an entity can be only inside one at a time but could easily be moved to another

• Improve SendProp code
  It has great potential for improvement, and I feel like the whole SendProp thing can be reworked.
  Idea: Every NetworkVar could be stored in a different class which then can be copied as snapshots instead of using a buffer, to make access and comparing easier & quicker for the whole CompareDelta code
  Idea concept:
  When initializing, we do some stuff, we figure out the total size for a SendTable, we also follow some principals:

• We sort the SendProp's by type into blocks (ints, floats, bools, vectors, and so on)

• We store them in their full size aligned to bytes (if we got 4 8bit ints, we can store each in 1 byte)

• Boolean are stored as bit flags (8 bools = 1 byte) - each bool sendprop has an extra var in which their bit is stored
  Once we got the full size allocated we allocate a memory block, and also update all SendProp offsets for their new positions

Version 1 (higher memory usage):
We store a snapshot normally for each entity - like how its currently done. Due to us not using the bit sizes we will use more memory now.

Version 2 (lower memory usage):
We store only the latest snapshot for an entity, this means were limited to compare deltas against an old version and the newest one, and we also don't know the old version, instead we store per snapshot a bitset where each bit will be 1 if a sendprop is non-zero or 0 if they are empty. We now only keep track if they changed or not - we don't keep track of their older values. At this point though we could also just not store their value in a snapshot at all and just grab them from the entity directly - though idk about CPU predicion / cache misses.

• Improve CServerGameEnts::CheckTransmit
  Already done that in HolyLib but I wanna redo it and port it over since the performance improvement was great but since HolyLib is a plugin for gmod and the SDK is not up to date there were weird issues.

• Reduce size of CBaseClient
  The class stores a scratch buffer inside itself, but it's unnecessary, as it's used only for SendSnapshot, where a static thread_local buffer is enough and will even save memory, as normally only 4-8 threads will actually use it and we avoid like 18MB of wasted memory if we have 128 players.
  Commit: bc8dc5e

• DirectX11
  It was already partially implemented in upstream though it doesn't seem to be fully finished
  Please add DirectX 11 support Source-Authors/Obsoletium#141
  Maybe trying to also do DXVK after that?

• Increase Map size & limits
  I think this could be great, especially when I reach the point of having the networking functional for 255+ players.

• Check out engine code to possibly switch player networking from byte to short to raise absolute player limit to 64k instead of 255

• Port back cell system for positions from CS:GO
  Precision will definetly become an issue, even for rendering.
  Maybe we could make rendering positions and such relative to the eye position instead of world?
  Would be utterly painful but probably have great results when having huge maps (or we slap doubles onto it but thats weh)
  Related:
  Source-Authors@442d776
  Source-Authors@cf876a6
  Source-Authors@83cbeb2

• Change curtime to a double and reduce usage
  I don't see why having curtime be a float serverside is even nessesary, clientside okay but serverside?
  Perferably it would be removed completely as even if its a double at one point precision will suffer.
  Would need major reworks so that things work based off ticks, I think removing it completely is impossible but reducing usage heavily is, only animations would need it as a double.
  I guess the best idea is: Switch it over to a double & while changing things we also reduce usage of it when possible
  Entire branch related to changing to a double: https://github.com/RaphaelIT7/obsolete-source-engine/commits/gmod-curtime-double

• Raise net channel limits & improve them
  Their too slow, too limited.
  Related: Source-Authors@5a2907c

• Implement Embree for VRAD
  It was done for the Raven VRAD compiler and I think it'll probably be a great improvement since VRAD does a lot of traces

• Allow one to replace the AI network at runtime
  Useful when modifying it at runtime, though currently it loves to crash.
  Fixed in the past in: Source-Authors@6438414

• Fix up SourceVR
  It's not really functional in it's current state though I did start in the past to fix it up
  Related commit: Never pushed these local changes 😭

• Native Join Queue
  I think the default server browser of sending requests & connecting only when a slot is free (only for it to be taken by a faster client) is annoying, it should be easy to implement a proper queue.

• Remove assumption of having playerIndex == entIndex-1
  I find this a bit limiting, the player index should not be bound to the ent index.
  Instead, when a client is given an entity, the clients index can be stored on the entity, making it an easy bind and removing the necessity for code to rely on the assumption for the playerIndex.

• Improve the filesystem
  There are many ways to improve it, for example with a cache, different search passes and so on.
  I think for this though, as I don't think many search paths will be added, I'd focus on a cache for materials, and just the split search passes which should work good enouth.

• • Model material cache
    Currently, to load a model material it will search through every model path it has to find it, instead we could do that once and save the path a given material was found at, I think it would generally be easier if just the full path for materials are stored directly instead of these split ones though with changing content they may change so having it as a seperate cache is a more flexible approach.
    This could also be written into the mdl itself by making our own model version or flag though this would only work on models compiled with our tools and to the above mention for flexibility, it would probably be fine as long as a model is recompiled when content is changed.
• • Split search passes
    By default it tries to open a file using CWin32ReadOnly(or such, forgot the name) and then using fopen, we can split a search into two passes first doing just windows, then only fopen, this would be faster as Windows would mostly open files when found, so the calls to fopen would be unessesary/saved - in the worst case, performance remains the same - in the best case, it ends up twice as fast (when the Windows part succeeds)
    Related commit: [filesystem] optimize file search by splitting it into two passes Source-Authors/Obsoletium#113

• More stuff in parallel

• • Model scaling
• • Stringtable setup/precaching - Source-Authors@c840dea
• • PrecacheLighting - Source-Authors@41f11a6

Other commits to bring over (ToDo):

• b20316e
• 31e4296
• 429b3ea
• 72f3797
• cdb1639
• 3c98645 - to not make the game unresponsive while loading
• b9e4bc9
• 0315360
• 429b3ea
• 2e0bfa3 - from sigsegv but huge improvement

[Grocel]

Good luck with this.