"architecture" la plus efficace pour une application 2D en couches utilisant OpenGL sur iPhone?

Question

Je travaille sur une application iPhone OS dont la vue principale est une vue 2D OpenGL (c'est une sous-classe de la classe EAGLView d'Apple, qui consiste à configurer un environnement 2D ortho-projeté) avec laquelle l'utilisateur interagit directement.

Parfois (pas toujours) je voudrais rendre quelques contrôles au-dessus de cette vue GL de base - penser comme un affichage tête haute. Notez que la vue de la ligne de base en dessous peut faire défiler/animer alors que les contrôles semblent être fixés sur l'écran ci-dessus. Je suis bon avec les vues Cocoa en général, et je suis assez bon avec CoreGraphics, mais je suis vert avec Open GL, et les opérations d'EAGLView (et sa relation avec CALayers) sont assez opaques pour moi. Je ne sais pas comment mélanger les autres éléments le plus efficacement (lire: meilleure performance, moins de tracas, etc). Je sais que dans un pincement, je peux créer et conserver la géométrie pour tous les autres contrôles, et les placer au-dessus de ma géométrie de base chaque fois que je peins/permutons et que je garde tout ce que l'utilisateur voit sur une seule vue. Mais je suis moins certain des autres techniques, comme avoir une autre vue sur le dessus (UIKit/CG ou GL?) Ou créer d'autres couches dans ma seule vue, etc.

Si les gens seraient si gentils d'écrire quelques brèves observations si elles ont déjà parcouru ces routes, ou au moins me diriger vers la documentation ou la discussion existante sur cette question, je l'apprécierais grandement.

Merci.

Answer 1

Créez votre vue animée normalement. Rendez-le à une cible de rendu. Qu'est-ce que ça veut dire? Eh bien, habituellement, quand vous "dessinez" les polygones à l'écran, vous le faites en réalité sur une surface normale (la surface primaire), qui se trouve être celle qui finit par arriver à l'écran. Au lieu de rendre à la surface de l'écran, vous pouvez rendre à n'importe quelle surface ancienne.

Maintenant, votre HUD. Est-ce que ce sera exactement la même chose tout le temps ou cela changera-t-il? Est-ce que seulement des morceaux changeront?

Si tout cela change, vous aurez besoin de garder toute la géométrie HUD et les textures en mémoire, et vous devrez les rendre sur votre « défilement » surface comme normale. Vous pouvez leur appliquer ce rendu composite final à l'écran. Je ne m'inquiéterais pas trop de tracas et de performance ici - le HUD peut difficilement être aussi complexe que le fond. Tu auras au moins quelques quadruples de textures?

Si tout le hud est statique, vous pouvez le restituer sur une surface distincte lorsque votre application démarre, puis chaque image s'affiche à partir de cette surface sur la surface animée que vous dessinez à chaque image. De cette façon, vous pouvez décharger toutes les géométries HUD et les textures dès le début. Bien sûr, il se peut que la surface prenne plus de mémoire - cela dépend des ressources dont votre application a le plus besoin. Si vous aviez des demi-changements et demi, alors techniquement, vous pouvez pré-rendre les parties statiques et ensuite rendre les autres parties que vous avancez, mais c'est plus compliqué que les deux autres options.

Vos deux options principales dépendent de la dynamique du HUD. Si elle se déplace, vous devrez besoin de le redessiner sur votre scène chaque image. C'est nul, mais je peux difficilement imaginer que la géométrie soit complexe par rapport au reste. Si c'est statique, vous pouvez pré-rendre et juste alpha mélanger une surface sur l'autre avant d'envoyer à l'écran.

Comme je l'ai dit, tout dépend de ce que les ressources de votre application aura de rechange.