>elles ne sont pas optimisees.
Compare avec les routines ExtGraph pour les largeurs 8X et avec BitmapPut. Par rapport à ces fonctions-là, c'est optimisé. Et cela en raison de la spécialisation à 32*x.
>ExtGraph impose la convention C d'appel.
Mais pas des fonctions écrites en C!
Et ton exemple de mauvaise optimisation n'a rien à voir avec la convention d'appel, mais avec le C.
>C'est mon avis suite a mon bench perso ou Genlib offre de 87% a plus de 300% de vitesse en plus.
Le mien donne 34% sur HW1.
>>* profite de cette conversion pour rajouter des fonctions que tu as négligé pour des raisons de place: sprites avec masque, sprites 16*x plutôt que 16*16, et puis aussi 32*x et 8*x,
>>big_sprites avec masque et sans halo, ... (Même si personne n'utilise ces fonctions, si la librairie est statique, ça ne gène personne.)
>Ca par contre c'est deja prevu :P
Et si la librairie reste dynamique, les gens vont râler que la taille on-calc augmente.
Si elle est statique, ce ne serait pas le cas.
Je crois aussi que je n'ai pas été clair ici:
>>la plupart des programmes utilisant les fonctions
>>de type GraySprite*MASK, zoom, FloodFill ...)
Je voulais dire: "la plupart des programmes utilisant les fonctions de type GraySprite*MASK" et c'est tout. Les fonctions de type zoom et FloodFill ainsi que les autres routines de sprites ne se trouveront que rarement dans les programmes et donc on-calc.
>Bill-Bob:
>erf moi qui pensais que le halo autour des sprites de chrono etait du a un masque elargi !!
>Ca n'aurait pas ete plus rapide que de calculer le halo ?
>Enfin bref c dommage d'imposer ca quand meme
... meme si pour l'exemple de chrono c'est une bonne idee !
PpHd n'utilise jamais les masques.
[edit]Edité par Kevin Kofler le 08-08-2001 à 17:51:00[/edit]
on le remercie pas assez JM 
