Les choses étranges du code de Minecraft
-
Dans Particle.java:
public void moveEntity(double x, double y, double z) { double d0 = y; if (this.field_190017_n) { List <axisalignedbb>list = this.worldObj.getCollisionBoxes((Entity)null, this.getEntityBoundingBox().addCoord(x, y, z)); for (AxisAlignedBB axisalignedbb : list) { y = axisalignedbb.calculateYOffset(this.getEntityBoundingBox(), y); } this.setEntityBoundingBox(this.getEntityBoundingBox().offset(0.0D, y, 0.0D)); for (AxisAlignedBB axisalignedbb1 : list) { x = axisalignedbb1.calculateXOffset(this.getEntityBoundingBox(), x); } this.setEntityBoundingBox(this.getEntityBoundingBox().offset(x, 0.0D, 0.0D)); for (AxisAlignedBB axisalignedbb2 : list) { z = axisalignedbb2.calculateZOffset(this.getEntityBoundingBox(), z); } this.setEntityBoundingBox(this.getEntityBoundingBox().offset(0.0D, 0.0D, z)); } else { this.setEntityBoundingBox(this.getEntityBoundingBox().offset(x, y, z)); } this.resetPositionToBB(); this.isCollided = y != y && d0 < 0.0D; if (x != x) { this.motionX = 0.0D; } if (z != z) { this.motionZ = 0.0D; } }this.isCollided = y != y && d0 < 0.0D; if (x != x) { this.motionX = 0.0D; } if (z != z) { this.motionZ = 0.0D; }Celle-là, je l’avais jamais vu!</axisalignedbb>
-
Assez étrange en effet.
-
Oui c’est bizarre… Je pense que les mappings y sont pour quelque chose.
-
Peut-être une erreur de décompilation et de mappage oui.
Mais je ne vois pas d’autres variables dans la fonction donc ce n’est pas certain. Et puis si le code ne fait pas la même chose que celui de minecraft, on devrait constater une anomalie sur le déplacement des entités en ayant forge, or ce n’est pas le cas. -
C’est du code tout à fait valable. C’est du code de protection contre la valeur NaN.
Lorsqu’un flottant se retrouve à la valeur NaN (Not a Number), un moyen de réinitialiser la variable est de vérifier si elle est différente d’elle-même. En effet, par définition, NaN est différent de tous les autres nombres, y compris de NaN.
-
Et comment qu’un double pourrait ne pas être un nombre ?
-
Quand le résultat d’une opération ne donne pas un nombre.
Avec des entiers, 1/0 ou 0/0 vont envoyer une exception ; en flottant, le résultat est défini, 1.0/0.0 donne +inf (infinity). -1.0/0.0 donne -inf. Et 0.0/0.0 donne… NaN.
De même, le résultat de Math.sqrt() avec un nombre flottant négatif NaN, puisque la racine carrée d’un nombre négatif n’est pas défini pour les réels.
-
Ah et ben tu viens de m’apprendre quelque chose, bizarre qu’on puisse deviser par zéro quand c’est un flottant.
-
@‘Mokona78’:
C’est du code tout à fait valable. C’est du code de protection contre la valeur NaN.
Lorsqu’un flottant se retrouve à la valeur NaN (Not a Number), un moyen de réinitialiser la variable est de vérifier si elle est différente d’elle-même. En effet, par définition, NaN est différent de tous les autres nombres, y compris de NaN.
Tu m’as appris quelque chose!
J’aurais plutôt penser à ça qui est moins ambigu:if(!Float.isNaN(x)) -
Ça serait bien plus lisible en effet.
Après, si c’est du code décompilé, il est possible que le compilateur est remplacé l’appel à IsNaN() par son implémentation en ligne et qu’à la décompilation, on se retrouve avec ça. Je ne sais pas assez comment se comporte le compilateur Java.
Ou bien, c’est quelqu’un qui a l’habitude de cette formulation dans d’autres langages qui n’ont pas de fonction IsNaN().
(on pourrait objecter que x != x est plus rapide qu’un appel de fonction, mais je pense que le JIT se charge de l’optimisation lors du premier appel… si le compilateur ne s’en ai déjà pas chargé. Là encore, ça sort de mon champ de connaissance)
-
Ouai mais du coup ça renvoi une erreur