D'où sortent tous ces chiffres ?
De ma poche
Ou plutôt, des chiffres que tu donnes dans ton propre script.
Les cases 0,10,20,30,40,50,60,70 sont les cases de la première ligne.
On peut numéroter 0 à 7 les 8 colonnes. Le numéro de la colonne s'obtient en divisant le numéro de case par 10.
D'une colonne à l'autre, tu décales l'offset en X de 0.125, c'est à dire 1/8, ce qui est logique.
En regardant toujours tes valeurs, on voit que par exemple, pour la colonne 4, l'offset vaut 0.0625, c'est à dire 1/16. A partir de là, si on remonte de 4 colonnes, on a
pour la colonne 0 : offsetX = 1/16-4/8 = -7/16 = -0.4375
Et, puisqu'on rajoute 1/8 = 2/16 à chaque nouvelle colonne, on a
pour une colonne quelconque : offsetX = (-7+2*numero_de_colonne)/16
Ensuite, il y a l'offset en Y.
En regardant toujours tes valeurs, on voit que pour ta première ligne (il est plus commode de l'appeler ligne numéro 0), l'offset en Y ne change pas, et vaut +0.4375 = +7/16
J'imagine que dans ce cas là, tu diminues l'offset de 1/8 à chaque changement de ligne, dans l'autre sens cette fois-ci, c'est à dire en ajoutant -1/8 à chaque changement de ligne.
D'où offsetY = (+7-2*numero_de_ligne)/16
Pour revenir sur les problèmes de division, euclidienne ou décimale, reste etc, et ajouter quelques compléments a ce qu'explique le chat de gouttière
plus haut :
Il y a deux façons de diviser.
Si tu as un paquet de farine de 1.4 kg, à partager entre 4 personnes, tu pourras toujours faire 4 paquets de masse identique. Appelons ça une division décimale.
Si tu as 14 pommes à partage entre 4 personnes, et pas de couteau pour les découper, tu donneras 3 pommes à chacun, et il te restera 2 pommes.
Ca s'appelle une division euclidienne. On ne considère que des nombres entiers, et comme en général ça ne tombe pas pile, il y a un reste.
On a besoin d'extraire le numéro de la colonne et le numéro de la ligne, pour un numéro de case donné.
Les cases 20,21,22,23... , sont toutes sur la ligne numéro 2 (si on commence à numéroter par 0 la première ligne).
La division euclidienne par 10 permet facilement d'obtenir alors le numéro de la ligne.
Et le reste de la division par 10 donne le numéro de la colonne.
On pourrait l'obtenir par :
integer icolonne = case/10;
integer iligne = case - (10*icolonne);
Mais puisque qu'on met à notre disposition une fonction qui nous donne le reste directement :
integer iligne = case%10;
Ce qui complique un peu les choses, c'est que le langage permet de faire au choix des divisions euclidiennes, ou des divisions décimales, mais que le signe utilisé est "/" dans les deux cas.
Quand je divise 10 par 3, j'obtiens 3.33333333 moi ...
On divise un entier par un autre entier. Le résultat est un entier, par la division euclidienne :
a = 3
On divise toujours un entier par un entier. Le compilateur interprète le signe "/" comme une division euclidienne. La variable a étant déclarée comme un nombre décimal, on obtient un entier, converti en décimal :
a = 3.0000
Le dividende ou le diviseur (ou les deux) étant un nombre décimal, le compilateur interprète le "/" comme une division décimale. Le résultat est :
a = 3.33333
Allez, pour finir, et puisqu'on parlait du loup
Allez le matou je suis sûr que tu peux gagner une ligne
.
Ouuuuuh le vilain taquin.
L'idée était de privilégier la lisibilité, qui me semblait plus importante ici, que la concision
Alors bon, à la demande générale, je joins une version à une ligne au lieu de 6.
vector getOffset(integer c) {return <c/10*2-7,7-c%10*2,.0>/16.;}
Je pense qu'on approche la limite inférieure du nombre de caractères
Ok ok, on peut gagner encore un peu, en supprimant les deux points décimaux, en raccourcissant le nom de la fonction...
Mais bon, là, j'enverrai une facture