Scroller une map pour un jeu de voitures - Page 1

Bonjour tout le monde,
J'aimerais programmer un jeu de course qui se déroullerait dans une map qui dépasse la taille de l'écran, et qui demanderait donc un scrolling... (cf schémas ci-dessus)
Est-ce possible avec graphx ?, sinon avec quoi et comment ?

Merci d'avance

Oui, c'est possible avec graphx. Utilise les fonctions de sprites clippées.
Si possible, découpe ta map de 320x200 en carrés de 16x16 (ou 32x32), et n'affiche que ceux qui ont une partie visible.

Sinon, genlib te permet de faire ça plus facilement puisque la lib te propose directement des fonctions prévues pour cette situation.

Si cela ne dérange pas sasume et comme je vois que ton buffer fait 320x200 pixels je peux te donner la routine que j'utilise pour arkanoid?

je pense que c possible avec grahx.
http://alineasofts.free.fr/graphx/documentation.htm

sinon, utilise Genlig, Xlib, ou Extgraph

geogeo :
Si cela ne dérange pas sasume et comme je vois que ton buffer fait 320x200 pixels je peux te donner la routine que j'utilise pour arkanoid?

Ouai ça serait super sympas

Sasume :
Oui, c'est possible avec graphx. Utilise les fonctions de sprites clippées. Si possible, découpe ta map de 320x200 en carrés de 16x16 (ou 32x32), et n'affiche que ceux qui ont une partie visible.

Si je remplie le buffer d'affichage "map" entierement,
n'aurais-je plus a y toucher dans la boucle princlipale ?
Si oui, pour copier le buffer "map" au buffer principal, j'utilise la fonction "GX_Copy(map)", avant d'utiliser "GX_DisplayWorkBuffer()". Mais comment faire pour décaller l'image de "map" (x--||x++||...) ?

Tu ne peux pas, la fonction que tu utilises copie par octets.

tu peux tjs faire 2 boucle for imbrikees... pour afficher les tiles
et pis apres
tu fe x++ ou x--

Oui, c'est possible avec graphx. Utilise les fonctions de sprites clippées.
Si possible, découpe ta map de 320x200 en carrés de 16x16 (ou 32x32), et n'affiche que ceux qui ont une partie visible.
Sinon, genlib te permet de faire ça plus facilement puisque la lib te propose directement des fonctions prévues pour cette situation.

Comment ça Graphx permet de travaillier sur des buffers de 320x200 pixels, bref supérieur à 240x128 pixels?

Orage contacte moi par mini-messages si tu veut la fonction de scrolling!...

Comment ça Graphx permet de travaillier sur des buffers de 320x200 pixels, bref supérieur à 240x128 pixels?

Sasume parlait de routines de sprites _clippées_, donc par conséquent il parlait d'afficher les sprites directement à l'écran (240x128) et pas dans un buffer 320x240 (parce que sinon il n'y a pas besoin de clipping).

geogeo> il n'est pas obligé d'utiliser un buffer temporaire de sa taille perso.
Il lui suffit d'afficher sur un buffer de taille normale les sprites visibles. Simplement.

oui bien sûr. J'avais pas compris ça au début.

oui c vrai ca fera un gain de place et de rapidite assez important
en effet
pourkoi afficher des sprites(ou coca) ke l'on ne vois pas?

L'intérêt, c'est que si tes tiles sont assez petits (8x8 ou 16x16), le fait d'afficher tout l'écran d'un coup permet de réduire de beaucoup le coût du scrolling. Si tu passes par un buffer intermédiaire, l'affichage de sprite sera très rapide (alignement horizontal de 8 ou 16 pixels), c'est en réalité le scrolling qui prendra une bonne partie du temps. Et tu n'as pas besoin de remplir tout le buffer 320x200, tu peux prendre un buffer un peu plus grand que l'écran qui représente l'endroit autour de la voiture (256x128 si tu as des tiles 16x16), donc il n'y a pas de surcoût lié à cela. En plus, si tes tiles ne sont pas animés, tu peux carrément éviter de dessiner les sprites dans le buffer intermédiaire.

ok merci...
En fait, c'est moi ou la fonction GX_PutSprite08_..() marche mal avec graphX ?
: On ne voit qu'une partie du sprite 8 bits...

Heu...
Puis-je profiter du sujet pour poser une question?
En fait, comment vous feriez vraiment pour faire un scrolling simple en imaginant qu'on a une map assez grande (genre celles de Mario) et que je ne veux pas utiliser un méga-buffer qui ferait 1600x800 pixels pour les maps standardes.
Et ce en utilisant par exemple les routines ScrollLeft et cie de extgraph?
Si on ne défile qu'à droite, un algo de m consisterait simplement à faire un ScrollRight à chaque fois puis à redessiner la dernière colonne de tiles, qui se trouverait en fait entre les positions x 175 à 160. Mais c'est sale.
Ce que j'ai fait dans Mariole n'est pas mieux (loin de là), il consiste à tout redessiner les tiles à chaque fois (en utilisant deux variables scrlX et scrlY qui contiennent un offset entre 0 et 15, puis baseX et baseY qui contient le nombre de motifs défilés dans chaque direction). Bien entendu qu'il faut alors utiliser des routines de sprites clippées, et comme si ça ne suffisait pas, j'ai du faire une routine de copie de tampon vers l'écran spéciale, sinon sur TI92 on voyait des déchêts à droite (routine qui consomme 20% de temps processeur, ce qui n'est pas étonnant vu mon niveau).
Puis pour les sprites ils ont une valeur absolue, ça évite de devoir tous les décaler lorsque l'écran défile, rend plus facile leur gestion et la détection de collisions avec le décor. Est-ce une bonne solution?

orage> C'est sûrement toi. Poste le code de ton utilisation.

Brunni> La technique que tu utilises n'est pas si mauvaise. Avec des ScrollRight (plutôt ScrollLeft), ça peut marcher aussi, mais ce n'est pas pratique si ton arrière-plan est animé ou si tu as plusieurs niveaux de scrolling.
Sinon, la technique utilisée par genlib (cf doc de genlib) est assez puissante.

J'ai essayé de scroller une map contenu dans un écran virtuel de 240*128 avec extgraph, mais j'ai eu quelques problèmes...
Le scrolling marche dans un sens (<-), mais dés que les bits sortent a gauche de l'écran, (<0), elles sont perdues... Alors quand je scroll dans l'autre sens (->) : il n'y a plus rien...

Quelqu'un a une solution svp ? (voir source)
// C Source File // Created 08/11/2003; 22:50:56 #define USE_TI89              // Compile for TI-89 #define OPTIMIZE_ROM_CALLS // Use ROM Call Optimization #define SAVE_SCREEN           // Save/Restore LCD Contents #include <tigcclib.h> #include "extgraph.h"         // Include All Header Files // Main Function void _main(void) {      void *ecran = malloc(3840);//Allocation mémoire d'un écran virtuel      short i=0;//Compteur      unsigned char herbe[] = {0x88,0xAA,0x22,0x88,0xAA,0x22,0x88,0x22};//Sprite 8bit d'herbe      short x=0, y=0;//Sert au remplissage du buffer "ecran"      PortSet(ecran, 239, 127);            /*Remplissage du buffer "ecran"*/      ClrScr();           for(x=0 ; x<232 ; x+=8)           for(y=0 ; y<120 ; y+=8)                Sprite8_XOR(x, y, 8, herbe, ecran);                 /* Affichage du buffer écran */           memcpy(LCD_MEM, ecran, 3840);      ngetchx();           for(i=0 ; i<50 ; i++)//Scrolling <-      {           ScrollLeft240(ecran, 100);           memcpy(LCD_MEM, ecran, 3840);           for(x=0 ; x<3000 ; x++)//Ralentir                for(y=0 ; y<150 ; y++);      }      ngetchx();      for(i=0 ; i<50 ; i++)//Scrilling ->      {           ScrollRight240(ecran, 100);           memcpy(LCD_MEM, ecran, 3840);           for(x=0 ; x<3000 ; x++)//Ralentir                for(y=0 ; y<150 ; y++);      }                 ngetchx();      PortRestore();      free(ecran);           return; }

Merci

Bah oui c'est un peu normal... Tu décale le buffer vidéo, tout ce qui en dépasse est perdu, faut réafficher...
J'ai même pas envie de donner une solution vu que j'aime pas le "voilà ma source corrigez-là" que tu pratique un peu trop souvent.

Vertyos
: J'ai même pas envie de donner une solution vu que j'aime pas le "voilà ma source corrigez-là" que tu pratique un peu trop souvent.

Je ne crois pas avoir dit "voilà ma source corrigez-là", mais plutot "voilà ma source, si il y en a que ça interesse regardez là" : Je ne force personne et ça ne dérange personne.


De + vraiment pas la peine de laisser des messages comme ça :

Vertyos
: Tu décale le buffer vidéo, tout ce qui en dépasse est perdu

Je te REMERCIE VRAIMENT POUR CETTE SUPER INFORMATION, mais je crois que j'ai un peu compris quand meme :

Orage
: dés que les bits sortent a gauche de l'écran, (<0)

Et puis c'est pas un forum d'entre aide ? C'est un peu normal que les anciens aident les nouveaux (sans avoir des préjugés hautains (je ne vise absolument personne (sauf Vertyos))

Brunni > je crois que c'est la méthode la plus simple, on réaffiche tout à chaque cycle. Par contre c'est sur que ça bouffe bcp de temps. Mais dans Mario le décort est animé (il me semble), donc t'as pas trop le choix.

Tu peux pas non plus faire un giga buffer, trop gros. Et avec des routines de "vrai" scroll, à un moment où un autre tu serais obliger de réafficher de nouveau sprite (car tu affiches au début que ceux qui sont dans la zone de proximité du héro), donc bon, ça ferait des effets de vitesse de décort bizarre ect. Enfin faut essayer, je l'ai honnetement jamais fait.

orage
: Je te REMERCIE VRAIMENT POUR CETTE SUPER INFORMATION, mais je crois que j'ai un peu compris quand meme :

Si tu as compris alors pourquoi tu poses la question...
Fais un test sur TI-92, tu auras une autre surprise...

je poses la question pour savoir comment y remédier

Vertyos
: faut réafficher...

Et au fait, tu as testé sur TI-92+ ?

Oui, j'ai le meme probleme...
Mais si il faut tout réafficher, ça doit etre chaud d'optimiser assez pour optenir un résultat assez rapide...

Sur TI-92+, est-ce que tu as remarqué que la bordure de droite aussi avait ce "problème" ?
Tu ne dois pas tout réafficher, seulement la colonne de pixels qui manque.
Ça ne devrait pas être trop lent...

d'accord je vais essayer ça merci de t'on aide

orage
: Je te REMERCIE VRAIMENT POUR CETTE SUPER INFORMATION, mais je crois que j'ai un peu compris quand meme :

Eh bah écoute apparement ça se voit pas. J'ai donné la solution dans mon post en plus, maintenant si t'es pas capable de la comprendre, va te pendre. Mais la prochaine fois que je me prends une réponse comme ça alors que j'ai donné la solution, ça va smasher légerement plus méchament...

Pen^2 :
je pense que c possible avec grahx.
http://alineasofts.free.fr/graphx/documentation.htm
sinon, utilise Genlig, Xlib, ou Extgraph

pas XLib