I don't think that " + (double)f3" in the line marked with " // <-- What?" is intentional. This should be removed. Ingame this leads to slightly wrong camera distances in the 3rd person views (front and back), if the camera hits an obstacle.
/*
* Decompiled with CFR 0.146.
*/
package net.minecraft.client;
// ...
public class Camera {
// ...
// Camera distance for 3rd persion view
private double getMaxZoom(double d /* = 4.0 */ ) {
// Generate 3 bit combinations, corresponding to 8 cube edges
for (int i = 0; i < 8; ++i) {
double d2;
BlockHitResult blockHitResult;
Vec3 vec3;
// Use bits to calculate cube edge offset
float f = (i & 1) * 2 - 1;
float f2 = (i >> 1 & 1) * 2 - 1;
float f3 = (i >> 2 & 1) * 2 - 1;
// Apply offset
Vec3 vec32 = this.position.add(f *= 0.1f, f2 *= 0.1f, f3 *= 0.1f);
// Ray trace vec32 -> vec32 - forwards * d (I guess that's what it should be)
if (((HitResult)(blockHitResult = this.level.clip(new ClipContext(vec32, vec3 = new Vec3(
this.position.x - (double)this.forwards.x() * d + (double)f + (double)f3, // <-- What?
this.position.y - (double)this.forwards.y() * d + (double)f2,
this.position.z - (double)this.forwards.z() * d + (double)f3
), ClipContext.Block.VISUAL, ClipContext.Fluid.NONE, this.entity)))).getType() == HitResult.Type.MISS
|| !((d2 = blockHitResult.getLocation().distanceTo(this.position)) < d)) continue;
d = d2; // Find smallest distance
}
return d;
}
// ...
}
Attachments
Comments 5
3rd person camera distance is slightly wrong calculated. It's probably not noticeable. Should still be fixed imo.
Literally all of those floats are converted to doubles, doubled are also more precise; this looks very much intentional.
Unless an issue is actually observable in-game, it is not accepted here. "Wrongly calculated" doesn't cut it, actual difference between the fixed and unfixed behavior needs to be established.
I'm not at all talking about the double cast, the whole expression " + (double)f3" should be removed, because it's wrong.
Does this have any impact on the game?