GenLib vs ExtGraph ou Kernel vs nostub - Page 1

Avec les nouvelles fonctions dans extgraph, genlib a du soucil a se faire ... enfin il conserve encore une bonne avance pr les programmeurs non nostub ...

pr les autres, la main est-elle passée?

NON.... c'est pas vrai... depuçis quelques jours, on n'entendait plus parler de la guerre Nostub vs Kernel...
Tu vas pas nous relancer ça ......

Pitié, un monde en paix... :-)

c pas une guerre je trouve mm qu'une concurrence est la bien venue pr faire avancée tt ca

>nEUrOne:

>pr les autres, la main est-elle passée?

Oui.
Le _nostub est le mode de programmation des TI-89/92+ du futur. Les kernels n'ont eu à l'origine pour but que de faciliter la transition à partir de Fargo et sont donc, même si JM essaye de faire progresser le but avec Universal OS, dépassés maintenant.

>enfin il conserve encore une bonne avance pr les programmeurs non nostub ...

Dans quel domaine?
Dans certains domaines, les librairies statiques ont même dépassé genlib. Notamment en la flexibilité lors de l'affichage des sprites (4 couleurs plutôt que 3, pas de halo blanc artificiel obligatoire autour des gros sprites, routines en des tailles autres que 16*16: 16*x, 8*x, 32*x, 8x*y, ...).
Dans d'autres, elles l'ont rejointe. Par exemple, Thomas Nussbaumer a ajouté des possibilités de synchronisation aux routines de niveaux de gris de TIGCCLIB.

Ceci dit, je n'aurais absolument rien contre une version en librairie statique de genlib, ce qui donnerait la possibilité de choix aux programmeurs en _nostub+librairies statiques. Évidemment, ceci nécessiterait un travail d'adaptation puisque les impératifs d'optimisation ne sont pas les mêmes pour les librairies statiques et dynamiques. Pour une librairie dynamique, il faut songer à la taille globale de la librairie et donc limiter le nombre de fonctions. La flexibilité ne peut être obtenue qu'en rendant les routines elles-mêmes plus flexibles et donc on doit faire un choix entre flexibilité et vitesse. Dans une librairie statique, il faut veiller à la taille de chaque fonction. Il faut donc augmenter au maximum le nombre de fonctions pour avoir une fonction adaptée pour chaque spécialité. Une librairie statique peut être en même temps très flexible et très rapide si elle contient de nombreuses fonctions spécialisées. Une autre différence est l'interdépendance des fonctions: pour une librairie dynamique, on épargne de la place si on la maximise, tandis que pour une librairie statique, on a intérêt à la minimiser pour éviter que l'utilisation d'une seule fonction entraîne la nécessité d'en inclure plusieurs autres qu'on n'utilise pas. Ces différences font qu'il n'est pas facile de convertir une librairie dynamique en librairie statique. Je comprends donc que PpHd ne veuille pas faire ce travail de conversion, mais je pense que genlib risque de tomber dans l'oubli tôt ou tard s'il ne passe pas par cette étape.

moi, je l'attend cette version ...

ben moi j'utilise Extgraph ET Genlib

Ca fait longtemps que je me suis pas battu avec Kevin
Let's have a new great fight !
(Private joke)

>progresser le but avec Universal OS, dépassés maintenant.
Ah bon.

>Dans certains domaines, les librairies statiques ont même
>dépassé genlib. Notamment en la flexibilité lors de
>l'affichage des sprites (4 couleurs plutôt que 3,
>pas de halo blanc artificiel obligatoire autour
des gros sprites, routines en des tailles autres que
>16*16: 16*x, 8*x, 32*x, 8x*y, ...).
Tu as le chic pour transformer un avantage en inconvenient.
C bien tourne.
Mais bon, heureusement que tu programmes pas des jeux
Avec toi, les graphismes des jeux tripleraient en taille.

>Dans d'autres, elles l'ont rejointe. Par exemple,
>Thomas Nussbaumer a ajouté des possibilités de
>synchronisation aux routines de niveaux de gris de TIGCCLIB.
Cool. Ca fait 2 ans que je l'ai fait.

>Ceci dit, je n'aurais absolument rien contre une version en
>librairie statique de genlib, ce qui donnerait la possibilité de choix aux programmeurs en _nostub+librairies statiques.
>Évidemment, ceci nécessiterait un travail d'adaptation puisque les impératifs d'optimisation ne sont pas les mêmes pour les librairies statiques et dynamiques. Pour une librairie
>dynamique, il faut songer à la taille globale de la librairie et donc limiter le nombre de fonctions. La flexibilité ne peut être obtenue qu'en rendant les routines elles-mêmes plus
>flexibles et donc on doit faire un choix entre flexibilité et vitesse. Dans une librairie statique, il faut veiller à la taille de chaque fonction. Il faut donc augmenter au maximum le
>nombre de fonctions pour avoir une fonction adaptée pour chaque spécialité. Une librairie statique peut être en même temps très flexible et très rapide si elle contient de nombreuses
>fonctions spécialisées. Une autre différence est l'interdépendance des fonctions: pour une librairie dynamique, on épargne de la place si on la maximise, tandis que pour une librairie
>statique, on a intérêt à la minimiser pour éviter que l'utilisation d'une seule fonction entraîne la nécessité d'en inclure plusieurs autres qu'on n'utilise pas. Ces différences font
>qu'il n'est pas facile de convertir une librairie dynamique en librairie statique. Je comprends donc que PpHd ne veuille pas faire ce travail de conversion,
A peu pres d'accord, suaf que genlib ne fait aucune concession niveau vitesse.
Ce que ne fait pas ExtGraph...

>mais je pense que genlib
>risque de tomber dans l'oubli tôt ou tard
>s'il ne passe pas par cette étape.
Par qui ?
De plus en plus de monde utilse genlib, mon vieux, faut te faire une raison.

Ok. Bientot je vais releaser les resultats du match Genlib VS Extgraph.
Pour le moment j'ai entre 80% et 300% de vitesse en plus.

les 2 modes doivent exister, moi aussi je programme pratiquement qu'en nostub, mais je trouve le mode kernel bien pratique quand mm
et donc au 2 modes leurs librairies propres

Oué, les resultats ... ce sera interessant.

en tt cas, manque du texturing dans ExtGraph et puis un zoom, c ce que je reproche principalement, sinon c fun ExtGraph...

(le nostub c quand meme plus souple)

arf...
Le garnd combat : qui gagneras ???
PpHd ou Kevin ?


lol

moi j'utilise ni ExtGraph ni Genlib

Universal OS n'est pas dépassé !!!

Non mais c'est pas vrai de dire des conneries aussi grosses que ça !


Ça fait des mois que je dis à Thomas Nussbaumer de faire une librairie nostub pour les niveaux de gris. Et non, il continue de vouloir faire du static. Et dire que la technique de NSPIRIT pourrait être remplacer les niveaux de gris actuels (pour les HW1 surtout).

Laisse tomnber, ce sont des fans su static
Ils veulent tout dans leur programme, et rien ailleurs.
S'il pouvait se passer de tios, il le ferait

>nEUrOne: en tt cas, manque du texturing dans ExtGraph et puis un zoom, c ce que je reproche principalement

Il manque un zoom???
Extrait de la documentation de ExtGraph:

Sprite Scaling Routines
Courtesy of Jim Haskell (jimhaskell@yahoo.com)
[routines slightly modified (and bugfixed) to fit the needs]
[...]

Pour le texturing, il y a FAT Engine. C'est une librairie dynamique (car ses fonctions sont énormes et il y a cette maudite limite de 64 KO), mais en _nostub.
En tout cas, le texturing (et le 3D en général) ne fait pas partie des objectifs de ExtGraph.

>JM: Ça fait des mois que je dis à Thomas Nussbaumer de faire une librairie nostub pour les niveaux de gris. Et non, il continue de vouloir faire du static.

Les niveaux de gris de TIGCCLIB ont toujours été statiques et ils le resteront.
L'overhead pour l'appel d'une librairie dynamique serait presqu'aussi grand que les routines elles-mêmes.
Et c'est facile de recompiler un programme. Ça m'a pris 5 minutes de réassembler mes 3 TSRs pour les mises à jour de h220xTSR et je l'ai déjà fait 3 fois. Et je ne pense pas qu'il existe des routines qui nécessitent plus de recompilations que les programmes anti-protection.

Et puis franchement, personnellement j'en ai marre de "Missing lib: xyzlib". Je tiens d'ailleurs à préciser qu'il n'y a pas de kernel sur mes 2 calculatrices. (Désolé JM, mais j'ai dû faire un peu de place sur ma TI-89 et Universal OS a dû partir.)

"xyzlib"
Connait pas.
C'est quoi comme lib ?

C'est un exemple.

Si tu préfères que j'utilise des wildcards standard: "Missing lib: *lib". Tu comprends mieux là?
[edit]Edité par Kevin Kofler le 08-08-2001 à 15:49:57[/edit]

>PpHd:

>Tu as le chic pour transformer un avantage en inconvenient.
>C bien tourne.

Il est où l'avantage de routines inflexibles?

La vitesse? Si Thomas Nussbaumer avait plus de temps libre et qu'il avait le temps de l'optimiser autant que genlib, ExtGraph pourrait être au moins aussi rapide que genlib.

La taille? genlib est loin d'être optimisée en taille! Pour la taille des données, cf. la réponse suivante.

>Mais bon, heureusement que tu programmes pas des jeux
>Avec toi, les graphismes des jeux tripleraient en taille.

Tripler en taille?
plane 0, plane 1 (3 niveaux de gris + 1 transparence comme dans genlib): 2 planes
plane 0, plane 1, masque (4 niveaux de gris + 1 transparence comme dans ExtGraph): 3 planes
rapport: 3/2 = 1,5 =/= 3

Si on menait ta logique jusqu'au bout, on ferait un écran tout blanc ou tout noir, on l'appellerait un jeu à 1 couleur et on épargnerait 100% de la taille des sprites.
[edit]Edité par Kevin Kofler le 08-08-2001 à 16:11:19[/edit]

>PpHd:

>>Dans d'autres, elles l'ont rejointe. Par exemple,
>>Thomas Nussbaumer a ajouté des possibilités de
>>synchronisation aux routines de niveaux de gris de TIGCCLIB.
>Cool. Ca fait 2 ans que je l'ai fait.

J'ai bien dit "rejointe".

>A peu pres d'accord, suaf que genlib ne fait aucune concession niveau vitesse.

... et donc tes routines sont inflexibles.
Dans une librairie dynamique, pour ne pas augmenter énormément la taille globale de la librairie, on est obligé de faire un choix entre vitesse, flexibilité ou un compromis.
Une librairie statique peut être très flexible sans surcharger et ralentir les fonctions car seules les fonctions utilisées par le programme en question seront chargées sur la calculatrice.

>Ce que ne fait pas ExtGraph...

1. Ce n'est que la version 0.86.
2. Thomas Nussbaumer fait le mieux qu'il peut faire en le peu de temps libre qu'il a. Et les différences de vitesse ne sont pas aussi gigantesques que tu dis. J'ai mesuré que genclib est 34% plus rapide que la version actuelle de ExtGraph. Je ne sais pas d'où tu sors tes 300%.

>Il est où l'avantage de routines inflexibles?
Quelles sont les routines inflexibles ?
Les routines d'extgraph ?

>La vitesse? Si Thomas Nussbaumer avait plus de temps libre et qu'il avait le temps de l'optimiser autant que genlib, ExtGraph pourrait être au moins aussi rapide que genlib.
C'est toujours bien de rever.
Mais etant donne que TiGcc sort parfois du code en )2 comme ca :
moveq #0,d0
lsr.l d0,d1
J'en doute beaucoup.

>La taille? genlib est loin d'être optimisée en taille!
>Pour la taille des données, cf. la réponse suivante.
Bof.
100 fonctions, et 16Ko, je trouve pas que ca soit enorme

>>Mais bon, heureusement que tu programmes pas des jeux
>>Avec toi, les graphismes des jeux tripleraient en taille.
>Tripler en taille?
Me suis trompe. Merci de me corriger.


>Si on menait ta logique jusqu'au bout, on ferait un écran
>tout blanc ou tout noir, on l'appellerait un jeu à 1
>couleur et on épargnerait 100% de la taille des sprites.
Alors je ne te conseilles pas de suivre la logique que tu m'a
sois disant emprunte jusqu'au bout.
Surtout que ces 3 couleurs + halo valent sans
aucun probleme les 4 couleurs + masque.
C'est meme mieux puisque ca prend moins de place
et que ca evite de le precalculer.
As-tu teste au moins le rendu visuel ?

Et Kevin, arrete de te faire plus idiot que tu n'est.
Genlib est meilleure qu'extgraph.
Si tu veux pas l'utiliser parce qu'elle necessite un
kernel, c ok. Mais critique pas genlib !

Bon, j'ai la solution a tous ces prob de nostub ou non ...

i) J'ouvre un poulet
ii) Je prend ses entrailles
iii) Je lit
iv) et voici ce qui y est ecrit: "Un jour quelques programmeurs qui en auront marres créeront une 2 API 100% compatibles faisant la 2D pr l'une et la 3D pr l'autre ..."
v) Je me reveille en sueur de ce rêve torride ...

>PpHd:
>Quelles sont les routines inflexibles ?
>Les routines d'extgraph ?

Non, les routines de genlib, fixées à 16*16 (sauf les big_sprites, mais ExtGraph permet d'utiliser des routines optimisées pour 32*x avec des sprites 32*64, et puis les big_sprites de genlib ont ce halo bizarre que tu as mis pour rendre les sprites de Chrono plus nets) et avec seulement 3 niveaux de gris.
Fais-tu exprès de ne pas comprendre?

>C'est toujours bien de rever.
>Mais etant donne que TiGcc sort parfois du code en )2 comme ca :
>moveq #0,d0
>lsr.l d0,d1
>J'en doute beaucoup.

Qui a dit que ExtGraph restera toujours en C? Il y a déjà quelques fonctions en assembleur.

>Surtout que ces 3 couleurs + halo valent sans
>aucun probleme les 4 couleurs + masque.

Mais c'est totalement artificiel! Et donc la qualité du graphisme est inférieure. (Je retiens un graphisme réaliste de plus haute qualité qu'un graphisme artificiel.) Et je ne parle pas de la vitesse perdue à calculer le halo.

>Et Kevin, arrete de te faire plus idiot que tu n'est.
>Genlib est meilleure qu'extgraph.

C'est ton avis subjectif.
Mon avis à moi est qu'une librairie flexible (ExtGraph) est meilleure qu'une librairie inflexible (genlib).
Et s'il te plaît arrête de nier que genlib est inflexible. Tu dis toi-même à plusieurs reprises que les jeux doivent être programmés pour genlib dès le début et qu'il est très difficile de convertir un jeu existant vers genlib. Une librairie flexible, elle, permet de convertir n'importe quel jeu pour l'utiliser.

>Si tu veux pas l'utiliser parce qu'elle necessite un
>kernel, c ok. Mais critique pas genlib !

Ce que je critique dans genlib est son inflexibilité.
Et le fait de nécessiter un kernel est également un désavantage. Le fait d'être une librairie dynamique aussi, même si tu utilisais la méthode de FATlib.

Quelques conseils pour les versions futures de genlib:
* convertis-la en une librairie statique
* 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.)

>>s'il ne passe pas par cette étape.
>Par qui ?
Par la conversion en une librairie statique. (cf. ci-dessus)

Kevin, si tu n'as presonnellement aucun besoin d'utiliser des progs qui utilisent des librairies, et si tu n'as que des progs inférieurs à 24 ko (ou si tu utilises un lanceur/explorer), et ..., je ne le critiquerai pas !!

Mais saches que pour certains, ce n'est pas le cas. Je suis persuadé qu'en ignorant Universal OS, certains passent à côté de quelque chose qui pourrait leur être utile.

Personnellement, je ne conçois pas d'avoir une calc sans les avantages que me fournissent mon kernel.

Alors arrête de critiquer ce kernel qui cherche à gagner de la place en mémoire à sa façon (je suis persuadé que sur une bonne partie des calculatices, ça vaut le coup) et à corriger des bugs (ou supprimer des limites) d'AMS.
[edit]Edité par JM le 08-08-2001 à 16:57:07[/edit]

Oui. Les kernels c'est très bien. Ca facilite la tâche du programmeur, et permet une adaptation plus rapide et simultanée des programmes en cas de changements internes dans l'AMS.
Vive UniversalOS, et genlib.

Et puis on gagne de la place avec des libs, nan ? Si plusieurs progs utilisent ExtGraph, la somme de leurs taille doit dépasser la somme taille de GenLib + ces programmes en mode kernel.

>Thibaut: Et puis on gagne de la place avec des libs, nan ? Si plusieurs progs utilisent ExtGraph, la somme de leurs taille doit dépasser la somme taille de GenLib + ces programmes en mode kernel.

Si les programmes utilisaient ExtGraph toute entière, oui. Mais en pratique, c'est loin d'être le cas. (Il y a beaucoup de routines dans ExtGraph qui ne seront pas utilisées par la plupart des programmes: fonctions de sprites en noir et blanc et/ou avec AND ou OR - la plupart des programmes utilisant les fonctions de type GraySprite*MASK, zoom, FloodFill ...) En pratique, on gagne presque toujours de la place par rapport à Universal OS + genlib (+ genclib pour les programmes en C).

Mouai je suis pas convaincu, m'enfin je le trouve bien pratique le mode Kernel. C'est le bordel pour ceux qui font des jeux de plus de 24 ko... Nan ?


Et puis pourquoi les OS (Window$, Linux, MacOS, TOS (Atari), ...) fonctionnent tous sur le principe du kernel+libs+relocations. C'est pas parceque c'est mieux ????? Pourquoi sur TI tu tiens à faire l'inverse ?

>Non, les routines de genlib, fixées à 16*16
C fait pour.
Et ca n'a rien d'inflexible.

>(sauf les big_sprites, mais ExtGraph permet
>d'utiliser des routines optimisées pour 32*x
>avec des sprites 32*64,
elles ne sont pas optimisees.

> et puis les big_sprites de
>genlib ont ce halo bizarre que tu as mis pour
>rendre les sprites de Chrono plus nets) et avec seulement 3 niveaux de gris.
>Fais-tu exprès de ne pas comprendre?
Fais-tu expres de ne pas comprendre que C'EST BIEN MIEUX POUR LA QUALITE VISUELLE !


>Qui a dit que ExtGraph restera toujours en C? Il y a déjà quelques fonctions en assembleur.
ExtGraph impose la convention C d'appel.

>Mais c'est totalement artificiel! Et donc la qualité du graphisme est inférieure. (Je retiens un graphisme réaliste de plus haute qualité qu'un graphisme artificiel.) Et je ne parle pas
>de la vitesse perdue à calculer le halo.
Le temps perdu a calculer le halo est inferieur
au temps perdu par la non-optimisation d'extgraph.

>C'est ton avis subjectif.
C'est mon avis suite a mon bench perso ou Genlib offre de 87% a plus de 300% de vitesse en plus.

>Mon avis à moi est qu'une librairie flexible (ExtGraph) est meilleure qu'une librairie inflexible (genlib).
Ca n'a rien a voir.
Je te parle de performances.

>Et s'il te plaît arrête de nier que genlib est inflexible.
>Tu dis toi-même à plusieurs reprises que les jeux doivent être programmés pour genlib dès le début
>et qu'il est très difficile de convertir un jeu existant vers genlib. Une librairie flexible, elle,
>permet de convertir n'importe quel jeu pour l'utiliser.
Et c'est au detriment de la performance.
Ce qui est chiant c'est de refaire les graphs

>Ce que je critique dans genlib est son inflexibilité.
Forcement. C'est une dynamqiue qui impose des contraintes
et qui offre de meilleures perforances.
On peut pas critiquer les perfs, alors on critique autre chose.
A savoir que l'on ne peut pas faire ce que l'on veut.
Non, dans un environnmeent de developement il y a des contraintes et genlib est plus qu'une lib graphique,
c'est un environnement de devleopement de jeux.

>Et le fait de nécessiter un kernel est également un désavantage.
Pkoi ? Parce que tu n'as pas de kernel.
Moi j'en ai 2 sur ma calc

>Le fait d'être une librairie dynamique aussi,
>même si tu utilisais la méthode de FATlib.
Je sais que tu aimes pas les dynamiques et moi j'aime pas les statiques.
C'est pas la peine d'essayer de me faire changer d'avi.

>Quelques conseils pour les versions futures de genlib:
>* convertis-la en une librairie statique
C non.

>* 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

>la plupart des programmes utilisant les fonctions
>de type GraySprite*MASK, zoom, FloodFill ...)
Et pas de plane ?
Pas de key scanning ?
Pas de lignes ?
Pas de cercles ?
C'est pauvre ;(

PS. T'es en forme, aujourd'hui, quel match !
>>s'il ne passe pas par cette étape.

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 !

>Thibaut:
>C'est le bordel pour ceux qui font des jeux de plus de 24 ko... Nan ?

Il suffit de cliquer sur Compress File et de rentrer un nom de fichier pour le fichier compressé (IDE) ou d'utiliser l'option -pack avec le nom du fichier compressé (ligne de commande). Total: 10 s.

>Et puis pourquoi les OS (Window$, Linux, MacOS, TOS (Atari ), ...) fonctionnent tous sur le principe du kernel+libs+relocations. C'est pas parceque c'est mieux ????? Pourquoi sur TI tu tiens à faire l'inverse ?

Exception notable: DOS. Et contrairement aux autres systèmes que tu cites, DOS a été conçu pour des systèmes avec peu de mémoire.

Je trouve:
* qu'il faut utiliser les fonctions du système sans ajouter d'autres librairies dynamiques. C'est pourquoi j'utilise Mingw32-CRTDLL (utilise la runtime CRTDLL.DLL livrée avec Windows) plutôt que Cygwin, par exemple.
* qu'il est inutile de réécrire les fonctions du système (comme on le fait trop souvent avec AMS, surtout dans les librairies "standard" des kernels). Sous Windows, ce sont les DLLs livrées avec Windows. Sous Linux, ce sont les fonctions du kernel uniquement. (Je ne considère pas la LIBC comme partie du système puisqu'il y en a plusieures et que l'on peut les linker statiquement.)
* que pour toute fonction non appartenant au système d'exploitation, les librairies statiques sont plus adaptées, en raison des avantages que je n'ai pas envie de répéter pour la nème fois.
[edit]Edité par Kevin Kofler le 08-08-2001 à 17:40:05[/edit]

>PpHd:

>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]