_X_Lib - Page 4

S'engueuler pour des conneries vraiment...

c po des engueulades à part entière !
Et puis, à mon avis c une bonne chose : ainsi, chauqe concepteur essaye de faire mieux que l'autre => ça pousse les codeurs de libs à optimiser encore plus et toujours plus

Tu n'as pas encore l'habitude de ces enguelades et de ces sous-entendus.
C'est du genre : 'je te tiens, tu me tiens par la barbichette. Le 1er de nous deux qui rira aura une tapette'.
C'est tout

OUé, perso, je commence à m'y faire, voila pkoi je commence à trouver ça marrant...

Bne moi je fais ca depuis le debut (Et TiMad aussi. Si vous saviez depuis le temps ou on s'enguelent pour des prunes )

c'est vrai que vous êtes toujours sur le dos de l'un de l'autre /D /D

clair !!!

Et puis, avant, ct contre Kevin

>PpHd

Comparons:

>XTimerOn(0);
>XL_Setup(plan1,plan2,plan3,annim);
>for (i;i<750;i++) XL_XY(i,sin(i));
>XStep(10,logo);
>for (i;i<300;i++) XA_D16x16(1,1,logo);

5 lignes.

>unsigned short number = 0;
>PLANE *P1 = gl_init_plane(mat1, tiles, 5);
>PLANE *P2 = gl_init_plane(mat2, tiles, 6);
>PLANE *P3 = gl_init_plane(mat3, tiles, 7);
>P1->x = P1->y = 0;
>P2->x = P2->y = 0;
>P2->x = P2->y = 0;
>int s1 = 1, s2 = 2, s3 = 4;
>
>while (!gl_key_pressed())
>{
>gl_update_vscreen_16(P1);
>gl_update_vscreen_16(P2);
>gl_update_vscreen_16(P3);
>
>P1->x+=s1;
>if (P1->x > 32 || P1->x < 0)
>s1 = -s1, P1->x+=s1;
>P1->y = 5 + 4*gl_sin[5*P1->x/8];
>
>P2->x+=s2;
>if (P2->x > 64 || P2->x < 0)
>s2 = -s2, P2->x+=s2;
>P2->y = 10 + 9*gl_sin[4*P2->x/3];
>
>P3->x+=s3;
>if (P3->x > 128 || P3->x < 0)
>s3 = -s3, P3->x+=s3;
>P3->y = 30 + 25*gl_sin[P3->x];
>
>Ready();
>gl_put_plane(P1);
>gl_put_fgrd_plane(P2);
>gl_put_fgrd_plane(P3);
>gl_put_sprite_16(P1->x+10, P1->y+20, (number++)/4 & 3);
>Wait15();
>SwapBuffer();

32 lignes non vides.

Alors, c'est quoi la librairie la plus évoluée? Si ce que dit TiMad est vrai, c'est clairement XLib à mon avis.

Et Kevion semble être du côté de TiMad...
ça va bientît repartir sur Kernel vs Nostub, non ?

Oui, devine pourquoi je suis plutôt du côté de TiMad...

pour le débta qui va bientôt reprendre ?

Kevin qui vient pas trop relancer le debat

C'est reparti pr une franche rigolade, et deq argumentations de fou !!!

Nbr de plan infin=> ca sert a quoi sachant que tu est limité par le hard.. LOL
=> Ton exemple ne gere pas les animations... ce sont des Plans a sprites fixes il me semble? sinon pardon...

De toute maniere... je ne cherche pas a vendre ma lib... et je conseillerai toujours extgraphlib si elle arrive a satisfaire leurs exigences....

Sinon tout ce que j'ai dit est vrai... je peux meme rajouter qu'a chaque refresh du moteur il appele une fonction Xmain() ou l'on met ce que l'on veut dedant ....

Heureusement que tu ne cherche pas à "vendre" ta lib.
Il manquerait plus que ça


(lol)

"Vendre" voulais dire la vanter a tout pris pour que des personnes l'utilisent....

Au fait tu ferais mieux de programmer ton jeu... que ce soit avec Xlib ou genlib je m'en fou, mais au moins que tu l'avances

timad> j'ai commencé la doc et donc le nvo package sortira dans qq jours au prorgamme :

- lignes (normles, wu, clippées)
- elliptises
- maths (calcul sur matrices et trigo surtout)

bon, c pas grand chose mais j'ai pas encore eut le tps de tester d'autres fonctions ..

Le débat est assez interessant je trouve pis c vrai que c pas vraiment des engueulades mais plutot des prises de becs

n'empeche que pour le programmeur C, c plus facile de prorgammer nostub/xlib que nostub/extrgaph

je parle pas trop de genlib car ca xlib n'est pas encore assez evoluée je pense et ca depend franchement de l'envergure du jeux que l'on compte faire ...

Pour moi le dernier post de kevin est un connerie, je le dis clairement, ce n'est pas parce que ca fait 5 lignes que c'est mieux, bien au contraire.

Et pourquoi ça serait une connerie??? C'est bien ça l'intérêt d'une librairie: fournir des fonctions pour éviter qu'on ait à tout reprogrammer à chaque fois. Donc plus il faut écrire du code soi-même, moins il y a d'intérêt à utiliser une librairie.

Oui, devine pourquoi je suis plutôt du côté de TiMad...
J'adore
Mais ou prennent ils toutes ces répliques plus hilarant les uns que les autres
[edit]Edité par HEvil le 27-02-2002 à 03:07:36[/edit]

l'utilité de cette lib repose quand mm en la simplicité de l'utilisation et sa rapdité biensur ..

c pr ca que je suis tout a fait d'accord avec kevin sur ce qu'il a dit !

attention neurone j'ai pas dit que 5 lignes n'est pas bien pour faire un moteur de jeu, mais que dans l'absolu ca ne veut rien dire la remarque de kevin...

TiMad 107> je sais, j'avais juste voulu "jouer" un peu avec les mots
et je peux po coder pdt la semaine sans TIGCC et VTI, c dur
Ca sera avec XLib (aucun doute, c déjà bien parti ) mais je sais pas qd ça sortira, vu que je l'avanance pas super super vite...
Je veux faire bien => j'essaye de faire un truc qui foire pas, sur lequel j'ai pas besoin de revenir 10 fois avant que ça marche... => c po rapide à coder

Hevil 111> ben, ils réfléchissent...
Ce type de débat est souvent assez instructif...
Du temps du débat nostub vs kernel, g appris pas mal de choses comme ça.

>freka: attention neurone j'ai pas dit que 5 lignes n'est pas bien pour faire un moteur de jeu, mais que dans l'absolu ca ne veut rien dire la remarque de kevin...

Pourquoi? La librairie la plus évoluée est celle qui nécessite moins de lignes de code pour un effet donné. Et tu n'oseras pas contester que 5<32, n'est-ce pas?
[edit]Edité par Kevin Kofler le 27-02-2002 à 12:03:15[/edit]

En fait je l'ai deja expliquer, je cherche a eloigner le plus possible le programmeur de jeu du moteur graphique...
en effet en C, on perd enormement de temps avec les appels de fonctions asm... etc... donc niveau rapiditée, j'ai pensé faire un moteur qui gere tout automatiquement avec des flags.... ce qui permet un rapidité maximale...

Sinon j'avais compiler une routine de pxlput qui fait plus de 0.1MPxl/sec. l'inconvegnant, c'est que le Gplan est contenu dans le programme....
Donc ca prend pas mal de place... SAUF si le programme est compressé ce qui tiendra en moins de 30 octets....

Je pense pas que ce soit utile une telle rapidité.. et je le repete, je favoriserai avant tout la simplicité de la lib...
De plus le moteur est assez souple... il permet de faire quasiment tous les jeux que l'on veut tres facilement....

De toute maniere il est evident que niveau rapidité, je suis oblige de ne pas la bouster a font, sinon elle sera beaucoup trop gourmande en ram ...

Faire plus rapide que genlib c'est facile... (routine de preshifting).
Mais je n'y tiens pas ( du moins pas en utilisant de telles methodes...)et je proposerai de vraies routines 4 grays avec mask....

J'ai juste encore une hesitation:
Est ce que la lib utilise des fonctions programmées et compilées, ou alors crée elle meme les fonctions...
dans la 2eme solution, ca prend de la ram, mais c'est plus rapide.. ( semi preshifting)...

les routines de pixels ne sont pas à mes yeux celles qui ont le plus besoin d'être optimisées... mieaux vaut optimiser à MORT celles de sprites d'abord

pr la question, ça dépend combien de RAM ça bouffe...

C'est simple.... ca fait genre du 5ko voir beaucoup plus ....

5ko, c'est supportable, je penses...
mais bcp plus, ça devient bcp moins suportable...
(vu que certains progs ont besoin de bcp de mem !)

N'oublie pas la protection des HW2 pour tes routines auto-générées!