XLib v1.00 HARDER BETTER FASTER STRONGER - Page 3

il devait pas sortir aujourd'hui le TBO ?

Si.. comme le logiciel de sprite..
J'ai deja programmer toute la nuit.. mais ca a pas suffit
Patience.. ca va arriver... et je precise que c'est pas une concurence au genialle tbo de FZ!

J'ai fait un bench. Xlib en mode kernel, ben c pas facile a faire, mais j'y suis arrive (au prix d'un demi-douzaine de patch de xlib).

Ensuite les resultats :
+ spr16 : Genlib/x : 4000 spr/s (moins de 1% de difference) (3200 spr /s pour graphx)
+ lignes: Genlib : 1200 ligne/s / X : 400 lignes/s
Je vais tester bientot les pixels, les cercles, les disques, et surtout en bench beaucoup plus interressant ou je mesurerais non pas le fps, mais le nombre de sprite moyen par frame en double scrolling differentiel + sprites.

c'est tout a fait normal que les fonction 2d soit plus lente.. elles sont codé en C (utilisant les routines de pxls...
ce sera surment identique pour cercle et elipse.. je ne peux pas m'avancé..
Elles sont prevu pour des effets pour les jeux quand ca ne demande pas une vitesse extraordinaire...

Si tu pouvais mettre les sources du bench pour que zieute un peu merci.

J'ai pas la source sur cet ordi mais sur l'autre. Desole. Je pense pas avoir fait de conneries dans le bench pourtant. Je le finis d'abord.

>Lignes: Mais dans Gen, elles sont meme prevus pour faire des jeux devant aller tres vite (Cf cf).

Bof.. c'est pas indispensable je pense...
Enfin peut etre qu'elles seront passer en asm...

oué et peut-etre même ce soir ... mais en tt cas, 400/s ca suffit même (je pense) pour la pluspart des jeux ... nan?

Ben, des routines de cercles (par exemple) rapides, ça peut être utile pour des effets d'éclairage : un rond clair autour d'un perso, sur fond noir, pour le mettre en valeur.
Il me semble d'ailleurs que c'est fait dans CF (ça fait longtemps que j'y ai pas joué, alors je sais plus trop, mais je crois que c dans CF que j'ai vu ça)

Pas besoin d'une super rapidité pour ca...

>> + spr16 : Genlib/x : 4000 spr/s (moins de 1% de difference) (3200 spr /s pour graphx)

Je suis plutôt bien placé la différence de FPS ne doit donc pas être si grande que ça

lol.. quand meme.. et puis il faut voir comment le bench est fait...

et bien cela montre que le bench est pas si mal pour Xlib (routine de sprite, le plus utilisé ds des jeux comme plate forme ou RPG).

Attendons d'autre bench (Kevin ?), pour vérifier tout cela

TiMad : 3200/4000, c'est pas ça qui va diviser la vitesse d'un jeu par 2... La différence de vitesse est insensible.

Thibeau: La différence entre (X|Gen) et graphx est équivalente à la différence entre graphx|Extgraphlib...

Apres tout depend ce que l'on veut..

il me semble que Kevin est en vacances en Grèce pr encore en gros deux semaines.
(enfin, c ce que j'ai cru comprendre du forum de la TICT...)

Oui, je crois que c ça.
Peut-être qu'à son retour il voudra en faire un

J'ai jamais remis en cause le bench de pphd... je dis juste qu'il faut que je vois la source pour savoir sur quelles caracteristiques, il a bencher les fonctions...

Bon j'ai mis a jour XSpriteEditor pour pouvoir charger sauvgarder un bmp...
demain (enfin aujourd'hui) je ferai l'editeur de pic.

#74 : Et après tu dis que la différence de vitesse entre le DrawLine de Gen et celui de X est négligeable.

Parce que tu n'utilises pas de routines de ligne quand tu a besoin d'une grande puissance graphique...

Sinon j'ai encore fait une nouvelle version de XSpriteEditor (v3.00) qui cette fois gere le fait que l'on peut laisser le bouton gauche pour desiner un sprite..

Je sais cela à pris du temps mais j'ai du reprogrammer tout de a à z jusqu'a la gestion des messages pour obtenir ce resultat.. (j'ai pas trouver la doc pour utiliser le composant windaube..
En dl sur le site XLib...

Cool

"J'ai fait un bench. Xlib en mode kernel"

!!ATTENTION!! si l'on veut un bench significatif, il fatu bencher Gen en mode nostub qui est plus lente ...

Voila XPicEditor v1.00 est en dl.

Je ne programme qu'en mode kernel, desole.
Et le bench, c :

for(j = -16 ; j < 128+16 ; j++)
for(i = -16 ; i < 240+16 ; i++)
{
gl_put_sprite(i,j,0); // Xmmmm // GX machin
count++;
}

Sachant qu'en mode kernel on appelle la fonction qu'avec un jsr.. et qu'en nostub.. c'est différent.. la différence de cycle se faire resentir.
si il y a 10 cycle d'ecart, ca fait 40000 cycles d'avance pour Genlib.. ce qui est beaucoup je trouve...
La version Genlib nostub tournera certainement moins vite de 200-300 sprite/s...(voir plus tard...).

Donc ce bench n'est pas représentatif...
En revanche pour les coordonnées, je suis ok.

>10 cycle d'ecart,

Ca ne fait pas beaucoup a l'arrivee ! Mettons que ca baisse d'1% (au maximum !)
Une routine 16x16 fait environ 7000 cycles !

je ne pense pas.. t'as qu'a convertir le bench en nostub, ca doit pas trop te dérangé puisque c'est ta lib et que les appels sont les mêmes...
d'ailleur ton dernier bench public était nostub...

C'etait parce qu'aggnar me l'avait demande. Mais tu peux compiler en kernel/nostub tous mes progs !

PS: xlib.h est buggue si on compile avec l'option -mregparm !

Buggée... je pense plutot que c'est pas compatible avec le format dll.. parce que sinon je vois pas d'ou ca vient..

Une routine de sprite 16x16 ne prend que 3Kcycles il me semble...