1 1
That sounds messy That sounds messy That sounds messy 
Snap() methods implementation instead of many
if(SnappingClientVersion >= VERSION_DDNET_MULTI_LASER) {}
else {}
like here: https://github.com/ddnet/ddnet/pull/5886/files#diff-df2ce2969f31b753247baa59b8cc1c53ee6a8d1ebb3e84867dff031d72e1487bR84-R108
we can have some SnapLaserObject(const SSnapContext &Context, int SnapID, const vec2 &To, const vec2 &From, int StartTick, int Owner, int Type) // I've put sixup / ClientVersion into the Context
This SnapLaserObject() can then snap CNetObj_Laser or protocol7::CNetObj_Laser or CNetObj_DDNetLaser or whatever is better for this context (client version).
This way we can have less branches in the high level game code and have protocol detail in one place (instead of spreading the protocol through all CEntities and other high level classes).
I see that this approach would have issues with 0.7 in cases of a data member moved from one object to another (ClientInfo ) but it is still doable and will cleanup the game code from protocol details used here/there/everywhere.
Also there are cases in which we try to reduce the server load by fetching/calculating the data only for the clients which are able to use it. It is also solvable via the Context — if the protocol API implementation will fetch some extra data for some clients it still would be a simpler code. 
Snap() implementations from the protocol. We can remove protocol7 but we'll have various versions of DDNet client. We'd better hide the protocol implementation details from the high level game code. m_aCore[2]
in some .cpp:
m_aCore[CurTickMode] = ...
m_aCore[PrevTickMode] = ... (e.g. if one must access the previous state) (note here prev: is basically the current for client, while cur is the prediction, on server both would be the same, so u basically only access a core)
I don't think a third core is needed (smth like prev core), this usually only creates delays. If we want smoother interpolation for smth like cursor movement we can think about increasing the package count for such things, the way its handled rn is really weird (tsfreddie and me talked about it long before).
If the server sends fewer cores/snapshots the client should simply rely on its prediction cores (swap the current prediction core with the current simulation tick).
Smooth prediction should uses the 2 cores to calculate whatever state is wanted. and it should only do it when its needed, and that's usually at rendering. 1
Amount at the very last step, even if it breaks math.
But we want to transform into a different resolution anyway.. in the resolution of Amount:
x * y = x * y | / y
(x * y) / y = x | * x
(x * y) * (x / y) = x^2 | sqrt
sqrt(x * y) * sqrt(x / y) = x
At this point it's clear where our journey ends xd
x / y is the Aspect ratio.. The function takes the Aspect ratio as parameter
so our new x is:
x = sqrt(Amount) * sqrt(AspectRatio)
and y is
y = sqrt(Amount) / sqrt(AspectRatio)
now look at the original formular
float f = sqrtf(Amount) / sqrtf(Aspect);
*w = f * Aspect;
*h = f;
its the exact same. f is basically = y
and we go from y to x by multipling AspectRatio
And AspectRatio / sqrt(AspectRatio) = sqrt(AspectRatio)
You can think about this geometrically too, but I cannot explain it.
Draw it on your paper or watch some videos about geometrical mean of sqrt.
About WMax and HMax. Basically disallow zooming.
And yes / 32 is to get the tile count at normal zoom 
cl_showkillmessages 0 
