Plus d'excuse pour ne pas s'en servir : Xlib - Page 4

>Thibaut:

>Kevin:
Mais c'est quasiment deux fois plus que ce qu'annoncent les deux parties interressées!

Ximoon a écrit :
>Kevin: Mais c'est quasiment deux fois plus que ce qu'annoncent les deux parties interressées!

C'est parce qu'il est plus rapide de ne pas afficher un sprite que de l'afficher. Le bench de TiMad a été effectué là où il faut toujours afficher le sprite. Le mien a été effectué (à votre demande) en partie hors écran, donc le nombre de sprites "dessinés" est plus grand. En réalité, les sprites hors écran n'ont évidemment été dessinés nulle part.

Kevin> merci pour le bench.
Je pensais à quelqu'un comme toi pour le faire (je connais pas GenLib ou, du moins, je ne sias pas l'utiliser)

Pour le test de coordonnées, dans KII, il faut que je le fasse... et même si la routine clippait, il faudrait que je le fasse.
=> le fonctionnement de Xlib fait que le test est fait une fois dans mon prog, et pas une deuxième dans la fonction => gain de temps à l'exécution.
(je dois faire ce test pour avoir la possibilité de désactiver certaines choses...)

C'est bien ce que je me disait.
Mais dans ce cas on ne peut pas vraiment parler de 'sprites par seconde'.

Mais d'après toi la différence vient-elle du test de coordonnées externes ou de l'affichage lui-même?
tu peux faire le même test entre les limites de coordonnées où le sprite peut être affiché?
id est (-15,-15),(239,127) pour les sprites 16*16?

Ok, le test à l'exterieur est plus rapide (j'ai eu tord), la preuve :
En rajoutant le test sur les coordonnées à l'exterieur de l'appel genlib, on a:
Xlib: 9232 spr/s
Genlib: 9955 spr/s

Conclusion, Xlib n'est pas plus rapide

Si parce que personne n'aurait l'idée de faire le test à l'extérieur sous genlib, vu que PpHd dit que ce n'est pas nécessaire.

conclusion:
utilisons les fast_sprites de Genlib quand c'est dans l'écran
(1ko le sprite mais c'est plus rapide)

Regarde a quelle vitesse tourne SMA... est-ce vraiment necessaire d'avoir 200 spr/s de plus ? Personnellement je prefere avoir une lib pratique à utiliser qu'une lib ultra-rapide, et puis en plus ce qu'il y a de plus rapide ça reste quand meme les FAST_SPRITE de Genlib.
(sont bien marrants les nouveaux smileys!!)

ptdr Nitro.. tu va jusqu'a faire 2 fois un teste pour faire gagner Genlib dans un bench...

Le seul endroit ou Xlib est moins rapdide que genlib est pour les sprites dans le cadres des 32 pxl en dehors de l'ecran (a cause du GPlan).
Mais cette petite faiblesse de Xlib est compblée... de plus le Gplan n'est plus present dans la prochaine version.. je vais utiliser les formats classiques....

D'aillueur la prochaine version sera la derniere vesion de Xlib au niveau evolution ASM. mais j'ai malheureusement pas le temps avant la fin de l'année scolaire

>Nitro: Personnellement je prefere avoir une lib pratique à utiliser qu'une lib ultra-rapide

Pourquoi avez-vous (pas seulement toi) toujours critiqué ExtGraph alors?

TiMad a écrit :
ptdr Nitro.. tu va jusqu'a faire 2 fois un teste pour faire gagner Genlib dans un bench...
Le seul endroit ou Xlib est moins rapdide que genlib est pour les sprites dans le cadres des 32 pxl en dehors de l'ecran (a cause du GPlan).

C'est ce que je lui ai déjà dit par ICQ. Et je précise qu'avec ma macro, ce n'est qu'un cadre de 16 pixels. (Et oui, pourquoi afficher un sprite 16×16 à la coordonnée -32?)

Nitro> c'est clair

je propose un nouveau topic:
plus de raison pour ne pas s'en servir: [graphlib]!

Allez dormir, ça vous fera du bien
Bonsoir!

Extgraphlib est une lib tres bien.. elle permet de faire pas mal de chose ex: Krypton.
Mais pour des jeux tres gourmand, elle est malheureusement pas assez rapide

>> Pourquoi avez-vous (pas seulement toi) toujours critiqué ExtGraph alors?
Parceque là c'est vraiment trop lent.

Donc quand ça t'arrange, c'est "on s'en fiche des 400 sprites/seconde de différence" (c'est bien 400, pas 200), mais quand tu veux cracher sur le travail des autres (celui de Thomas Nussbaumer en l'occurrence), c'est "c'est trop lent, il y a 400 sprites/seconde de moins". Très objectif comme attitude...

erf...

extgraph est pas mal, certes, mais y'a mieux.
Comme dit un de mes profs : "L'informatique, c'est résoudre les problèmes d'une époque avec les moyens de l'époque".
=> on prend toujours le mieux qu'on ait... ou l'équivalent.

On ne prend pas forcement ce qu'il y a de mieux.. mais ce qui est le mieux adapter a notre besoin...

sinon:
FAST_SPRITE n'a rien d'extraordinaire.. si ce n'est que ca bouffe de la ram pour rien.. c'est juste une routine utilisant du preshifting!

TiMad> oué, c'est une interprétation à laquelle j'avais pas pensé... et qui est meilleure que celle que j'avais fait. merci

Kevin Kofler a écrit :
>Nitro: Personnellement je prefere avoir une lib pratique à utiliser qu'une lib ultra-rapide

Pourquoi avez-vous (pas seulement toi) toujours critiqué ExtGraph alors?

Où est-ce que j'ai critiqué ExtGraph

Tu faisais bien partie des gens qui disaient que genlib était 100 fois mieux que ExtGraph... (Je me rappelle quand tu avais parlé d'utilisation de genlib en _nostub pour la première fois - c'était pour ton projet Small, mais tu ne l'avais pas encore annoncé - que tu avais dit que ExtGraph était nul par rapport à genlib...) Malheureusement, je ne retrouve plus les topics correspondants (surtout parce que le moteur de recherche est désactivé). Et des mois sont passés entretemps, donc ma mémoire pourrait me trahir.

Kevin Kofler a écrit :
Tu faisais bien partie des gens qui disaient que genlib était 100 fois mieux que ExtGraph... (Je me rappelle quand tu avais parlé d'utilisation de genlib en _nostub pour la première fois - c'était pour ton projet Small, mais tu ne l'avais pas encore annoncé - que tu avais dit que ExtGraph était nul par rapport à genlib...) Malheureusement, je ne retrouve plus les topics correspondants (surtout parce que le moteur de recherche est désactivé).

Je n'ai jamais critiqué le travail de Thomas Nussbaumer... Il etait totalement exclu que j'utilise ExtGraph parce que j'avais besoin de plus que ça. Genlib permet d'utiliser le link, le clavier, les niveaux de gris, le scrolling des plans, le zoom, etc.. le tout avec une interface cohérente.

Nitro a écrit :
Regarde a quelle vitesse tourne SMA... est-ce vraiment necessaire d'avoir 200 spr/s de plus ? Personnellement je prefere avoir une lib pratique à utiliser qu'une lib ultra-rapide [...]

c absurde ca .. une lib plus rapide sera forcement mieux dans toutes les circonstances .. par exemple, SMA tu peux rajouter des animations en plus etc, faire un sonic plus interactif ... enfin y'a le choix ...

et c pareil pour tous les jeux !

bref, plus de cycle => plus d'animations et c ce qui va faire la difference maintenant pour les jeux

Et pourtant il y en a qui milittent sur le gameplay plutôt que sur la beauté des décors.
On n'y arrivera jamais...

oué mais je parlais a un gameplay equivalent ...

faire une animation c'est pas afficher plus de sprites en temps réel mais pooséder plus de sprites en RAM, ça n'a pas trop de rapport avec la vitesse.
Tu change un chtit numéro dans ta table du décors et hop! le sprite change!
C'est vraiment pas ça qui ralentit un jeu.

ben ca te le ralenti forcement ...

pis en tt cas ca te fais gagner du cycle donc c mieux ca t'en laisse plus pour tes autres routines ..

Question de point de vue ...

heu la rapidité de sma... faut rappeller que sma fait un "scrolling" de plus de 4 pxls il me semble...
des routines plus rapide permettent de le faire par exemple en 3 ou 2 .. ce qui rend le jeu plus fluide.. car niveau rapidite, on en gagne encore plus avec XDrawLevel.
Pour ce qui est des annimations, ca peut permettre de rajouter un pas dans l'annimations... ce qui peu etre plus joli...

Mais c'est pas pour autant que je critique SMA .. (je vous vois deja deja venir...)

kler ... SMA est tres bien, c indégniable