stratégie de rendu pour un système de fenêtre XNA (performance RenderTarget)

Question

Je crée actuellement un système de fenêtre pour les jeux XNA à partir de zéro. Je développe principalement pour Windows, mais qui sait quelles plates-formes je pourrais soutenir à l'avenir. N'hésitez pas à répondre si vous le savez pour Direct3D natif, car la sémantique des performances devrait être similaire. Si possible, pensez à ce qui changerait si la plate-forme cible était X-Box 360.

Je fais des progrès, mais maintenant je ne suis pas sûr sur la façon de rendre exactement les fenêtres. Je suis venu avec quatre approches:

• Juste render tous les contrôles directement sur l'écran. C'est ce que je fais maintenant. Les contrôles peuvent être animés par un mélange entre les états tant qu'ils ne sont pas semi-transparents. Je n'ai pas trouvé un bon moyen d'animer entre un nombre arbitraire d'états (supposons un bouton qui est en train d'animer de bouton en bas à bouton en bas et de souris en passant par souris, puis il est désactivé. Avec cette approche, cela ne fonctionne que si une animation est jouée après la fin de la dernière, ou si vous avez des sauts dans l'animation

• Rendu chaque fenêtre de haut niveau tous les contrôles dans une cible de rendu, puis l'utiliser pour rendre les fenêtres de haut niveau avec semi-transparence sur l'écran.Cela rend la semi-transparence au travail de haut niveau et est facile à gérer, mais ne change pas la chose avec les animations.

• le rendu de chaque commande en un Rende r cible, qui n'est mise à jour que lorsque le contrôle devient sale (c.-à-d. doit animer ou le texte a été modifié). De cette façon, la semi-transparence par contrôle fonctionnerait.

• Comme le précédent, mais en plus de résoudre le problème d'animation ont une deuxième cible de rendu pour chaque contrôle. Chaque fois qu'une animation démarre, permutez les cibles de rendu, de sorte que nous ayons l'état au démarrage de l'animation et que nous l'associons à l'état de destination dans l'autre cible de rendu. Cela ne devrait pas ajouter de surcharge par rapport à l'approche précédente, nous avions seulement deux fois plus de cibles de rendu, dont dans une trame donnée, une seule serait rendue (au maximum). Mais voici le problème: pour que cela fonctionne, il faudrait que l'ancienne cible de rendu conserve son contenu. Cela devrait fonctionner avec de bonnes performances sous Windows, mais semble avoir un sérieux impact sur les performances sur X-Box 360. D'un autre côté, le bit "preserve" n'est nécessaire que lorsqu'une animation est active.

Et voici les vraies questions. Tout ce qui clarifie est le bienvenu. Avec les questions de performance, souvenez-vous que ce serait juste le système de fenêtre d'un jeu - le jeu derrière pourrait utiliser de nombreuses cibles de rendu et aspirer les performances aussi, et probablement beaucoup plus que le système de fenêtre. Supposons que nous ayons cinq fenêtres de haut niveau avec 20-40 contrôles chacun sur l'écran dans le pire des cas.

• Laquelle de ces approches, le cas échéant, recommanderiez-vous et pourquoi? N'hésitez pas, bien sûr, à ajouter une autre approche.
• Y at-il un impact sur les performances quand tout avoir, disons 200 ou 400 cibles disponibles render, à condition que peut-être seulement 20 d'entre eux sont rendus à chaque image?
• L'impact des PreserveContents sur les performances est-il vraiment si mauvais sur X-Box 360? À quel point est-ce que c'est Windows?
• La propriété RenderTarget2D.RenderTargetUsage peut être écrite dans. Est-ce une bonne idée de changer cela à l'exécution, pour activer PreserveContents seulement si nécessaire?Pourriez-vous (en tant que joueur) si les animations de contrôle sauteraient dans certaines situations, par exemple en survolant un bouton, en déplaçant la souris puis en revenant, de sorte que l'animation "normal-> hover" est jouée deux fois depuis le début parce que c'est plus lent que toi?

Answer 1

• Si vous voulez que le niveau de contrôle avec des animations (ie. Ayant plusieurs cours sur le même contrôle à la fois), alors vous allez avoir faire des passes multiples. Donc, soit activer ce genre de chose dans un shader et faire plusieurs passes avec le shader, ou faire la boucle Render-> Resolve-> Rerender standard.
• Il y a en effet un hit de performance créant autant de jeux de rendu. Ce n'est pas une bonne idée d'en créer autant. Il est préférable d'avoir un plus petit nombre de cibles de rendu de plus grande taille et d'écrire plusieurs contrôles sur cette cible.
• Cela fait longtemps que je n'ai pas fait de 360 ​​dev (bugger :(), mais d'après ce que je peux me rappeler, ce n'est pas vraiment génial, j'éviterais cette option à moins que ce ne soit absolument nécessaire. help
• Cela peut fonctionner à l'exécution, mais peut impliquer beaucoup de travail dans les coulisses Je ne m'attendrais pas à ce que cela fonctionne trop bien Je suis sûr que ça ira si vous ne le faites pas dans le milieu d'une boucle rendre.
• Je pense que les animations Jumpy seraient certainement sucer. Imho :)

Answer 2

Si vous développez pour Xbox 360, vous devez être prudent avec cibles de rendu. La Xbox 360 dispose d'une mémoire spéciale (10 Mo) pour contenir les cibles de rendu, y compris celle utilisée pour le rendu à l'écran. Tant que vous ne dépassez pas 10 Mo, le passage d'une cible de rendu à une autre n'a aucun impact, même avec PreserveContents, car toutes les cibles de rendu sont stockées dans cette mémoire spéciale. Cependant, lorsque vous avez plus de 10 Mo de cibles de rendu avec PreserveContents, cet attribut doit être émulé en changeant constamment une cible de rendu et en mémoire normale. Le nombre de cibles de rendu n'est donc pas aussi important que la taille totale de celles-ci. Vous pouvez connaître la taille d'un rendu cible avec cette formule:

size (bits) = width x height x color data size (bits) 

La taille des données de couleur est de 32 bits sur Xbox 360 ainsi, à titre d'exemple, si l'utilisateur de votre bibliothèque développe son jeu en HD avec seulement aucune autre cible de rendu que la principale, il utilisera:

3,515625MB = 29491200 bits = 1280 x 760 x 32 bits 

De même, vous devriez éviter de créer dynamiquement des cibles de rendu. Ça coûte trop cher. Vous devez créer un pool de cibles de rendu statiques allouées au début du jeu et demander à vos composants d'interface graphique de les demander.

Answer 3

La Xbox360 dispose de 10 Mo de mémoire spéciale pour la cible de rendu en cours. Mais le reste a dit à propos de comment cela fonctionne n'est pas tout à fait exact. Quel que soit le rendu, la cible est utilisée dans ces 10 Mo d'espace. Sinon, vous pouvez avoir autant de cibles de rendu que vous le souhaitez. Si votre cible de rendu est plus grande que les 10MB (comme 1280x720 avec certains multi-échantillonnages AA), la xbox360 utilise une technique nommée Predicated Tiling: http://msdn.microsoft.com/en-us/library/bb464139.aspx

Je suis bien dans l'écriture d'un système de fenêtrage. Je rends les widgets à une cible de rendu, puis restitue la cible du widget à la cible de la fenêtre, la cible de la fenêtre au backbuffer. Cela me permet d'ajouter facilement des barres de défilement et de rendre seulement une partie de la cible de rendu du widget sur la cible de rendu de la fenêtre.S'il y a une meilleure façon de gérer le défilement du contenu de la fenêtre, faites-le moi savoir. Je ne sais pas si c'est la meilleure performance.