Optimisation des rotations

[Sphax]

Bonjour à tous,

après avoir fait quelques tests, il semblerait qu'une petite optimisation dans le moteur de rendu software serait assez simple à ajouter.

Quand un objet est "pivoté", le framerate chute assez vite (plus vite si c'est en haute définition) même si l'objet est invisible. L'optimisation s'appliquerait quand l'éditeur d'événement demande de pivoter un objet. Dans ce cas, l'angle demandé serait mémorisé dans l'objet mais la rotation ne serait pas appliquée directement.

La rotation graphique serait appliquée en fonction de l'angle mémorisé si l'objet n'est pas déjà dans cet angle, si l'objet est visible et actuellement affiché dans la fenêtre.

La rotation du masque de collision serait appliquée si le masque n'est pas déjà dans cet angle et si la collision fine de l'objet est demandée.

Actuellement le framerate baisse même si l'objet est invisible ou en dehors de la fenêtre.

Cette optimisation serait aussi utile dans le cas du rendu HWA pour le masque de collision.
[img]/epicentre/images/%%GRAEMLIN_URL%%/smile.gif[/img]

[Brovic]

<div class="ubbcode-block"><div class="ubbcode-header">En réponse à:</div><div class="ubbcode-body">si l'objet est visible et actuellement affiché dans la fenêtre.</div></div>
Mais il y a le cas de figure où une partie de l'objet ne s'affiche que SI il est préalablement pivoté. ex : un marteau.
<div class="ubbcode-block"><div class="ubbcode-header">Code:</div><div class="ubbcode-body ubbcode-pre" style="height: 96px;"><pre>
___ ___________ _________
| | | \| |
| | fenêtre | --&gt; /\ |
| |_________| / |_________|
</pre></div></div>
On ne peut pas savoir si il va être partiellement visible avant qu'il ne soit pivoté. Dans un tel cas la rotation ne s'appliquera jamais alors qu'au moins une partie de l'objet est théoriquement dans la zone d'affichage.

[BenjaminG]

On peut néanmoins rapidement calculer les dimensions de l'objet "après rotation" (avec l'angle et les dimensions) et avec ses coordonnées savoir s'il sera visible ou non... et ce avant d'effectuer la rotation!

Donc ce que propose Sphax vaut le coup d'être étudié!

(En même temps dans la clickteam, ils ne sont pas manchots... donc il y a peut être une raison à ça...)

[Sphax]

Je n'avais pas pensé à ça mais ça reste quand même faisable car en effet calculer 4 coins pivotés est bien plus rapide que de toujours calculer la rotation bitmap du sprite.

[Brovic]

Ca serait bien dans une version ultérieure (MMF3 ?) qu'on puisse avoir une sorte de marge/"zone spéciale" autour de la zone d'affichage. Les objets pénétrant dans cette zone même s'il ne sont pas affichés pourraient activer la fine collision par exemple ou une IA plus performante que celle utilisée hors champs (et dans notre cas la rotation).

[Sphax]

Tu peux déjà connaitre la zone d'affichage.

[Brovic]

Oui mais entre la Zone d'Affichage et la scène entière il y a une sorte de no man's land évènementiel. Par exemple on peut attribuer une IA simpliste à des ennemis éloignés de l'écran pour ne pas charger le CPU, et leur attribuer une IA plus poussée quand ils sont à l'écran pour qu'ils n'aient pas l'air crétins mais il suffit qu'ils soient pendant une ou 2 secondes hors champs ne serait-ce que d'un pixel pour qu'ils se comportent à nouveau comme des crétins (genre une sentinelle ou un sniper qui attendent d'être visibles pour réagir alors que tu es théoriquement à 10 mètres). Voir aussi le cas du marteau mentionné, la seule condition "est affiché" ne fonctionne pas pour la rotation alors qu'avec une zone de sécurité il aurait été pris en compte même en étant hors champs (sans avoir à calculer sa bounding box).

Il y bien la condition "is getting closer than x pixels from window's edge" qui s'en rapproche mais il me semble qu'elle ne fonctionne que de l'intérieur (un objet à l'extérieur ne peut pas savoir qu'il se rapproche de la fenêtre).

[Sphax]

Ce que je veux dire c'est que tu peux déjà calculer la zone de l'écran ! En utilisant "X Left Screen", "X Right Screen", "Y Top Screen" et "Y Bottom Screen".

[Brovic]

Je sais mais je parle de faire une distinction claire entre la "play area" (qui actuellement correspond à la frame), la frame proprement dite, et la Zone d'affichage(ZA). On aurait les conditions :

- On enter/leave Frame
- on enter/leave Play Area
(où Play area serait égale à ZA + marge de x pixels)
- on enter/leave ZA
(où ZA = l'équivalent du "client area" de l'objet window)

On s'y perd un peu avec les termes aussi. Il faudrait normaliser tout ça dans MMF3.

[Sphax]

C'est déjà "normalisé", sur ce coup, tu te compliques bien la vie...
Il existe la scène (frame), la caméra/écran (camera/screen) et la fenêtre (window).

Encore une fois, tu peux déjà tester si un objet est à l'écran avec ou sans marge !