Époustouflant 

Hello

Déjà pour la direction du sort, tu peux reprendre les valeurs X et Y du thumbstick. Il partira dans la direction du thumbstick forcément.
Donc sort.vx = thumbstick.left.x et sort.vy = thumbstick.left.y

Ensuite pour l'angle :
Le stick est de base en position (0, 0).
Quand tu le bouges, ça change les coordonnées X et Y. Donc tu peux par exemple l'avoir en (0.8, 0.12).

A partir de la, c'est simple : il suffit de trouver l'angle décrit par le triangle rectangle passant par (0, 0) et (0.8, 0.12)
C'est donc un calcul à base de côté opposée, côté adjacent, hypoténuse, sinus, cosinus ... La trigonométrie

Exemple de fonction qui renvoie l'angle entre 2 points (par rapport à l'axe des abscisse d'un repère orthonormal) :


Pour avoir l'angle de ton thumbstick, tu fais donc :

Voilou

Edit : J'ai cherché un peu le net, voir ce que les gens font. Tu as plus "simple" pour le coup, vu qu'on part toujours de 0, 0 ...

Tu peux utiliser la seconde "méthode" pour trouver l'angle du stick rapidos, mais la première méthode te permettra de calculer des angles entre 2 points n'importe ou à l'écran

Revoilou

L'origine est en bas à gauche de base

J'aurai pu passer this en effet, et faire ça plus propre aussi

L'interface est dans le projet Desktop.
Je ne fais que 2 projets (habitude vis à vis du tuto vidéo) : Desktop et Android. C'est Desktop qui contiendra toujours toute la logique de jeu, le projet Android ne fait que lancer le jeu et accessoirement, implémente l'interface que je crée pour gérer les spécificités liées aux plateformes.

Donc comme j'implémente à l'arrache l'interface dans ma classe principale, j'envoie ma classe principale à mon jeu. Dans un cas il s'agira de Desktop, dans l'autre d'Android. Mais dans les deux cas, je reçois un type "DroidInterface" qui me permet de manipuler les méthodes spécifiques.

J'avais commencé à séparer mes interfaces pour les regrouper selon leurs fonctionnalités. Quand j'ai commencé à créer 3 interfaces pour 3 méthodes, et fait autant de passage au constructeur, ça m'a saoulé et j'ai tout regroupé

Je sais que sur openGL (avec libgdx) il faut éviter les images de plus de 1024x1024.
Il y a des téléphones qui ont tendance à pas trop aimer ces grandes résolutions.

Pour un jeu, je charge tout pour pas montrer de loading ingame aux utilisateurs. Sinon je dirais que ça dépend du type d'application. L'appli 9gag par exemple ne charge que l'image en cours, et pendant que tu lis précharge la suivante pour gagner du temps, mais pas plus. Il charge pas les 50 images d'un seul coup

En Java, tu as le garbage collector. Lorsque tu fais un dispose() d'un objet, il est pas supprimé de suite, mais au moment du passage du garbage collector. Recycle() sert, il parait, à appeler le garbage collector plus vite. Mais bon, je suis pas convaincu de son utilisation

Perso c'est ma technique également : je load une image de loading, et derrière cette image je charge toutes les ressources du jeu. Ensuite, plus aucun loading pendant le jeu, sauf éventuellement les niveaux que j'ai stocké en fichier XML (je les laisse pas en mémoire)

Voilà un exemple pour expliquer l'interface

J'ai créé une interface nommé "DroidInterface" :

Elle me permet, en android comme en desktop, de pouvoir changer le pseudo du joueur ou savoir si je suis en mode desktop ou android.

Ensuite, je vais donc implémenter cette interface côté desktop et définir les fonctions  :



Côté android, voilà comment ça rend :

Je te passe les détails sur le fait de créer un handler pour permettre d'afficher un prompt dans le contexte courant, relou
Mais voilà, je défini côté Android comment ça doit faire quand on appelle les méthodes de l'interface


C'est simple au final, le plus dur c'est la première fois

Lorsque tu codes ton jeu, tu le codes dans la partie desktop (en tout cas, pour ma part). Cependant, dès que tu veux utiliser une spécificité propre à la plateforme (afficher un popup par exemple), il faut commencer à différencier le code.

En Java Swing, tu feras "JoptionPane.showMessageDialog()", mais en Android tu feras "AlertDialog()". Et là, c'est le drame ! Comment, alors que tu es en train de coder dans la partie desktop, dire à ton jeu qu'à ce moment il doit faire apparaître une popup selon la plateforme courante ?

=> Tu utilises les interfaces. (J'ai pas de code sous la main, mais je peux trouver si besoin)

Tu créé une interface "CrossPlatform.java" par exemple, qui déclare la méthode "showMyDialog".
Tu l'implémentes en Android en faisant "AlertDialog", et tu l'implémentes en Swing en faisant "JoptionPane.showMessageDialog()"
Après ça, la méthode qui construit ton jeu prend en paramètre un objet de type "CrossPlatform", et tu appelles "showMyDialog" sur cet objet pour afficher une dialog indépendamment de la plateforme

C'est le bordel à expliquer, mais c'est juste des interfaces quoi

Nop, pas d'activité. La librairie configure une zone openGL à l'écran et on vient dessiner dedans, comme sur DS ou Wii.

Je ne l'ai pas lu
Quand j'ai indiqué à l'auteur que j'avais acheté son bouquin, il m'a dit que ce n'était pas nécessaire pour moi et que je devrais pas le prendre

Donc là je peux pas trop te faire de retour Cependant, sur la page amazon tu peux le bouquiner un peu pour voir le contenu

C'est dommage que leur moulinette soit si restrictive dans le contenu de l'application android de base. Pas de code natif par exemple, et libgdx en utilise plein Donc pas possible pour moi de porter mes jeux

Celui là aussi a l'air complet, par le créateur de libgdx

bah euh les gars, je comprends pas tout à vos méthodes là
Moi j'affiche bien erreur technique à l'utilisateur, mais la stack trace reste dans le code quoi

J'affiche à l'utilisateur le message de l'exception à rapporter à la hotline de l'entreprise, mais pas plus
La stack trace est dans un log, qu'on consultera par la suite.

Vous loguez rien ?

Zipler, laisser planté une appli c'est peut être no problemo en solo, mais quand tu développes l'application à destination de collaborateurs de ton entreprise, il est très mal vu de voir des messages de plantage avec stack trace (c'est un peu violent lol)

Les exceptions permettent donc aussi au maximum de ne pas déranger l'utilisateur si dès problèmes surviennent, et de présenter un message plus user friendly tout en loguant et avertissant le codeur du problème rencontré

Il m'est arrivé d'utiliser des exceptions crades mais ça reste rare.
J'appelle exceptions crades les endroits où un simple test permet d'éviter l'exception (parseInt(), division par 0 ...)

Sinon je suis plutôt Pokemon exception :

Je n'utilise pas les exceptions pour m'aider dans mon code (comme ton exemple en Caml), mais plutôt pour vraiment faire un catch d'une erreur que je n'avais pas prévu, et la corriger pour qu'elle n'apparaisse plus ensuite