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

Hum, c'est quand meme bien vrai ce que dit nitro

'tain mais qu'est ce qu'elle vous a fait Xlib ???

pkoi vous passez votre temps à vous engueuler en la critiquant ???

ça vaut pour toi aussi TiMad, tu fais une lib (dont je me sers) pour faire une lib et en fair profiter les progs C nostub ou juste pour battre Genlib ????

Bossez dans votre coin, et arrêtez ça !!! ça fait un peu pitié.

Et puis je pense qu'Xlib vient de XBox

Pim89 a écrit :
'tain mais qu'est ce qu'elle vous a fait Xlib ???

pkoi vous passez votre temps à vous engueuler en la critiquant ???

ça vaut pour toi aussi TiMad, tu fais une lib (dont je me sers) pour faire une lib et en fair profiter les progs C nostub ou juste pour battre Genlib ????
Bossez dans votre coin, et arrêtez ça !!! ça fait un peu pitié.

Que veux-tu ? Il raconte tellement de bobard, Timad/JS/Ndhpp/a que c'est dur de le croire

ben si vous y croyez pas ne répondez pas. Après vous vous cassez mutuellement, au lieu de vous filer des coups de main. C'est dommage je trouve.

Il a pas demander un coup de main que je sache ? Et je lui ai jamais refuse de l'aider.

Ce que j'aime bien c'est la force des arguments:
L'histoire des pseudo, on va jusqu'a me reprocher d'avoir comme initiale JS ... c'est quand meme fort.
Ensuite, on critique Xlib alors qu'elle a pour but de faire des projet en C sans avoir besoin de fichier externe, elle rentre dans l'esprit nostub, contrairement a genlib.
Pour HpMad, je vois pas le raport... c'est comme timaniac ou autre... mais la encore monsieur pense avoir encore raison.

J'AI JAMAIS NIER L'AIDE QUE KEVIN M'A APPORTER, TOUT COMME SBIBI ET SQUALE92!! (ils seront dans la liste des credits..)
Et je vois pas en quoi je devrai avoir honte... ha oui Monsieur Nitro a appris a programmer seul, sans aucun bouquin.. juste en recompilant des sources))


L'histoire des bench, monsieur comprendra, si monsieur sait programmer en asm, qu'il y a une difference entre la theorie de cache ling ... et la pratique on calc.. en effet, faut toujours bencher une routine pour comparer, mais ca monsieur a pas l'air de le comprendre... et si les bench sont fait a partir de Genlib, c'est parce que c'etait ma reference de depart!

Puis pour l'histoire des bench, les bench de pphd sont completement erroné..
c'est simple pour faire gagner genlib, il fait afficher plus de 200 sprites en dehors de l'ecran ce qui ne se passe jamais dans un jeu.. mais comme dans genlib, la fonction redirige directement vers un rts, ca va en effet tres vite puisqu'elle ne fait rien..
ON BENCH UNE ROUTINE SUR LES COORDONNEES OU ELLE EST LA PLUS LENTE c'ad sur l'ecran... mais ca pphd le sait tres bien, mais son probleme c'est que si il l'applique, genlib devient beaucoup plus lente que prevue


XLib est OPEN SOURCE, elle a pour but de presenter des fonctions RAPIDES pour faire des JEUX, et elle est actuellement la plus RAPIDE, alors arretez de me gaver... surtout que vous ne connaisez meme pas toutes les fonctions qui n'ont pas encore eté presentées!

Puis pour l'originalite, c'est simple, Xlib presente tous les formats que l'on desire:
Sprite normal, transparent (blanc), maské ... contrairement a genlib.. alors arretez de me gaver avec ca..

TiMad a écrit :
Puis pour l'histoire des bench, les bench de pphd sont completement erroné..
c'est simple pour faire gagner genlib, il fait afficher plus de 200 sprites en dehors de l'ecran ce qui ne se passe jamais dans un jeu.. mais comme dans genlib, la fonction redirige directement vers un rts, ca va en effet tres vite puisqu'elle ne fait rien..
ON BENCH UNE ROUTINE SUR LES COORDONNEES OU ELLE EST LA PLUS LENTE c'ad sur l'ecran... mais ca pphd le sait tres bien, mais son probleme c'est que si il l'applique, genlib devient beaucoup plus lente que prevue

Cela prouve bien que tu n'a jamais fait de jeu.
Et mon vieux, arrete de dire qu'on bench lorsque gnagnagna. On benche sur des conditions reelles de fonctionnement. Pour avoir un apercu reel, il vaut imperativement prendre en compte le clipping. Dans des jeux comme SMA, cf, total, pokered, 30% des sprites sont hors ecrans. D'ou une perte de temps si on les affiche quand meme.
Et meme sans ca, Genlib reste bien devant, j'en suis desole. J'ai aussi teste

XLib est OPEN SOURCE, elle a pour but de presenter des fonctions RAPIDES pour faire des JEUX, et elle est actuellement la plus RAPIDE, alors arretez de me gaver... surtout que vous ne connaisez meme pas toutes les fonctions qui n'ont pas encore eté presentées!

Desole, la plus rapide reste Genlib. Forcement que l'on ne les connait pas ces fonctions. La nouvelle version n'est pas encore sorti ! Peut etre un jour elle sera la plus rapide mais j'attends pour cela.
Surtout qu'il faut faire en plus l'indirection de sprites, le clipping grossier, la correction de coordonnees a ta routine Et en plus elles possedent un biais qui ralentit le tout.

Puis pour l'originalite, c'est simple, Xlib presente tous les formats que l'on desire: Sprite normal, transparent (blanc), maské ... contrairement a genlib.. alors arretez de me gaver avec ca..

Halo ?
Et les sprites 64x64 clippes.... On peut encore attendre longtemps la

le but de XLib c'etait avant tout une librairie graphique nostub plus rapide que ExtGraph quand mm ..

pis XLib ne vient pas de XBox ...

Tu veux savoir les conditions reelle dans un jeu:
Utilisation de XDrawLevel => les 3 4 5 plan sont clippés a la methode traditionnelle => donc pas de perte de vitesse.
il reste que les sprites des bonhommes missiles etc .. ce qui est loin de faire 30 % mas bon c'est pas grave tu te defends comme tu le peux.

Je continue a dire que Xlib est la plus rapide car c'est la stricte verité, cf topic genlib.

Bon ceci etant dit, si tu veux ton halo, c'est vraiment pas dure a faire...

TiMad a écrit :
Utilisation de XDrawLevel => les 3 4 5 plan sont clippés a la methode traditionnelle => donc pas de perte de vitesse.
il reste que les sprites des bonhommes missiles etc .. ce qui est loin de faire 30 % mas bon c'est pas grave tu te defends comme tu le peux.

T'as vraiment rien compris a Genlib toi. Si je le dis, c'est que je le sais.
Ca peut monter a 80% meme.

Je continue a dire que Xlib est la plus rapide car c'est la stricte verité, cf topic genlib.

Mais oui, mais oui. Vas-y fais toi plaisir.
Tu peux rever.

>PpHd:
>Et au passage, ne le croyais pas lorsqu'il dit qu'x-lib est plus rapide.
>Les seuls benchs officiels c'est moi, et genlib est bien plus rapide.

Tes benchs ne sont pas plus officiels que ceux de TiMad, vu qu'ils manquent d'objectivité exactement de la même manière que ceux de TiMad (vous avez tous les 2 un intérêt à défendre). Et puis vu la manière de laquelle tu avais traffiqué les résultats des benchs genlib/ExtGraph (tu disais qu'il y avait une différence de vitesse de plus de 80% alors que c'était moins de 60% ou moins de 40% - selon ce qu'on prenait comme référence, et selon si on mesurait "différence de vitesse" comme "différence de temps d'exécution" ou comme "différence de fréquence d'exécution" -, mais en tout cas pas 80, j'ai des doûtes sur tes benchs, désolé...

Non mais de toute maniere M. pphd pense qu'il est le seul a faire des bench valable, car pour lui, un bench n'est valable que si genlib est la plus rapide...
Or dans le bench que je t'ai montre qui est open source, il est tres nette que Xlib est plus rapide que genlib... alors un jour ou l'autre il faudra sortir de ton monde.. d'ailleur Xlib est open source ca te permettra de bouster un peu tes routines ... bien que celle de Xlib sont encore pas mal optimisable, elles sont quand meme plus rapide que tes routines (Mega lol)

Au fait question bannal, si j'ai 750 enemis qui sont hors de l'ecran.. tu comptes toujours les dessiner? ))

TiMad a écrit :
Au fait question bannal, si j'ai 750 enemis qui sont hors de l'ecran.. tu comptes toujours les dessiner? ))

Je vois qu'il faut t'expliquer au moins 36 fois les choses avant que tu comprennes (comme c'etait le cas pour la transparence)... les 750 ennemis comment tu peux savoir qu'ils sont hors de l'écran ? bah faut faire un test sur les coordonnées. Avec Genlib pas besoin c'est la routine de sprite qui le fait, avec Xlib le programmeur est obligé de mettre des tests explicites, et en C c'est lent.
Toujours pas compris ?

Je ne suis pas d'accord. Si le test est fait dans la routine, il faut quand-même passer les paramètres à la routine (soit dans des registres, soit sur la pile, mais ça prend du temps en tout cas), appeler la routine, et la routine doit faire un rts. Si le test est fait dans le programme, on épargne l'appel de fonction. Et il n'y a pas grand chose à optimiser dans un test comme if (x>-32). Ça donne un cmp.x et un bxx si on optimise correctement et GCC génère exactement ça. Par exemple:
int x=ngetchx(),y=ngetchx();
if ((x>-32) && (y>-32) && (x<240) && (y<128)) puts("test")
est compilé en (j'ai supprimé le début, qui correspond à ngetchx et qui ne nous intéresse donc pas ici):

[...]
	cmp.w #-32,%d3
	jble .L2
	cmp.w #-32,%d0
	jble .L2
	cmp.w #239,%d3
	jbgt .L2
	cmp.w #127,%d0
	jbgt .L2
	pea .LC0
	jbsr puts
	addq.l #4,%sp
.L2:
[...]

où les jbxx sont optimisés en bxx.s comme nous le montre ttdasm:

[...]
cmpi.w   #0xFFE0,%d3          /* [0x94 (148)] 0c 43 ff e0       */
ble.s    __LB8  /*+0x20*/     /* [0x98 (152)] 6f 1e             */
cmpi.w   #0xFFE0,%d0          /* [0x9A (154)] 0c 40 ff e0       */
ble.s    __LB8  /*+0x1A*/     /* [0x9E (158)] 6f 18             */
cmpi.w   #0xEF,%d3            /* [0xA0 (160)] 0c 43 00 ef       */
bgt.s    __LB8  /*+0x14*/     /* [0xA4 (164)] 6e 12             */
cmpi.w   #0x7F,%d0            /* [0xA6 (166)] 0c 40 00 7f       */
bgt.s    __LB8  /*+0xE*/      /* [0xAA (170)] 6e 0c             */
pea      (__L70,%pc)          /* [0xAC (172)] 48 7a ff c2       */
jsr      0xCE                 /* [0xB0 (176)] 4e b9 00 00 00 ce */
addq.l   #4,%a7               /* [0xB6 (182)] 58 8f             */
__LB8:
[...]

Comment voulez-vous optimiser cela???

(PpHd / Nitro) / TiMad: c'est fini les batailles de bac à sable ?
Je ne cherche pas à juger qui a raison, et qui a commencé, mais je trouve que les deux parties manquent d'objectivité (surtout TiMad, j'ai peur).

Je suis d'accord avec Kevin et Pim89.
Le C n'est pas si lent que ça... il me semble que c'est un des langages les plus proches de l'assembleur.
Juste un truc dans ce qu'assemble GCC: "jsr 0xCE /* [0xB0 (176)] 4e b9 00 00 00 ce */": c'est pas super, ça ! GCC ne fait pas de bsr dans ce cas-là ? (ce qui, si je ne me trompe pas, économiserait une relocation et 2 octets).

Absolument d'accord avec toi.

tt facon, c pas possible d'être objectif, pphd et nitro veulent mettre en avant leur projet .. surtout depuis le portage en nostub, pis TiMad aussi il est pour son projet ..

mais c kler que le ton n'est pas top ... mm kevin vs pphd c plus cool

ça fait un peu trop "violent" comme débat...
il faudrait trouver un juge objectif, qui sache utiliser à la fois Xlib et Genlib.

Envoyez des routines pour faire de bench à un même groupe objectif et qu'on n'en parle plus!
De toute façon ce ne sont pas 10 sprites par secondes sur 4000 qui vont révolutionner le jeu sur TI.

En ce qui concerne le débat:

Kevin Kofler a dit:
Je ne suis pas d'accord. Si le test est fait dans la routine, il faut quand-même passer les paramètres à la routine (soit dans des registres, soit sur la pile, mais ça prend du temps en tout cas), appeler la routine, et la routine doit faire un rts. Si le test est fait dans le programme, on épargne l'appel de fonction.

Tu peux développer stp je ne te suis pas.
Quand la routine fait le test, les arguments ne sont pas à passer en plus puisqu'ils sont déjà là (coordonnées du sprite).
Et puis il faut de toute façon appeler la routine et donc faire un rts pour afficher le sprite.
Niveau utilisateur c'est quand même plus pratique si la routine d'affichage s'occupe du test. Bon forcément ça va faire perdre quelques sprites par secondes mais bon... Sinon ils seront perdus dans le prog alors...

>XDanger: Juste un truc dans ce qu'assemble GCC: "jsr 0xCE /* [0xB0 (176)] 4e b9 00 00 00 ce */": c'est pas super, ça ! GCC ne fait pas de bsr dans ce cas-là ? (ce qui, si je ne me trompe pas, économiserait une relocation et 2 octets).

GCC ne peut pas savoir où est puts. Ça peut être à plus de 32 KO de distance. Ce n'est qu'au moment du linking où la position du fichier contenant puts est fixée. C'est pour ça qu'un saut absolu est généré.


>Ximoon:
>Quand la routine fait le test, les arguments ne sont pas à passer en plus puisqu'ils sont déjà là (coordonnées du sprite).

Qui te dit qu'ils ne sont pas autre part que dans les registres où les veut la routine? En RAM par exemple.

>Et puis il faut de toute façon appeler la routine et donc faire un rts pour afficher le sprite.

Oui, mais seulement si le sprite est visible. Alors que chez PpHd, il y a un appel de fonction pour tous les sprites invisibles également.

>Niveau utilisateur c'est quand même plus pratique si la routine d'affichage s'occupe du test.

#define XGSprite16x16_boundtest(_x_,_y_,_GSprite_) ({short __x__=_x_;short __y__=_y_;if ((__x__>-16) && (__x__<240) && (__y__>-16) && (__y__<128)) XGSprite16x16(__x__,__y__,_GSprite_);})

>Bon forcément ça va faire perdre quelques sprites par secondes mais bon... Sinon ils seront perdus dans le prog alors...

Justement, la méthode de PpHd fait perdre du temps alors qu'il prétend qu'elle est plus rapide!!!

Il y a un bogue. &;&; au lieu de && ...

Et puis arrêtez de reposter toutes les sources de moins de 5 lignes que je poste avec la coloration syntaxique, ça ne vaut vraiment pas le coup (sinon je le ferais)!

Mais comparons ce qui est comparable alors!
Quand on dit faire du clipping, il faut en faire, pas à moitié!

Et en poussant ton raisonnement à l'extrême (pas d'appel de fonction, pas de rts), on va se retrouver avec que des macros et ça irait plus vite...

Quand on fait une lib, qu'est-ce qui est le plus important, la satisfaction personnelle de l'auteur (ouais chwui l'meilleur) ou le confort des utilisateurs?

Et pour finir avec cette histoire de bench, pourquoi non plus ne pas tester ces routines dans toutes les situation?
C'est à dire faire une routine qui affiche un sprite depuis (-32,-32) ou (-31,-31) j'usqu'à (239,127) ou (240,128)?
La même routine, on ne change que la fonction appelée et puis basta!

Enfin, pour un jeu vraiment rapide, c'est pas en C qu'il faut le faire...

Ximoon a écrit :
Mais comparons ce qui est comparable alors! Quand on dit faire du clipping, il faut en faire, pas à moitié!

Ceux qui sont de cet avis-là n'ont qu'à utiliser ma macro (que je permets évidemment à TiMad d'utiliser pour _X_Lib).

Et en poussant ton raisonnement à l'extrême (pas d'appel de fonction, pas de rts), on va se retrouver avec que des macros et ça irait plus vite...

N'as-tu toujours pas compris que si je dis ceci, c'est pour répondre à PpHd et Nitro qui prétendent que c'est plus rapide de faire le test dans la routine de sprites??? Ce que je viens de dire montre bien que ce qu'ils prétendent est faux!!! C'est tout ce dont il s'agit ici! Il ne s'agit pas du tout de tout faire en macro! J'ai l'impression que tu fais exprès...

Quand on fait une lib, qu'est-ce qui est le plus important, la satisfaction personnelle de l'auteur (ouais chwui l'meilleur) ou le confort des utilisateurs?

Je ne vois pas ce que ça change pour les utilisateurs si la fonction qu'ils appellent est vraiment une fonction ou une macro (celle de mon post n°80)!

J'ai adapté le bench de TiMad pour utiliser ma macro et pour aller de x=-50 à x=300 et de y=-50 à y=200 et voilà les résultats:

XLib: 9020 sprites/seconde
GenLib: 8692 sprites/seconde

Je pense que l'argument du test des coordonnées est définitivement battu avec ça.

(Je précise que j'ai testé sur TI-92+ HW2 et que j'ai testé la version kernel vu que l'interface _nostub de genlib est boguée et ne marche pas sur HW2 AMS 2 non patchée - Nitro va corriger ça.)

J'ai essayé en _nostub avec une version de gennlib.a que Nitro vient de m'envoyer et qui marche à peu près. Voilà les résultats:

XLib: 9030 sprites/seconde
GenLib: 8625 sprites/seconde

Ça ne change pas beaucoup des résultats en kernel (même si on voit clairement que l'interface _nostub de genlib est plus lente, alors que pour _X_Lib, le mode _nostub va à peu près à la même vitesse - même plus vite, mais c'est probablement une imprécision de mesure - que le mode kernel).

Et dans les 2 cas, _X_Lib est la plus rapide.

Kevin Kofler a écrit :
N'as-tu toujours pas compris que si je dis ceci, c'est pour répondre à PpHd et Nitro qui prétendent que c'est plus rapide de faire le test dans la routine de sprites??? Ce que je viens de dire montre bien que ce qu'ils prétendent est faux!!! C'est tout ce dont il s'agit ici! Il ne s'agit pas du tout de tout faire en macro! J'ai l'impression que tu fais exprès...

Il est évident que c'est plus rapide de faire le test hors de la routine, mais c'est carrément pas logique!!!

Je ne vois pas ce que ça change pour les utilisateurs si la fonction qu'ils appellent est vraiment une fonction ou une macro (celle de mon post n°80)!

Quand elle est petite, rien. Mais quand elle grossit...

XLib: 9030 sprites/seconde
GenLib: 8625 sprites/seconde

Enfin un bench potable!
Ces chiffres me semblent énormes quand même... c'est des sprites 16*16 transparents clippés?

Je pense que l'argument du test des coordonnées est définitivement battu avec ça.

Bah ouais

Et dans les 2 cas, _X_Lib est la plus rapide.

Et bien ça va allimenter le débat

>Thibaut




>Ximoon:

>Enfin un bench potable!
>Ces chiffres me semblent énormes quand même... c'est des sprites 16*16 transparents clippés?

Oui.