Un nioob de Genlib - Page 5

Et squale now tu est membre de la T³ !

Il le mérite.

Bon je vais aller voir un peu la concurence et nioober un peu avec Gen

./120> si, le fait qu'il ne soit pas fini
(il ne fait que les formats de sprites que j'utilises... je n'ai pas cherché les autres )
(mais une fois les formats connu, c super simples à rajouter : juste une paire de copier-coller : le skelette du prog est entierement fait, de meme que la reconnaissance de parms, et autres)

Et squale now tu est membre de la T³ !

et bien, il semblerait que oui #fier#
j'étais marqué comme B-testeur dans la page des contacts (je le savais limite meme pas ), et TechNic m'a demandé si ça me disait que Krypton soit présent sur le site T3 ; j'aurai été fou de refuser

geogeo> merci
(cela dit, j'ai pas le niveau de PpHd ; j'ai encore BEAUCOUP de boulot pr en arriver là (et je ne vise meme pas si haut : je fais parti ce ceux qui considèrent qu'il ne peut y avoir qu'un seul PpHd ))

(par contre, le fait est que j'utilise pas genlib pour K1... et encore moins pr KII )

(cela dit, j'ai pas le niveau de PpHd ; j'ai encore BEAUCOUP de boulot pr en arriver là (et je ne vise meme pas si haut : je fais parti ce ceux qui considèrent qu'il ne peut y avoir qu'un seul PpHd ))

Tu n'es pas seul.

(par contre, le fait est que j'utilise pas genlib pour K1... et encore moins pr KII )

T'as encore plus de merite, parce qu'avec genlib t'as un drawlevel ca aurait ete trop simple de faire K2

JackosKing
: 1. bon deja la rapidité de Extgraphlib je la connais puisque JackieChan et moi discutons par minimessage (lui au moins admet certains defaults de Extgraphlib).

Qui disparaissent petit à petit.

2. Extgraphlib ne peut pas etre aussi rapide que gen et X pour le simple fait que vous ne fetes pas de difference entre certains shift (ce que toute bonne lib graphique fait..)

Nous avons l'intention de proposer des fonctions Sprite16 30% plus rapides pour Ext2 qui optimiseront le shift.

3. Le nombre de fonctions, parlons en, bon alors on a le droit entre sprites clippés, non clippés (supper... autant dire que ca sert a rien ..).

Ça permet de gagner de la place (et un peu de vitesse, mais surtout de la place).

En plus si vous utilisez votre seul routine rapide (drawlevel, pour laquelle j'admet qu'elle est plus rapide que celle de gen, mais surment pas celle de X!),

Ne parlons pas trop vite, il n'est pas sûr qu'à l'utilisation, nos fonctions soient plus rapides que celles de genlib (pour divers détails que je ne veux pas prendre la peine d'expliquer ici), je pense que la rapidité sera équivalente à celle de genlib (v 0.99.22.b pas-small)

alors tout est en double, puisque vous ne reprennez pas les routines de sprites.. trop bien alors pour un jeu on a besoin d'un draw level, de 4 routine de sprite en transparence, 1 routine de masque, la le programme fait avec Extgraphlib est enorme..

Ce n'est pas faux. Mais en même temps, les fonctions d'extgraph sont relativement petites (et suffisamment rapides pour afficher 10 objets à l'écran par frame).

Et puis je n'ai toujours pas vu ton drawlevel...

En plus si vous utilisez votre seul routine rapide (drawlevel, pour laquelle j'admet qu'elle est plus rapide que celle de gen, mais surment pas celle de X!),

parlons pas trop vite, il n'est pas sûr qu'à l'utilisation, nos fonctions soient plus rapides que celles de genlib (pour divers détails que je ne veux pas prendre la peine d'expliquer ici), je pense que la rapidité sera équivalente à celle de genlib (v 0.99.22.b pas-small)

Pour le moment de totue maniere c'est pas comparable vue que pour l'utilisation d'un level annimé je suis archi lent et que pour sans annimation je suis plutot rapide

pour en rajouter sur mon convertisseur de sprites Xlib, il me manque en fait le format des sprites GTB et GN
(GTW, GM sont fait, de meme qu'un troisieme, je sais plus ce que c'est)
(et les pic correspondant sont respectivement non fait et fait)

T'as encore plus de merite, parce qu'avec genlib t'as un drawlevel ca aurait ete trop simple de faire K2

ce n'est pas une question de mérite ou autre, mais de choix
je me plait à faire ça moi-même

Kevin Kofler
:

Thibaut :
+ de registres utilisés == + de registres empilés/dépilés == plus lent format graphlib == deux pointeurs à passer == encore plus lent

Le format standard nécessite aussi le passage de 2 à 4 pointeurs. Rien ne dit que les plans sont forcément consécutifs.

Je parle justement du format "standard". J'ai dit ça pour argumenter en faveur des formats X GX Gen : ils ne nécessitent qu'un pointeur.

A mon avis le format des plans consécutifs est bien plus efficace et réduit la charge à la fois pour le programme et pour la lib. Le seul inconvénient qu'on peut y trouver est la perte de 3.8ko sur HW1, qui est vraiment négligeable (surtout face aux variables internes du TIOS un jeu qui veut vraiment économiser bcp de RAM ferait mieux de compresser les variables internes du TIOS, puis les restaurer lorsqu'il éteint la calc ou à la sortie, et en plus il peut réutiliser ces 3.8 ko...)

Pq cette perde de 3.8Ko au fait sur HW1???

Parce que sur HW1 on peut utiliser LCD_MEM ($4c00) pour faire un plan de gris sur les deux alors que sur HW2 c'est impossible.
En fait, en utilisant les 2 plans consécutifs, on peut considérer qu'on pert les 3840 octets de LCD_MEM car ils ne sont pas utilisés.

oui mais si on utilise la meme technique de buffer sur HW1 ou HW2 sa simplifie le code nan ?

On se trimbale quand meme pas un code pour HW1 et un pour HW2 quand on utilise grayOn si ??????

si

Je crois qu'on parlait de sprites avec Kevin, pas de plans

godzil> C'est du self-modifying code et ya très peu de choses qui change entre HW1 et HW2.
Néanmoins, en passant outre ce gain potentiel de 3840 octets, on pourrait réduire un peu la taille de GrayOn, et surtout la taille de toutes les routines graphiques qui, pour être compatibles avec GrayOn, doivent utiliser un pointeur sur chaque plan - ce qui permettrait aussi un gain en vitesse.
Mais les choix de l'équipe de Tigcc sont impénétrables.

Il ne faut pas non plus oublier que les routines de grays de TIGCC embarquent une interruption pour les HW1 et une autre pour les HW2.

Raahhhhhh encore une histoire de SMC.....

> Je crois qu'on parlait de sprites avec Kevin, pas de plans
OK. Sauf que pour les sprites, je ne pense qu'il y ait de format meilleur que les autres, ça dépend de la taille des sprites et de la flexibilité qu'on attend de la manipulation sur ces sprites. Le format genlib est très très bien (le meilleur possible?) pour afficher des sprites 16x16, mais si on veut faire des choses plus flexibles dessus, il est trop contraignant. Par exemple la lib graphique de GT-Basic utilisera un format de sprites assez différent, résultat le tracé de sprites sera légèrement plus lent, mais en revanche on gagnera énormément en flexibilité (collisions, SetPort, la même routine trace en noir&blanc, en 16x16, en masqué, en XOR...)

En revanche pour ce qui est des plans, je ne crois pas qu'il s'agisse d'un compromis, puisque la solution des 2 plans à la suite permet de gagner bcp en mémoire pour l'exécutable malgré la perte de RAM qui en résulte sur les qques HW1 qui restent...

Ben de toute facon, on les recupere le plan alors, c'est pas vraiment une perte.

Sinon, on parle beaucoup des nouvelles libs, mais on les voit pas. C'est normal ?

Désolé, mais il y a beaucoup de boulot.
Je suis encore en vacances pour une ou deux semaines, donc je vais essayer d'avancer encore.

> Ben de toute facon, on les recupere le plan alors, c'est pas vraiment une perte.
On le récupère manuellement, et je ne pense pas que beaucoup de jeux le fassent...

Et puis gl_window n'est quand même pas extraordinairement utile

Sinon, on parle beaucoup des nouvelles libs, mais on les voit pas. C'est normal ?

Ouai manque de motivation et puis faut que je fasse mon rapport de stage et que je prepare mon inté .. en bref les vacances c'et fait pour glander

Meuh, ca avance quand mm un peu ...

JackosKing
:

Le format standard nécessite aussi le passage de 2 à 4 pointeurs. Rien ne dit que les plans sont forcément consécutifs.

Ce n'est pas un format STANDARD, et pour reprendre tes argument, XSpriteConvert ne supporte pas le format tigcc donc il ne peut pas etre standard

Parce qu'il ne respecte pas le standard. ImageStudio etc. étaient là bien avant!

godzil
:Sur mon pc je n'ai aucun convertisseur, donc le format standard c'est celui quie st dans ma tete

Tiens, moi aussi, j'ai tapé mes sprites à la main (pour Backgammon).

squale92 :
./117> bah, vu que je codfe sous X, j'ai besoin d'un convertisseur

Encore un avantage du format standard.

Pollux
:le format des plans consécutifs

Euh, on parlait des sprites là, pas des plans!

A mon avis le format des plans consécutifs est bien plus efficace et réduit la charge à la fois pour le programme et pour la lib.

Non, on ne gagne strictement rien en simplicité.

Le seul inconvénient qu'on peut y trouver est la perte de 3.8ko sur HW1, qui est vraiment négligeable

C'est une perte totalement gratuite (elle n'apporte aucun avantage), donc stupide.

(surtout face aux variables internes du TIOS un jeu qui veut vraiment économiser bcp de RAM ferait mieux de compresser les variables internes du TIOS, puis les restaurer lorsqu'il éteint la calc ou à la sortie, et en plus il peut réutiliser ces 3.8 ko...)

Il ne peut appeler aucun ROM_CALL s'il fait ça!

godzil :
oui mais si on utilise la meme technique de buffer sur HW1 ou HW2 sa simplifie le code nan ?
On se trimbale quand meme pas un code pour HW1 et un pour HW2 quand on utilise grayOn si ??????

Si, et pour bien d'autres raisons que celle-ci! (L'interruption est totalement différente.)

mais arrete de raconter des conneries..
tu sais tres bien que le format de Gen/GX/X est meilleur... il permet certaines optimisations (que tu ne connais peut etre pas.. )
de plus il n'y a pas de standard de sprite tant que je ne l'ai pas dit! (je m'appelle KK)

squale92 :
./117> bah, vu que je codfe sous X, j'ai besoin d'un convertisseur


Encore un avantage du format standard.

avec le format standard aussi, j'ai besoin d'un convertisseur...
donc aucune différence pour moi entre le format "standard" et le format Xlib

mais fait pas oublier que le format Xlib est maintenant le format standard (je viens de le definir =

Tu code sous X squale ? tu a peur qu'on te reconnaise pendant que tu code ??