MMF2 HWA Beta 1e

Bonjour,

Un nouveau build est disponible:

Version Standard
Version Developer

Il corrige quelques problèmes rapportés dans la première béta :

- les actions Flip ne marchaient pas dans l'objet Image Active.
- l'alignement vertical ne marchait pas correctement dans l'objet Chaîne.
- crashes avec l'objet Calque.
- l'objet Particle Spray devrait marcher correctement maintenant avec la version HWA.
- la condition "Souris sur objet" ne marchait pas avec les objets ayant un angle ou un coef. d'échelle différent de 1.
- la fonction Ajouter Décore ne marchait pas.
- les effets ne marchaient pas avec les objets Chaîne.
- apparemment l'option VSync ne marchait pas correctement dans la première béta (mais c'est peut-être encore améliorable, la gestion interne de Direct3D 9 est différente, voir l'autre post sur la première béta).

Les autres problèmes seront corrigés ultérieurement.

Merci!

Yves.

Juste pour info quelques bugs ont été rapportés dans cette version (pour que vous ne les rapportiez pas) :

- les chaînes sont affichées sous les objets décor
- l'action Ajouter Décor ne marche pas dans l'objet Image Active
- les compteurs affichés en mode texte ne sont pas toujours affichés à la bonne position en cas de scrolling
- il peut y avoir des crashs dans les tests de collisions avec un sprite redimensionné ou ayant un angle différent de 0

Cette version semble nettement plus performante sur certains points, en particulier il y avait un net temps d'attente et pas mal de ram utilisée lorsqu'on affichait beaucoup de grands sprites à l'écran. Là ça démarre tout de suite et l'usage ram est normal. Cool.

Pour la condition <mouse over>/angle, c'est partiellement résolu à savoir que la condition fonctionne mais j'ai oublié de rapporter qu'il y avait aussi une chute dramatique du framerate quand on passait la souris sur les objets, apparemment liée à une hausse effrénée de l'usage CPU. On passe d'un FPS de 130 à un FPS de 20 (!).
Je joint un MFA test mais il faudra sans doute augmenter le framerate et le nombre de sprites sur une config moderne pour le tester correctement.

J'ai toujours également un net déchirement avec le MFA d'heliuse sur mon PC (PIV 2.26 | Geforce 4 Ti 4200 | XP) et sur mon portable aussi (Dothan 2Ghz | Geforce FX 5200Go | XP) avec ou sans synchro d'ailleurs et réduire la taille de la fenêtre et du visuel n'y change rien.

J'ai noté un truc bizarre :
quand le framerate imposé une application dépace sensiblement sa capacité à le suivre, par exemple quand on impose un FPS de 200 alors que l'application n'arrive pas à dépasser 130, l'utilisation du CPU grimpe à 100% alors que si on redescend le framerate à 130 le CPU retombe à 0%. Absolument rien ne justifie ce surcroît d'activité puisque ni les sprites accélérés, ni le code ne requièrent cette puissance alors que diable calcule MMF lors de ce dépassement de framerate ?

Ca n'a peut-être aucun rapport mais j'ai rapporté sur le forum anglais un autre bug bizarre (datant d'avant la HWA) à savoir qu'un Framerate fixé à 500 fais chuter sur certaines configurations le FPS à 260 (alors qu'à 499 ou 501 il n'y a aucun problème).

Bref il y a des trucs pas clairs et tous ces trucs réunis montrent qu'il y a un problème au niveau de la synchro.

PS : Testez les releases avec des machines qui ont au moins 4-5 ans comme un bon "vieux" PIV et une "vieille" geforce parce que vous passez à coté des chutes de performances anormales sur des machines trop puissantes.

La chute de framerate est normale dans la version actuelle car pour tester les collisions avec les sprites ayant un angle, je calcule le masque de collisions à la main (Direct3D ne gère que les images, pas les masques de collision).

Mais en fait dans le cas du test de la souris sur les objets actifs c'est hyper optimisable, je suis une quiche, il suffit de rapporter le point à tester dans le repère de l'image et de tester le pixel du masque originel... Je vais optimiser ça.

Pour le coup du frame rate qui passe à 260, ça n'a rien à voir avec la synchro, c'est probablement un problème de résolution du timer suivant les machines, les timers ne sont pas tous aussi précis suivant les machines.

Je vais regarder le coup de la synchro, sous DirectX9 je peux mettre utiliser l'option dont je parlais, mais ça fait tomber le frame rate à 30 fps sur ma machine. Je vais voir si je ne peux pas faire mieux.

PS: en ce qui concerne l'utilisation du CPU, si le frame rate demandé est inférieur (même légèrement) au frame rate possible, MMF2 se met en sommeil le temps restant entre la fin du calcul de la frame courante et le début de la suivante. Même si ce temps est très court, l'appel de la fonction en question permet à Windows de switcher plus facilement sur d'autres applis.

Si le frame rate demandé est supérieur, MMF2 n'attend pas et essaye de récupérer le maximum de temps.

Le calcul du pourcentage de CPU accordé par Windows à l'appli est probablement différent dans les 2 cas, même si l'appli consomme à peu près autant de CPU.

Toujours avec mon exemple : test syndro
On remarque avec ta nouvelle beta un changement de la gestion de la syncro mais elle ne fonctionne toujours malheureusement pas correctement .
c'est trés bizare car par exemple le fait l'ouvrir la petite fenêtre du débugeur rend l'animation presque parfaitement syncro (en regardant bien elle s'effectue dans ce cas à la 3em lignes en partant du haut).
mon cpu a une charge dans ce cas précis de 15% en moyenne et si je ferme la fenêtre du débugeur l'image redevient toute hachés l'animation s'accélère et le cpu passe a 40% .
xp 32 ,la syncro est forcée dans les prefs nvidia .
sur vista c'est pire qu'avant , hachée grave .
c'est à rien y comprendre , seul toi Yves sais commen MMF gère l'affichage , utilise t'il un double ou triple tampon mémoire , précalculant les images pour que l'affichage soit à jour pile au moment du refraichissement d'écran ?
Merci Yves.

OK, je vais utiliser la méthode standard, ça résoudra le problème même si c'est plus lent, et je garderai la méthode actuelle en mode fenêtré sous DirectX8 en essayant de l'améliorer.

C'est paradoxal cette histoire de framerate/cpu parce que si on prend mon exemple avec les plumes qui tournent (% en gros):
(A) framerate MMF: 130 => FPS affiché: 130 => CPU = 0%
(B) framerate MMF: 200 => FPS affiché: 130 => CPU = 100%
(C) framerate MMF: 200 mais sprites invisibles => CPU = 0%

Donc, CPU réclamé par l'affichage = 0% puisque c'est la carte qui gère (cf. A), CPU réclamé par l'application hors affichage = 0% puisque pratiquement rien à calculer (cf. C) - mais la somme des 2 = 100% CPU si le framerate > FPS max (cf. B) ? MMF réclame inutilement 99% de ressources puisqu'ici le goulet d'étranglement c'est la carte pas le processeur (aligner 50 pentiums en série n'y changerait rien).

Avec la HWA le framerate seul n'est plus un critère pertinent pour déterminer si MMF doit solliciter ou non plus de ressources CPU. Il faut tenir compte à la fois des capacités de la carte ET des besoins réels du processeur (parce qu'usage réel ou allocation de temps CPU ou pas, je constate que mon portable chauffe et ventile à tout va quand ça affiche > 70).

Juste pour info, la chute de frame rate de 130 à 20 n'arrive plus dans la prochaine béta (2d, pas encore sortie). [img]/epicentre/images/%%GRAEMLIN_URL%%/smile.gif[/img]

Ah, cool. je n'avais lu. Merci.
Ca serait bien aussi si on pouvait empêcher MMF de tirer sur le CPU quand c'est la carte qui ne suis pas le framerate imposé (bizarrement cocher machine indépendant speed ne change pas grand chose).