2010-03-23 5 views
6

Je me demandais si quelqu'un pouvait vous conseiller sur un bon modèle pour le chargement des textures dans une application Android & OpenGL ES. Ma première préoccupation est de déterminer combien de noms de texture à allouer et comment je peux efficacement faire cela avant de rendre mes sommets.Chargement des textures dans une application Android OpenGL ES

Ma deuxième préoccupation concerne le chargement des textures, je dois déduire la texture à charger en fonction de mes données de jeu. Cela signifie que je vais jouer avec des cordes, ce que je comprends est quelque chose que je ne devrais pas faire dans mon thread GL. Dans l'ensemble, je comprends ce qui se passe lors du chargement des textures, je veux juste en tirer le meilleur cycle de vie. Y a-t-il d'autres choses que je devrais envisager?

Répondre

14

1) Vous devez allouer autant de noms de texture que vous le souhaitez. Un pour chaque texture que vous utilisez.

Le chargement d'une texture est une opération très lourde qui bloque le pipeline de rendu. Donc, vous ne devriez jamais charger de textures dans votre boucle de jeu. Vous devez avoir un état de chargement avant l'état de l'application dans lequel vous affichez les textures. L'état de chargement est chargé de charger toutes les textures nécessaires au rendu. Ainsi, lorsque vous avez besoin de rendre votre géométrie, toutes les textures sont chargées et vous n'avez plus à vous en soucier.

Notez que lorsque vous n'avez plus besoin des textures, vous devez les supprimer en utilisant glDeleteTextures.

2) Si vous voulez dire par là que vous avez besoin de différentes textures pour différents niveaux ou quelque chose de similaire, vous devez traiter les données de niveau dans l'état de chargement et décider quelles textures doivent être chargées. En revanche, si vous avez besoin de peindre du texte (comme le score actuel), les choses se compliquent dans OpenGL. Vous aurez les options suivantes: prérendre le texte nécessaire aux textures (facile), implémenter votre propre moteur de polices bitmap (plus difficile) ou utiliser la paire Bitmap et Canvas pour générer des textures à la volée (lent).

Si vous avez un ensemble limité de messages à afficher pendant le jeu, alors je les préfèrerais probablement aux textures car l'implémentation est plutôt triviale.

Pour le score actuel, il suffit d'avoir une texture qui a un glyphe pour les nombres de 0 à 9 et de l'utiliser pour rendre des valeurs arbitraires. La mise en œuvre sera assez simple.

Si vous avez besoin de textes plus longs, vous devez commencer à réfléchir aux textures génératrices à la volée. Fondamentalement, vous créez une image dans laquelle vous affichez du texte en utilisant un canevas. Ensuite, vous le téléchargeriez en tant que texture et le restitueriez comme n'importe quelle autre texture. Une fois que vous n'en aurez plus besoin, vous le supprimerez. Cette option est lente et doit être évitée dans la boucle d'application. 3) En ce qui concerne les textures et pour tirer le meilleur parti du GPU, gardez au moins les choses suivantes dans votre esprit (ces choses deviendront un peu plus avancées, et vous ne devriez les utiliser qu'après avoir reçu l'application) en cours d'exécution et si vous avez besoin d'optimiser la fréquence d'images):

  • Minimiser les modifications de texture car l'opération est lente. Idéalement, vous devriez rendre tous les objets utilisant la même texture dans un lot. Puis changez la texture et rendez les objets ayant besoin de cela et ainsi de suite.
  • Utilisez des atlas de texture pour réduire le nombre de textures (et les changements de texture)
  • Si vous avez beaucoup de textures, vous devrez utiliser d'autres profondeurs que 8888 pour que toutes vos textures tiennent dans la mémoire. L'utilisation de profondeurs de bits inférieures peut également améliorer les performances.
+2

Lorsque vous dites "état de chargement", est-ce normal que ce soit en même temps que j'initialise mon moteur de rendu? Ma pensée actuelle est de faire initialiser mon graphe de scène et interroger tous les objets dans le graphe de scène pour les textures qu'ils finiront par demander (en leur faisant déduire des noms du modèle de jeu). Chaque objet qui a demandé une texture devrait alors recevoir le «nom» d'entier OpenGL correspondant aux textures qu'il a demandées. Cela vous semble-t-il correct? –

+2

J'aime modéliser la logique applicative de haut niveau en utilisant des machines à états. Ainsi, le terme état de chargement. Il est tout à fait correct de le faire en même temps que vous faites le reste de l'initialisation. C'est juste une question de comment vous voulez concevoir votre logique d'application. Donc, il semble bien. – Lauri

2

Cela devrait être un commentaire à la réponse de Lauri, mais je ne peux pas commenter avec 1 représentant, et il y a une chose qui doit être souligné:

Vous devez textures recharger chaque fois votre Le contexte EGL est perdu (c'est-à-dire lorsque vos applications sont mises en arrière-plan et inversement). Ainsi, l'emplacement correct pour les (re) charger est dans la méthode

public void onSurfaceChanged(GL10 gl, int width, int height) 

du moteur de rendu. Évidemment, si vous avez des ensembles de textures différents à charger en fonction du niveau de jeu que vous jouez, vous devez supprimer les textures que vous n'utilisez pas et charger les nouvelles textures lorsque vous changez de niveau. En outre, vous devez garder une trace de ce que vous devez recharger lorsque le contexte EGL est perdu.

Questions connexes