Ruby ?? - Page 4

Pour un nombre signé, ça change.
(-1)>>4 == -1
(-1)/16 == 0

"Même" moi je le savais.
Arrêtez de chercher KK... c'est pueril. (sans aucune ironie)

Laissez-moi rouvrir cette horreur..... ok. Alors non pourtant j'ai en partie des entiers signés (pour la vitesse entre autres, normal) et en partie des entiers non signés. M'enfin ça vient peut être de là, je sais pas. Par contre je remarque que je codais quand même sacrément horriblement à l'époque

//Retourne si oui ou non la coordonnée spécifiée est dans la zone décompressée
int coordValide(int coordX, int coordY)     {
   if (coordX>=((advMapOffsetX+3)<<9) || coordY>=((advMapOffsetY+3)<<9) || coordX<((advMapOffsetX-1)<<9) || coordY<((advMapOffsetY-1)<<9))
      return 0;
   else
      return 1;
}

D'ailleurs dans ce cas ça me ferait chier d'utiliser des entiers non signés parce que les coordonnées pourraient être négatives (le test échouera presque toujours dans ce cas si je me souviens bien). Alors oui je pourrais utiliser le fait qu'un nombre négatif interprété en non signé sera très grand donc le test échouera de toute façon mais je trouve ça moche

Y'a pas à dire, le dévellopement Nspire va bon train

Brunni (./88) :
Si je remplace les & 15 du moteur de collisions de mon Sonic par des % 16 ou pire les >> 4 par des / 16 je peux te jurer qu'il tourne *carrément* moins bien niveau vitesse, même si le résultat est exactement le même visuellement parce que je ne tombe jamais dans les cas limite... Y'a des fois où t'as pas le choix...

On parlait de x8 par de /16.

Ok effectivement concernant le x8 c'est une connerie, j'ai rien dit.

Sasume (./84) :
-> D'où l'intérêt de laisser le compilateur réaliser lui-même les bonnes optimisations (puisque tu te trompes et que ton code est moins lisible)

Je parle bien des zones critiques où on fait des opérations bas niveau hein, comme par exemple plotter un pixel sur le framebuffer, le genre de trucs appelé des milliers de fois.
J'aime pas mélanger les trucs, par exemple si tu dois faire des multiplications et des divisions et que tu dois utiliser *8 dans un sens et >>3 dans l'autre parce que sinon tu perds 160 cycles, c'est pas plus compréhensible que <<3 et >>3...

Brunni (./96) :
tu dois utiliser *8 dans un sens et >>3 dans l'autre parce que sinon tu perds 160 cycles

Bah non, pour un entier non signé « / 8 » devrait être remplacé par « >> 3 ». Mais c'est vrai que pour la manipulation de mots de bits, je préfère la notation avec les « << » et « >> » qui a plus de sens.

J'ai jamais appris à utiliser strictement les bons types signés ou non, donc ça vient peut être de là. Sur TI je faisais très attention à la taille parce que les opérations sont très très lentes sur du 32 bits par exemple, mais sinon je les mets presque toujours signés parce que ça semble naturel dès qu'on interface avec l'utilisateur. Ca me semble trop space de se dire qu'il n'y a "rien" avant 0. En C (en C++ on devrait utiliser ces d'exceptions) je retourne souvent -1 pour signaler une erreur par exemple. Même mes variables de boucle sont signées alors que c'est vrai que ça n'a pas de sens. En plus t'as des milliers de warnings dès que tu commences à mélanger (et les casts rendent le tout illisible). En plus je me rappelle qu'avec mon compilo en mettant unsigned c'est parfois plus lent, va savoir pourquoi :/