Les choses étranges du code de Minecraft

Mokona78

Peut-être, mais alors juste peut-être, que ce sont des annotations plutôt destinées à des analyseurs statiques, qui peuvent lever des warnings avant même la compilation si l’analyse montre qu’il y a des null potentiels dans les paramètres ou les valeurs de retours.

SCAREX

Non, ce sont des annotations qui indiquent que les paramètres de fonctions ne doivent pas êtres nuls (par défaut). Donc si tu essaies de mettre null dans une fonction ton IDE te dira que c’est pas possible (il me semble que c’est le but)

Mokona78

Donc de l’analyse statique

C’est le nom générique des analyseurs qui tentent de faire des vérifications sur un programme au niveau du code source (ça peut aller bien plus loin que ça).

jglrxavpok

@‘Mokona78’:

Peut-être, mais alors juste peut-être, que ce sont des annotations plutôt destinées à des analyseurs statiques, qui peuvent lever des warnings avant même la compilation si l’analyse montre qu’il y a des null potentiels dans les paramètres ou les valeurs de retours.

J’en suis sûr, c’est exactement ça.

jglrxavpok

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>

elias54

Assez étrange en effet.

AymericRed

Oui c’est bizarre… Je pense que les mappings y sont pour quelque chose.

robin4002

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.

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.

AymericRed

Et comment qu’un double pourrait ne pas être un nombre ?

Mokona78

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.

AymericRed

Ah et ben tu viens de m’apprendre quelque chose, bizarre qu’on puisse deviser par zéro quand c’est un flottant.

jglrxavpok

@‘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))

Mokona78

Ç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)

SCAREX

Ouai mais du coup ça renvoi une erreur