LibGDX a un système de coordonnées où (0,0) se trouve en bas à gauche. (comme cette image : http://i.stack.imgur.com/jVrJ0.png )
Je me frappe la tête contre un mur, principalement parce que je porte un jeu que j'ai déjà fait avec le système de coordonnées habituel (où 0,0 est dans le coin supérieur gauche).
Ma question : Existe-t-il un moyen simple de changer ce système de coordonnées ?
Si vous utilisez une caméra (ce que vous devriez faire), le changement de système de coordonnées est assez simple :
camera= new OrthographicCamera(Gdx.graphics.getWidth(), Gdx.graphics.getHeight());
camera.setToOrtho(true, Gdx.graphics.getWidth(), Gdx.graphics.getHeight());Si vous utilisez des TextureRegions et/ou un TextureAtlas, tout ce que vous devez faire en plus est d'appeler region.flip(false, true).
Les raisons pour lesquelles nous utilisons y-up par défaut (que vous pouvez facilement modifier comme illustré ci-dessus) sont les suivantes :
Les deux seuls endroits dans libgdx où nous utilisons y-down sont :
Encore une fois, vous pouvez facilement changer le système de coordonnées utilisé en utilisant soit Camera, soit un petit peu de mathématiques matricielles.
@badlogic vous avez spécifié qu'il devrait utiliser la caméra, mais quel serait l'inconvénient d'utiliser simplement la méthode SpriteBatch.draw et de gérer moi-même le défilement du monde et le frustum culling ? Je développe un jeu de stratégie de haut en bas.
Je suppose qu'il y a une raison pour laquelle il a été développé de cette façon, mais que se passe-t-il si vous n'utilisez pas de caméra du tout et que vous dessinez simplement des textures, des images, des polices de caractères, etc. en utilisant SpriteBatch.draw() ? J'ai exactement le même problème que Pasman.
Juste pour développer un peu sur ce que badlogic a dit ci-dessus, si vous utilisez un TextureAtlas (avec TextureRegions) vous devez les retourner, comme badlogic a dit, en plus du travail de la caméra. Si vous utilisez un TextureAtlas, vous pouvez utiliser ce code juste après avoir chargé votre atlas :
String textureFile = "data/textures.txt";
atlas = new TextureAtlas(Gdx.files.internal(textureFile), Gdx.files.internal("data"));
// Let's flip all the regions. Required for y=0 is TOP
Array<AtlasRegion> tr = atlas.getRegions();
for (int i = 0; i < tr.size; i++) {
TextureRegion t = tr.get(i);
t.flip(false, true);
}
Si vous voulez cacher la transformation et ne pas y penser après l'avoir configurée une fois, vous pouvez créer une classe qui hérite de toutes les fonctionnalités dont vous avez besoin, mais qui transforme d'abord les coordonnées avant de les transmettre à la fonction de sa classe parente. Malheureusement, cela prendrait beaucoup de temps.
Vous pourriez aussi créer une méthode qui fait le simple y' = height - y transformation sur l'ensemble Coordinate (ou ce que vous utilisez), et l'appeler une fois avant chaque opération.
Eh bien, ce n'est pas exactement ce que je voulais. Mais j'ai fait ceci et ça a bien fonctionné, et ce n'était pas beaucoup de codage non plus (d'ailleurs, j'ai continué à chercher et je pense qu'il n'y a pas d'autre moyen) Merci !
Je ne sais pas si c'est ce que vous vouliez dire, mais je ne pense pas qu'une classe "divine" qui fasse tout cela soit une très bonne idée, donc j'essaie d'étendre toutes les classes dont j'ai besoin et de surcharger les méthodes si nécessaire. Ce n'est pas une belle solution non plus.
Une bibliothèque graphique intéressante, je dirais. J'ai trouvé cette évaluation à partir du lien ci-dessous :
Un autre problème était que différents systèmes de coordonnées étaient utilisés dans différentes parties de Libgdx. Parfois, l'origine des axes se trouvait dans le coin inférieur gauche avec l'axe des ordonnées pointant vers le haut et parfois dans le coin supérieur gauche du sprite pointant vers le bas. Lors du dessin de Meshes, l'origine était même au centre de l'écran. Cela provoquait une certaine confusion et un travail supplémentaire pour que tout soit à la bonne place à l'écran. l'endroit correct sur l'écran.
C'est en fait une bibliothèque très puissante pour le développement de jeux sous Android. La seule chose bizarre est la gestion des coordonnées, comme le souligne l'évaluation.
Ainsi, si vous vous y connaissez en caméras ou en matrices, vous pouvez avoir le système de coordonnées que vous voulez :)
Mais si vous n'utilisez pas de caméra, il semble que vous n'ayez pas de chance et que vous deviez envelopper l'API dans une façade pour changer cela. Arrrgh..pourquoi utiliser autre chose que l'absurde système de coordonnées standard haut-gauche ? POURQUOIYYYYYYYYYYYYYYYY ? :(
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
0 votes
Bien sûr, c'est un peu ce que je fais en ce moment. Mais y a-t-il un moyen d'inverser le système de coordonnées ? Quelque chose comme créer une matrice de projection avec le système de coordonnées que je veux. Ou dire au Spritebatch de dessiner selon un certain système de coordonnées... J'ai cherché comme un fou, mais je ne semble pas trouver quelque chose en particulier ... (et si oui, quel est le code réel)
2 votes
C'est en effet un cauchemar. Les choses comme SpriteBatch et sprites vont du bas vers la gauche. Les choses comme input et textureregion partent du haut à gauche. Il en résulte un codage très maladroit et une rotation des choses dans votre esprit si souvent que vos yeux commencent à sortir. Quoi qu'il en soit, je recommande de s'y habituer, tourner autour de la caméra résulte en des images retournées et ensuite vous devez tout retourner, mais pas tout, juste la plupart des choses et les faire dessiner de manière inattendue. LibGDX est génial, mais le système de coordonnées a de sérieux problèmes. Il faut s'y habituer.