J'ai une partie qui fonctionne assez bien (55-60fps) sur un écran de rétine. Je tiens à ajouter une superposition plein écran qui se mélange avec la scène existante. Cependant, même lorsque vous utilisez une petite texture, le succès de la performance est énorme. Y a-t-il une optimisation que je peux jouer pour rendre cette utilisable?
Si j'utilise une texture 80x120 (la texture est rendue à la volée, c'est pourquoi il n'est pas carré), je reçois 25-30fps. Si je rends la texture plus petite, la performance augmente, mais la qualité n'est pas acceptable. En général, cependant, la qualité de la superposition n'est pas très importante (c'est juste l'éclairage). P>
L'utilisation du rendu est à 99%. P>
même si j'utilise une texture carrée d'un fichier (.png), la performance est mauvaise. p>
Voici comment je crée la texture: p> et voici le rendu ... P> lowp vec4 texColor = texture2D(tex, texCoordsVarying);
lowp vec4 lightColor = texture2D(lightMap, worldPosVarying);
lightColor.rgb *= lightColor.a;
lightColor.a = 1.0;
gl_FragColor = texColor * color * lightColor;
4 Réponses :
OK, je pense que vous avez couru contre les limitations du matériel. Le mélange d'un quad à l'écran sur toute la scène est probablement un cas particulièrement mauvais pour le matériel à base de carreaux. Le PowerVR SGX (sur l'iPhone) est optimisé pour l'élimination de la surface cachée, pour éviter de tirer des choses lorsqu'il n'est pas nécessaire. Il dispose d'une bande passante de mémoire faible car elle est optimisée pour un périphérique basse puissance.
Quatre mélangée de taille d'écran est donc la lecture de chaque fragment à l'écran. Aïe!
Le Il y a une très bonne vue d'ensemble du matériel iOS ici: http://www.imgtec.com/facsheets/sdk/powervr%20sgx.opengl%20ES%202.0%20Application%20Développement%20Recommendations.1.1f .External.pdf comme pour une solution réelle - j'essaierais directement votre superposition sur la scène de jeu. Par exemple, votre boucle de rendu devrait ressembler à: GLCLEEAR SPEED UP est associé - parce que vous disiez que GL, vous ne vous souciez pas du contenu du backbuffeur avant le rendu, ce qui permet de charger le contenu précédent dans Mémoire.
Merci. Oui, je suis en quelque sorte vint à la même conclusion. Malheureusement, je ne peux pas utiliser votre solution-- La superposition que je dessine est vraiment plus une lumière de lumière, donc cela affecte les pixels d'environnement de jeu. J'ai fini par écrire un shader pour faire le même travail, avec un bon succès. Je posterai les détails de cela dans ma question. Merci pour toute votre aide sur l'enquête!
Génial - j'aimerais voir ce que vous avez fait.
J'utilise une quad à la taille d'écran mélangée sur toute la scène de mon jeu et que vous n'avez pas eu une goutte de cadence (30 fps en 3G, 60s dans les rétinas). Le ralentissement pourrait être dans la création de la texture? Est-ce que vous le faites chaque image?
Si vous rendant à une cible de rendu sur une puce PowerVR, passez à une autre cible de rendu et rendant, puis revenez à une cible de rendement précédente que vous subirez une performance majeure. Ce type de modèle d'accès est étiqueté une "charge de tampon logique" de l'analyseur OpenGL ES intégré aux derniers instruments.
Si vous changez d'ordre de rendu afin que vous dessinez d'abord votre cible de rendu LightMap, puis rendez votre scène à la trame principale, puis faites votre mélange complet de la texture de la cible de la LightMap, votre performance devrait être beaucoup plus élevée.
Je peux confirmer, sur iPad 1 à l'aide de iOS 4.2, activer / désactiver GL_BLEND pour un quad à écran complet basculé entre 18 et 31 fps. Dans les deux points, l'utilisation du rendu était de 90 à 100%.
Même avant de jouer avec la texture, assurez-vous que votre shader est optimisé. Lors du remplissage d'un écran de 960x640 (614400 pixels) toute opération du shader fragment a un impact énorme.
Une bonne chose à créer une version spécifique de votre shader de fragment pour cette situation. Il devrait s'agir de quelque chose comme ceci: Créez un autre programme avec ce shader de fragment et utilisez-le avant de dessiner votre gros quad, puis de restaurer le programme normal. L'iPhone 4 est capable de rendre environ 7 quads texturés en plein écran, 1: 1 par image avec mélange, mais il tombe rapidement à environ 1 avec un shader plus sophistiqué. (en outre dans votre cas, essayez Pour rendre d'abord votre texture de recouvrement, alors les éléments normaux, puis la texture sur le reste. Il devrait améliorer les performances d'une marge significative.)
Je soupçonne que les commutateurs tampon GlView sont probablement le coupable ici. Qu'est-ce qui se passe dans ces méthodes? Pourquoi ne pas utiliser
GLBINDRenderbuffer ?Je vais aligner ces méthodes de clarification.
OK pour débufer le problème de perf, essayez de pré-rendu la superposition (laissez-la simplement statique pour l'instant), puis de la copie dans le tampon principal de chaque image. Cela vous indiquera au moins si les commutateurs tampons sont lents (c'est-à-dire faire deux appels à GlbindFrame, GLBINDRender, GlviewPort chaque cadre).
Si je fais tout sauf le dessin (y compris le relancement, la fenêtre de la fenêtre et en réalisant les lumières), il est rapide. Je pense donc que cela doit être le dessin final / composition qui est lent.
Et si vous faites
gldisable (GL_BLEND) est-ce qu'il accélère?Désolé, je pense que tu as raison. J'ai fait plus de tests et il semble que la commutation tampon ait un impact. Des idées pour la façon d'atténuer cela? (Tests à l'aide d'un statique 256x256 .png) Aucun mélange, pas de commutation tampon: 52FPS OUI Mélange, pas de commutation de mémoire tampon: 46FPS Aucun mélange, commutation de mémoire tampon: 29FPS Oui Mélange, Yes Tampon Commutation: 27FPS OUIM SUPPORT, Aucun dessin: 46FPS
Oh, attends, j'ai quitté la ligne Glclear, qui semblait artificiellement accélérer le "Yes Mélange, Yes Buffer commutation" Benchmark. Il court à 29fps sans le Glclear. Je vais mettre à jour la question. Donc, il semble que le problème principal est de dessiner un grand quad à mélangé.