Coucou tout le monde!

Alors voilà dans ce topic on présente le moteur du jeu pour notre projet du forum: un mario.

On avait proposé comme idée d'utiliser les statplot pour obtenir un scrolling, et avoir la position des objets plus facilement.

J'ai commencé à coder et voici le résultat (Un X se balade sur le terrain, avec scroll vers la gauche lorsqu'il est à droite. Il y a maintenant une gestion des objets qui bloquent (plate formes...), et des ennemis (qui peuvent nous bloquer, nous tuer, ou bien être vulnérable dans une des 4 directions). Mario peut également faire un double saut (appuyer 2 fois rapidement sur flèche du haut)).




Voici le prgmMARIO:

Code:

Goto M // On va au menu
Lbl J

getKey->K

If Ans=45 // Si on veut quitter
Goto M

// Déplacement vertical
1=int(.001[A](max(1,B-1),13-A->ø // On teste si on touche le sol

0 // Déplacement nul par défaut

If (ø or F)(K=25 // Si on veut sauter et qu'on peut (on touche le sol ou on peut faire un double saut)
1!=int(10fPart(.01[A](B+1,13-A->F // Alors on teste si il n'y a pas d'obstacle à notre saut

B+Ans-not(ø+E->B // On saute si on veut sauter et on tombe si on doit tomber et qu'on a pas sauté

F->E // On sauvegarde si on vient de sauter
øAns->F // on sauvegarde si on vient de sauter et qu'il y avait le sol sous nos pieds (double saut possible donc)


// Déplacement horizontal
(K=26)-(A!=1)(K=24 // Si on veut se déplacer (sans sortir des limites de l'écran)

If Ans
A+Ans(1!=int(10fPart(.1^(Ans+2)[A](B,13-A-Ans->A // On se déplace s'il n'y a pas d'obstacles

If C=A and D=B // Si on ne s'est pas déplacé inutile de continuer
Goto J

If A=10 and Xmin+12-dim(L1 // Si on doit scoller (à droite de l'écran et pas au bout du circuit)
Then

prgmMSCROLL // On scroll

Else

Text(min(56,72-8D),max(2,8C-5),"    // Sinon on doit effacer mario (3 espaces)

End

Text(min(56,72-8B),8A-5,"X // On affiche mario

If D-B
Then
D-B+3
Else
C-A+2
End
int(10fPart(.1^Ans[A](B,13-A // On récupère le nombre correspondant au déplacement effectué sur la case où on se trouve (en privilégiant le déplacement vertical s'il y en a eut un).

If Ans=3 // Si ce nombre vaut 3 c'est qu'on vient de tuer un ennemi
Then

B+10(A+Xmin-1->ø // On calcule la valeur qu'on doit trouver dans la liste (sans prendre en compte le numéro de sprite)
0->[A](B,13-A // Il n'y a plus d'objet sur cette case donc on efface dans la matrice

Repeat ø=int(10L4(Ans // on cherche l'indice de l'objet dans L4
Ans+1
End

0->L4(Ans // On efface l'objet de la liste (il sera supprimé réellement au prochain scroll)

Else

Ans-2->I // Si la valeur vaut 2 c'est qu'on a été attaqué, donc on est mort

End

B->D // On sauvegarde les positions actuelles
A->C

If I and B-1 and A+Xmin+1-dim(L2 // On teste si le jeu est fini
Goto J

If B-1 and I
Then
"GAGNE
Else
"PERDU
End
Text(20,37,Ans

Pause

// Le menu (à changer bien sûr)
Lbl M
Menu("MARIO","JOUER",I,"QUITTER",0

// Initialisation des variables du jeu
Lbl I

// Pour un écran "propre"
AxesOff
PlotsOff
FnOff

// pour qu'une unité vaille 8 pxl
0->Xmin
1->Ymin
11.8->Xmax
8.8->Ymax

seq(A,A,0,43->L1 // Les absices du sol
{1,1,1,1,1,1,2,3,4,5,4,1,2,3,0,1,2,2,2,2,2,3,4,5,6,0,0,1,1,2,3,3,1,1,2,3,4,3,3,4,4,4,4,4->L2 // Les ordonnées du sol.
ClrList L4 // Liste contenant les objets immobiles (vide au départ)
{14.501,1111,15.501,1111,16.501,1111,17.302,3222,18.303,1222->L3 // Les objets
DelVar H1->G // Il n'y a pas d'objets immobiles à afficher pour l'instant, et on en est au premier objet de la liste

// On affiche le terrain
Plot1(Histogram,L1,L2
DispGraph

// Les matrices
{10,12->dim([A] // Pour la collision
Fill(0,[A]
{10,4->dim([B] // Pour un scroll facile de la matrice [A]
Fill(0,[B]

// On la rempli avec les données du sol, mais à l'envers (la 12e colonne (à droite dans la matrice) correspond en fait à la plus ancienne, celle de gauche sur l'écran)
For(ø,1,12
For(A,1,L2(ø
1111->[A](A,13-ø // 1111 car le sol est infranchissable dans toutes les directions
End
End

// Position et déplacement de mario
DelVar C1->A
DelVar EDelVar D2->B

Goto J // On va au Lbl de jeu

// on quitte
Lbl 0
PlotsOff
DelVar [A]DelVar [B]ClrList L1,L2,L3,L4

Et le prgmMSCROLL (gère le scroll comme son nom l'indique):

Code:

// Nouvelle fenêtre, avec un scoll de 4
Xmin+4->Xmin
Ans+11.8->Xmax

6->A // on change la position de mario en conséquence
5->C

{10,8->dim([A] // on tronque la matrice (les 4 dernières colonnes qui correspondent en réalité à celles de gauceh sur l'écran disparaissent)
augment([B],[A]->[A] // on en rajoute 4 vierges au début (donc qui correspondent à celles à droite de l'écran)

For(ø,8,12 // On les remplis avec les données du sol
For(W,1,L2(ø+Xmin
1111->[A](W,13-ø
End
End

If H // S'il y a des objets immobiles
Then


sum(L4>=Xmin // On compte le nombre d'objets qui sont encore sur l'écran

If Rép or Rép-dim(L4
SortD(L4 // On trie dans l'ordre décroissant, ainsi l'objet se situant le plus à gauche de l'écran est en dernière position, mais que s'il y a des objets à supprimer ou qu'il ne faut pas tout supprimer

Ans->dim(L4 // On tronque la liste (donc on supprime les termes qui sont les moins grands, se sont ceux qui ne sont plus à l'écran)
Ans->H

End

While G<=dim(L3) and Xmin+12>L3(min(G,dim(L3 // Tant qu'il y a des objets à rajouter et qu'ils sont sur l'écran

H+1->H
L3(G->L4(Ans // On rajoute à la liste d'objets à traiter

L3(G+1->[A](int(10fPart(Ans)),12+Xmin-int(Ans // On charge les propriétés de collision dans la matrice [A]

G+2->G // Le prochain objet est 2 termes plus loin

End

For(ø,1,H // On affiche tous les objets
L4(ø
Text(71-8int(10fPart(Ans)),8(int(Ans)-Xmin)+3,sub("OAT",100fPart(10Ans),1
End

// On affiche le drapeau (à changer en objet)
Line(42.9,7,42.9,4
Line(42.9,7,41.8,6.5
Line(41.8,6.5,42.9,6

Voilà pour l'instant .



Variables utilisées:
L1 (absices du terrain)
L2 (ordonnées du terrain)
L3 (liste avec les objets).
L4 (objets immobiles présents dans l'écran, à afficher à chaque scroll donc)
[A] (tile map pour gérer les collisions dans la zone affichée)
[B] (matrice vide de dimension {8,4} pour réactualiser la matrice [A])
K (touche pressée)
plot1 (terrain)
A (absice de mario)
B (ordonnée de mario)
C (ancienne absice de mario)
D (ancienne ordonnée de mario)
E (flag à 1 si mario vient de sauter, à 0 sinon)
F (flag à 1 si on vient de sauter et qu'on a la possibilité de faire un double saut maintenant, à 0 sinon)
G (pointeur sur le terme du prochain objet dans L3)
H (nombre d'objets immobiles à afficher)
I (flag à 1 si on est vivant, à 0 si on est mort à cause d'un ennemi)
Théta et W sont des variables temporaires à chaque fois.

Je pense utiliser:
L5 (les objets mobiles, à afficher à chaque tour).
I (état de mario, lorsque les objets auront été rajoutés. Pour l'instant il indique juste si mario est vivant ou mort)


Dans L3, les informations sur les objets sont codées comme suit, sur 2 termes de la liste:
premier terme: AA.ONN
deuxième terme: XXXX
A, O, N et X représentent des chiffres décimaux.

AA correspond à l'absice de l'objet
O à son ordonnée
NN à son numéro de sprite (pour l'affichage)

Le premier X (à gauche) correspond à la direction "bas", c'est a dire quand un autre objet va dessus en se déplaçant vers le bas.
Le second c'est la direction "droite".
Le troisième c'est la direction "haut".
Le dernier c'est la direction "gauche".
X vaut:
0 si l'objet est inexistant (dans la direction considérée (c'est le cas par exemple pour une plateforme qu'on peut traverser en sautant))
1 Si l'objet nous bloque (plate forme...)
2 si l'objet est mortel (un ennemi)
3 si on peut tuer l'objet (direction bas avec un ennemi par exemple)
4 si on active l'objet (un champignon ou autre)  (je n'ai pas encore codé cette partie là)

Je ne voit pas ce qu'il pourrait y avoir d'autre comme cas, mais si vous avez une idée dites toujours.

Lorsque l'objet arrive dans l'écran, le premier terme est stocké dans la liste L4, puisque celle ci gère l'affichage des objets, tandis que le second est stocké dans la matrice [A], qui gère les collisions.



Historique de réalisation:
01/11: Les objets sont gérés grâce aux listes L3/L4 et à la matrice [A]. Ils peuvent: être traversés par mario, bloquer mario, tuer mario, ou être détruits par mario. Rajout du double saut en appuyant 2 fois rapidement sur la flèche du haut.
28/10: La gestion des collisions (sol compris) se fait maintenant via la matrice [A].
26/10: L'idée de gestion des pentes est abandonnées, j'ai rajouté le déplacement d'un "X", en fonction du terrain, et le sol est géré via un statplot diagramme plutôt qu'un polygone.

Bravo!
Mais comment tu compte gèrer les pentes?

Si mario (ou un autre mob) touche le sol:
S'il veut se déplacer à droite où à gauche et qu'il y a une pente:
Je le sais parce que l'ordonnée où il veut aller est différente de celle où il se trouve. Donc j'adapte son déplacement (et sa position donc), c'est tout aussi simple .

Tu adaptes son déplacement? C'est à dire?
Tu "réduits" sa vitesse ?

Non je le fais aller vers le bas/le haut en fonction de la pente.
Mais pas d'une case entière, ça dépend de l'angle de la pente:
Si une pente va de la 4e ordonnée à la 5e sur la case n°X, bah je lui rajoute une demi case (0.5) à son ordonnée. Comme ça il se retrouve au milieu de la case. il faudra voir aussi parce que j'ai peur qu'il soit à moitié dans le décor et à moitié dans le vide en faisant comme ça...

Ha oui
Mais tu peut pas rajouter 0.5 à une ordonnées, si?

Pourquoi je pourrait pas?  
je travaille par rapport au zoom, pas à l'écran, donc je peux rajouter 1E-99 si ça me chante (même si là ça serait inutile)
Avec le zoom que j'ai pris, 0.5 unités correspond en fait à 4 pixels.

Beau travail !

Merci

çaaaa vaaaa êtreeeee leeeennnnttttt ! ! ! ! !

Déjà là, rien que pour le "terrain", ça va être long, alors avec notre figurine dessus... Pfiou ! Mais on peut pas faire mieux en ti-basic, tentons quand même...

J'ai fait un prototype (juste un mario qui se déplace et peut "sauter" (mais sans redescendre et sans prendre en compte le terrain)) et j'ai une très mauvaise nouvelle.
C'est bien pire que lent...  

Et là entre en scène la magie de WLib  je suis en train de bosser sur le nécessaire pour afficher un sprite. Espérons que ça soit pas trop lent à interfacer avec le Basic quoi x)

Ce serait bien ça .
(Il faudrait aussi pouvoir l'effacer si possible ).

Par contre je crois que je vais abandonner l'idée de la pente (ça va vraiment ralentir le prgm, et en plus on pourra pas bien afficher le mario sur une pente.)
Du coup je ne vais pas utiliser le même type de statplot, je vais me servir de diagramme, ça sera plus simple à coder.
C'est dommage j'aimais bien le principe avec les pentes, mais c'est vraiment irréaliste en ti basic...

Essaye tout simplement la méthode qui va le plus vite possible. Y'aura bien assez de trucs par-dessus pour le faire ramer, t'inquiète pas.

Ouais je vais faire avec les diagrammes alors.
Et aussi quand je décale l'écran je décale de plusieurs cases à la fois sinon faut tout le temps le mettre à jour c'est horrible...

Par contre quand tu affiches le sprite faut que ce soit en fonction du zoom .

Ah non. Ça sera en fonction de pixels, sinon c'est bien trop lent.

Ah mais si j'utilise les statplot je dois l'afficher en fonction du zoom, et si je recalcule les coordonnées en fonction des pixels pour l'afficher ça risque d'être compliqué... Mais bon je me débrouillerai ça sera toujours plus rapide que comme ça de toute façon.

J'édite demain pour vous montrer où j'en suis .

Euh c'est surtout que ton scrolling là tu le fais d'abscisse 1 par 1...

Evidemment que c'est lent...

Faut le faire de 2 par 2, si c'est pas plus...
Ensuite, utiliser les diagrammes est une bonne idée, quoique je suis pas sur que ça aille plus vite, mais ça fait plus "plateforme"...

Et +1 pour Wlib, bien sur

Oui c'est ce que j'ai dis je fais faire du 3 par 3 (voire même du 4 par 4), pour que ça soit plus fluide.

Les diagrammes ça ira plus vite (plus facile de savoir où est le sol, et 2 fois moins de coordonnées à afficher).

Je vous montre dès que possible où j'en suis (un "X" qui se balade en prenant compte des murs/sols/limites pour l'instant.

@Matref: Quand on affiche hors de l'écran ça serait bien que tu n'affiches juste rien, et que tu ne renvoi pas d'erreur (à la rigueur tu mets une certaine valeur dans une variable en cas d'erreur et tu nous dis laquelle pour si on veut faire quelque chose en cas de sortie d'écran)...

Je peux faire ça oui. Un bon vieux clipped sprite avec en plus détections de sortie, ça risque d'être compliqué, mais je vais essayer.

Ok super .

J'ai édité le premier post.
Qu'en pensez vous?

matrefeytontias a écrit:Je peux faire ça oui. Un bon vieux clipped sprite avec en plus détections de sortie, ça risque d'être compliqué, mais je vais essayer.

Oula!

+1 pour les diagrammes

c'est awesome !

Merci .


Bon alors voilà je pense changer complètement la façon de gérer le jeu, sinon je ne sais pas trop comment introduire les objets.

Je garde bien sûr le principe des statplot afin de réaliser un scrolling comme ici.
Par contre: je récupère tous les éléments du jeu (sol objets etc) dans une matrice (au début je pensais à une liste mais c'est moins pratique même si plus rapide d'accès).
Il faut donc réactualiser la matrice à chaque scroll, et il faudra donc décaler une partie de la matrice pour recueillir les nouvelles données.
Et du coup je n'ai qu'à faire réagir le personnage et les objets de la matrice s'il y en a (je pense conserver la position de ceux qui doivent agir à chaque tour dans une liste afin d'aller plus vite dans le traitement).

Dans la liste d'objet L3 (qui servira de banque de données pour rajouter à la matrice quand on arrive à la bonne absice), je pense utiliser 2 termes pour chaque objet: le premier indiquera sa position (valeur entière = absice; 10 * valeur décimale = ordonnée), et le second donnera des informations sur l'objet comme suit:
XXXX.AA
avec X et A des chiffres décimaux.

Le premier X (à gauche) correspond à la direction "bas", c'est a dire quand un autre objet va dessus en se déplaçant vers le bas.
Le second c'est la direction "droite".
Le troisième c'est la direction "haut".
Le dernier c'est la direction "gauche".
X vaut:
0 si l'objet est inexistant (dans la direction considérée (c'est le cas par exemple pour une plateforme qu'on peut traverser en sautant))
1 Si l'objet nous bloque (plate forme...)
2 si l'objet est mortel (un ennemi)
3 si on peut tuer l'objet (direction bas avec un ennemi par exemple)
4 si on active l'objet (un champignon ou autre)

Je ne voit pas ce qu'il pourrait y avoir d'autre comme cas, mais si vous avez une idée dites toujours.

AA correspond au numéro de l'objet (pour afficher le bon sprite).

L'inconvénient de ce système c'est qu'on  ne peut avoir que des objets de 8*8 pixels (ou sinon il faut les séparer en plusieurs objets qui réagissent pareil)

Ensuite, dans la matrice:
On a pas besoin des coordonnées, vous devinez pourquoi. (sauf pour les objets qui se déplacent ou agissent à chaque tour, auquel cas leurs coordonnées sont stockées dans L4).
Les objets seront codés comme dans la liste L3, avec le sol en plus (-1 si c'est le sol).

Que pensez vous de ce système?
Comment est ce qu'on pourrait faire sinon?

Edit: Mmh beaucoup plus facile à dire qu'à faire
Je ne suis pas sûr que ce soit vraiment comme ça la meilleure solution...

Whâââââ! Super!
(je pars un week-end et tout est déjà fait snif... )

ash a écrit:tout est déjà fait snif

Houlà loin de là
Il faut encore rajouter tous les objets, l’interaction avec le personnage, et modifier quelques trucs pour que ça ailles plus vite (je pense faire un système de pointeur pour savoir quelle ligne de la matrice est la première plutôt que de tout décaler à chaque fois (c'est trop lent à chaque scroll sinon).
Enfin bref pour l'instant ce qui a été fait c'est le plus facile, il y a encore de quoi s'amuser .

Beau travail +1 continuez comme sa :p

Je viens de faire en sorte que le sol soit géré par la matrice. Comme ça on peut déjà rajouter des plates formes et autres objets qui bloquent.

Ce qu'il reste à faire dans l'immédiat:
_gérer les éléments qui bloquent lorsqu'on saute (pour l'instant je ne me suis occupé que des directions gauche droite et bas puisque mario ne pouvait pas être bloqué en allant vers le haut (puisqu'il n'y a que le sol)).
_Créer la liste L3 d'objets et la rajouter à la réactualisation de la matrice à chaque scroll, ainsi qu'aux listes L4 et L5 (L4 servira aux objets inertes qui se trouvent dans l'écran et L5 aux objets mobiles, qui demandent de s'occuper d'eux à chaque tour).
_Ensuite il faudra rajouter la gestion des autres actions (pour l'instant je ne gère que on laisse passer mario (0), ou on ne le laisse pas passer (1)).

Un petit screen:

Comme vous le voyez, le scroll est très lent, c'est à cause de la réactualisation de la matrice (et ça risque d'être pire lorsqu'on rajoutera des objets).

J'édite le premier post pour vous montrer le code.

Si quelqu'un a des remarques/optimisations surtout à ce niveau là je suis preneur .

En voyant la manière dont tu gères tu scrolling, j'ai eu une idée qui je pense serait vachement bien ...

Je vois qu'à chaque fois que tu veux scroller tu effaces et redessines tout l'écran. Moi je te propose d'utiliser la fonction de scroll de WLib (j'ai déjà donné une version utilisable il me semble) pour décaler tout l'écran et redessiner une seule colonne, celle qui entre dans l'écran.

EDIT : WLib.83p v0.1b

Sauf que se serait plus lent de redessiner les 4 colonnes, puisqu'elles sont dessinées grâce aux satsplot... Du coup, je n'ai qu'à choisir mon nouveau zoom, et c'est la calto qui redessine entièrement toutes les colonnes qui sont dans l'écran (ce n'est pas le prgm qui s'en occuper lui même). Du coup effacer et redessiner l'écran n'est pas très lent, ce qui est lent c'est le chargement des données dans la matrice en fait.