>Alors, c'est quoi la librairie la plus évoluée? Si ce que dit TiMad est vrai, c'est clairement XLib à mon avis.
Moi j'ai file un exemple 100% fonctionnel et ouvert.
Sinon j'aurais pu faire un :
void move(PLANE *P) { P->x++; P->y = 10+10*gl_sin[P->x]};
BOOL stop(void *data) { return gl_key_pressed() || (PLANE *) gl_deref_data(3)->x < 110); }
...
gl_setup_engine(4,{Plane, mat1, tiles, 32, NULL, anim},{Plane, mat2, tiles, 64, NULL,anim}, {mat3, tiles, 128, move,anim}, {SPRITE, tile, 10, {10,10}, anim2});
gl_main_loop(stop);
Mais je prefere le premier. Je croyais que tu preferais la flexibilite des libs, Kevin ?
>Oui, devine pourquoi je suis plutôt du côté de TiMad...
Pkoi ? La version nostub arrive grace a ....
>Nbr de plan infin=> ca sert a quoi sachant que tu est limité par le hard.. LOL
Pour les calcs overlockes qui peuvent en afficher 5 sans pbs.
>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...
Pas d'accord (dans l'absolu du moins).
Je doute que faire une fonction pxlput a donf soit une priorite par ailleurs
>Faire plus rapide que genlib c'est facile... (routine de preshifting).
Ah ! Mais genlib gere depuis 3 ans le preshifting
>dans la 2eme solution, ca prend de la ram, mais c'est plus rapide.. ( semi preshifting)...
mais bien plus chiant.
>mieaux vaut optimiser à MORT celles de sprites d'abord
Mieux vaudrait deja apprendre aux programmeurs a s'en servir aussi.
>N'oublie pas la protection des HW2 pour tes routines auto-générées!
Certes, mais c'est pas si penible.