Release de Flash CPE 2003 - Page 4

Je ne pense vraiment pas que l'effet de "saccade" dérange tellement. Et c'est idiot d'utiliser une interruption pour l'affichage des frames, vous jetez plein de cycles par la fenêtre!

Ah bon ? Pkoi ?

Parce que le processeur est en attente entre les 2 appels de l'interruption.

Oui, mais c'est pour avoir un fps constant que je fais ça.

Mais c'est quand-même un gaspillage de cycles.

Bon, j'ai benché la version avec 2 boucles (non déroulées) :
ExtGraph 1.02 : 7179 sprt/s
Futur ExtGraph (48 octets) : 8333 sprt/s (+16
2Boucles (80 octets) : 8762 sprt/s (+22

Donc le gain est quand même sympathique, mais la taille double presque. Et oui, j'ai benché les fonctions non clippées, donc elles étaient de petite taille à la base, donc de rajouter une deuxième boucle (et le peu de code qui va avec pour les gérer) a presque doublé la taille de la fonction.
Mais sur une fonction de sprite clippée, la taille n'augmentera que de 20% (150->180 octets) à mon avis.

bein faut savoir si vous voulez que votre lib permette de faire de gros jeux

Kevin Kofler
a écrit : Je ne pense vraiment pas que l'effet de "saccade" dérange tellement. Et c'est idiot d'utiliser une interruption pour l'affichage des frames, vous jetez plein de cycles par la fenêtre!

Mais la saccade est tout bonnement a exclure dans un programme ! Ca fait moche et lorsque l'on fait un jeu, on essaye de soigner les graphismes ... c'est de l'utilisation des niveaux de gris etc.
Donc cette perte de cycles est nécessaire ...

Bon, ce matin j'ai eu un peu de temps en cours pour écrire une fonction qui déroule un peu la boucle (j'affiche 2 lignes par itération).
Il faudra que je la recopie ce soir et je la bencherai.

Voilà le nouveau bench :
ExtGraph : 7160 sprt/s
Futur ExtGraph (52 octets) : 8198 sprt/s (+14.5
2 Boucles différentes (80 octets) : 8758 sprt/s (+22.3
2 Lignes par itération (72 octets) : 8712 sprt/s (+21.7

Donc la version qui affiche deux lignes par itérations est légèrement plus petite en taille et légèrement plus lente que la version qui utilise deux boucles selon le shifting.

Maintenant je vais voir en combinant les deux.

Et bonjour le gaspillage de place.

1/8198-1/8758 < 8 * 10^-6
On ne gagne même pas 8 microsecondes! Il vaut beaucoup mieux conserver les 28 octets!

J'ai fini la dernière version qui comprend les deux optimisations que je viens de tester et les résultats sont à la hauteur de mes espérances : 9506 sprt/s (soit une amélioration de 33% !)
Par contre la fonction a plus que doublé de taille (et pourtant j'ai essayé d'optimiser aussi en taille) : elle fait 120 octets

Kevin Kofler a écrit :
Et bonjour le gaspillage de place.

1/8198-1/8758 < 8 * 10^-6 On ne gagne même pas 8 microsecondes! Il vaut beaucoup mieux conserver les 28 octets!

nan mais je reve !

Bon 2 versions d'Extgraph c'est envisageable ? Une lente et petite, une moins lente et moins petite ?

si tu veux je te passerai les versions rapides.
Mais autant utiliser XLib en fait, ça doit être mieux.

cf topic d'XLib, si je peux m'en passer à moindre cout je le fais sans hésitation, j'en ai plus qu'assez de cette lib incomplete.

Ben je croyais que tu n'utilisais que 2-3 fonctions de la lib

Exactement, 2 fonctions. Et c'est pour ça que j'aimerais me passer de toutes ces fonctions de mise en route de la lib, création de buffer, redirection d'affichage, qui m'encombrent plus qu'autre chose et prennent une place considérable.

[edit pour Kevin] : considérable c'est pas 28 octets.

Ou alors tu fais chaque fonction en deux exemplaires: par exemple sprite_16 et fast(er)_sprite_16
Puisque c'est du statique on peut se le permettre

> Bon 2 versions d'Extgraph c'est envisageable ? Une lente et petite, une moins lente et moins petite ?
Possible, formellement, oui. Souhaitable, il faut voir. Mais pas sans l'aide d'un plus grand nombre de personnes... Parce qu'une fois que les routines seront finies, il faudra modifier en profondeur la documentation, pour l'intégration dans ExtGraph... Et ça prend du temps, beaucoup de temps.

Pour les routines, je préférerais la routine "2 lignes par itération", insensiblement plus lente que la "2 boucles différentes" mais plus petite.
La routine de 120 octets est trop grosse... On ne va pas faire des trucs XLib-like...
Et merci encore jackiechan de prendre le temps de faire tout ce boulot...

De rien, j'aime faire ça

Sinon, Ximoon ta proposition tient la route, mais déjà qu'on a à peine codé la moitié du total de fonctions à faire pour l'instant, si on rajoute encore des fonctions, ExtGraph ne sortira jamais...

Et bien concentrez-vous sur la version principale et faites un add-on plus tard

Ouais, ce serait déjà bien.
Il nous reste pas mal de fonctions clippées à faire et après toutes les fonctions en nvg.

Bah c'est du recopiage/adaptation brutal non? J'imagine que les routines de clip seront plus ou moins les mêmes pour toutes les fonctions de sprites au moins.
Pour les nvg ça va pas changer trop non plus... du travail à la chaine quoi.

Oui, mais ça prend quand même un certain temps. Et je tiens à vérifier le bon fonctionnement de chaque routine.
D'ailleurs en traduisant certaines fonctions de A68k en GNU ASM, j'ai fait parfois des petites modifs, il faudrait que je vérifie si ça ne gêne pas.

Tu fais bien
Vivement que vous ayiez fini, ça sera une bonne chose de faite!

MDR.
Kevin, t'as deja vu un jeu sans synchro... ton ignorance me fera de plus en plus rire!

Vertuos: Dsl si Xlib ne correspond pas a tes besoins, mais elle est loin d'etre grosse (faut pas abuser quans meme!).
Et pour ce qui est du nombre de fonction a appeler, il faut pas dire n'importe quoi.. a part XOn et XGPlanc et XNewPlan, le reste reste un jeu d'enfant.. et d'ailleur meme avec Extgraphlib, il faudra allouer tes plan, activer tes niveaux de gris etc... qui est beaucoup plus long qu'avec Xlib!

jackiechan
a écrit : D'ailleurs en traduisant certaines fonctions de A68k en GNU ASM, j'ai fait parfois des petites modifs, il faudrait que je vérifie si ça ne gêne pas.

La conversion a68k>GNU, je comprends pas vraiment l'interêt...
TIGCC supporte parfaitement a68k, et les fonctionnalités du GNU Asm ne sont pas utilisées, non ?
Des % partout c'est pas vraiment marrant à lire.

NB: tu te plaignais de GX car tu la trouvais pas assez rapide, mais bon perso je suis 80% sur que extgraphlib sera pas plus rapide ( et je ne me base pas sur des benchs a la ***)

ExtendeD a écrit :
La conversion a68k>GNU, je comprends pas vraiment l'interêt...
TIGCC supporte parfaitement a68k, et les fonctionnalités du GNU Asm ne sont pas utilisées, non ? Des % partout c'est pas vraiment marrant à lire.

En fait, c'est simplement parce que XDanger avait commencé à écrire ses fonction en GNU ASM, donc pour avoir un truc plus homogène, il préfère que je mette tout en GNU.

lol
l'important c'est que ce soit au moins plus rapide que la version précédente