[PROJET MARIO] le moteur du jeu

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.

Franchement si, pour moi le dessin est très lent  t'es sûr que tu peux pas juste dessiner le bon nombre de colonnes ?

Au fait, go : https://tout82.forumactif.org/chatbox

Dessiner 4 colonnes "à la main" serait plus lent qu'en dessiner 12 avec les statsplot à mon avis... Parce qu'il faudrait récupérer dans la liste les positions des sols, tracer la ligne horizontale en fonction de cette position, puis les lignes verticales, en recalculant à chaque fois l'absice... Le gain en vitesse (s'il y en a un ce qui n'est pas sûr) ne se verrait pas à cause du chargement de données dans la matrice en fait, qui prend beaucoup plus de temps.

Perso je discerne pas le chargement dans la matrice, peut-être que je sais pas où chercher ; par contre le scroll je le vois bien.

Juste avant le scroll, tu as le "X" qui est immobile un certain temps, c'est là que la matrice charge.
Quand j'utilisais la liste de la position du sol c'était beaucoup plus fluide à ce niveau...

Après on peut toujours essayer avec Wlib et voir la différence.

Perso je discerne pas le chargement dans la matrice, peut-être que je sais pas où chercher ; par contre le scroll je le vois bien.

Dur, de te repérer dans la matrice ? Tu ne sais pas comment elle charge ? Laisse moi t'aider, Neo...


Quand au traçage, à mon avis les statplots restent aussi plus rapides que Wlib. Et surtout plus économiques en octets.

[idée potentiellement stupide]
Par contre, si la matrice est lente... chargeons en qu'un petit bout ?

Genre charger uniquement la zone proche de Mario pour gérer les collisions, possible ou pas possible ?
[/idée à débattre]


PS: Si on commence à publier des codes et des 83p différents, préciez toujours la date dans le titre MARIO-29-10-13.83p

Mmh... ça impliquerait qu'il ne pourrait y avoir des ennemis/objets que dans la zone proche de mario, et ils apparaitraient d'un coup, ce serait assez perturbant...
De plus, ça voudrait dire qu'il faudrait charger la matrice à chaque fois que mario se déplace, alors que là c'est seulement au moment du scroll... Là pour l'instant le déplacement de mario est assez fluide, mais dès qu'on rajoutera la gestion des objets il ne faudra pas que ça ralentisse plus (heureusement que les sprites seront affichés en asm d'ailleurs).

okay, alors on fait comme si j'avais rien dit

Les sprites seronts affichés en ASM ?
On peut mélanger du TI - BASIC avec de l'ASM ?
Wlib?

Oui.
Oui.
Oui.

On peut mélanger ti basic et asm en appelant un prgm asm depuis un prgm ti basic à l'aide de la commande send(9prgmXXX) (send=envoi en français), avec XXX le nom du prgm asm.
Il est aussi possible de faire l'inverse (appeler un prgm ti basic depuis un prgm asm), mais c'est peu (voire pas) utilisé.

Vous vous débrouillez très bien sans moi.

Reste là, au cas où

Tout à fait d'accord avec Persalteas .


J'ai rajouté la gestion des objets bloquant + gestion d'obstacle bloquant en direction "haut" + gestion d'objets mortels + double saut de mario lorsqu'on clique 2 fois très vite sur la touche flèche du haut (sinon mettre des plateformes est inutiles puisqu'il aurait fallu qu'elles soient posées sur le sol).
Je poste demain voire après-demain pour vous montrer le code source.
J'envisage aussi de passer par un système de goto/lbl qui sera je pense plus rapide que la boucle Repeat actuelle.

EDIT:
La gestion des collisions avec les objets est presque complète (il ne manque plus que les objets à ramasser en fait).

D'ailleurs je viens de me rendre compte qu'avec cette gestion d'objets on peut facilement faire des grottes secrètes (enfin pas si secrètes que ça puisque les objets dans la grotte seront affichés même si on a pas trouvé la grotte, mais c'est mieux que rien ) .

J'édite pour rassembler mes 2 précédents post, et je (re)double post pour vous annoncer que j'ai terminé la gestion des objets fixes.
Pour l'instant, il y a:
O plateforme.
A un ennemi (tuable en lui sautant dessus)
T un ennemi (invincible, mais on peut lui marcher dessus)
Y un ennemi (invincible)
ø un champignon (pour faire grandir mario)
^ un champignon hélicos (pour transformer mario en hélicos)

Mario peut maintenant "évoluer":
X mario normal
H mario plus grand
x (avec la barre au dessus comme une moyenne) mario hélicos, il peut voler de 5 cases en appuyant sur 2nde.

Lorsque mario rencontre un ennemi et que celui ci l'attaque, mario diminue d'un cran (x->H->X), et l'ennemi est tué.

J'ai séparé le prgm en 4: MARIO (le principal), MSCROLL (pour le scroll), MSPE (pour une action spéciale lorsqu'on appuie sur 2nde), et MOBJ (lorsqu'on ramasse un objet).

Un petit screen:

Voilà .

Prochaine étape: gestion des objets mobiles (ça va barder  )

   Très bon travail !

Pourquoi ne scroller que si peu et si tôt à chaque fois ?

si peu, non
si tôt, oui !

M@t a écrit:Prochaine étape: gestion des objets mobiles (ça va barder Razz )

Tu parles des ennemies ?

M@thieu41, tu dépasses mes premières attentes. Bravo, continue.

Je pensais que les statplots pourraient gérer aussi des points, que ce soit des plateformes ou des objets.

Je pense que l'écran devrait défiler lorsque le personnage dépasse un peu plus que le milieu. Mais je reconnais que ne pas être trop près du bord a ses avantages.

Je pense que plus de plats devraient exister, pour faciliter des concepts d'ennemis.

Je m'absente quelques jour, je reviens le jeu est presque finit!
Sa commence à me dépasser, tu est un killeur en prog mathieu

Merci

blg_flg a écrit:Pourquoi ne scroller que si peu et si tôt à chaque fois ?

Pour l'instant je fais un scroll de 4 (sur douze) lorsque mario arrive à la 10e colonne...
Je peux faire un scroll plus grand (5 voire 6) mais je pense qu'il vaut mieux le laisser à la 10e colonne non? Parce que ça permet d'avoir un peu de marge quand on arrive au bout: s'il y a un ennemi juste derrière, on ne le voit qu'après le scroll, et ça peut être trop tard...

pito a écrit:Tu parles des ennemies ?

Oui mais pas seulement: pour faire bouger les objet à ramasser aussi par exemple.

pito a écrit:si peu, non
si tôt, oui !

Je n'ai pas compris si tu est (pas) d'accord avec ce qui est fait ou avec les remarques de keb...

Linka a écrit:Je pensais que les statplots pourraient gérer aussi des points, que ce soit des plateformes ou des objets.

Je ne comprend pas trop ce que tu veux dire, tu veux faire ça comment?
Stocker les positions dans des listes et les afficher grâce aux stat plot? Mais du coup tous les objets seraient des "+", ou autre marqueur disponible?

Linka a écrit:Je pense que plus de plats devraient exister, pour faciliter des concepts d'ennemis.

Je vais voir ça.
Pour l'instant je pense les faire avancer de manière simple (cad qu'ils vont à droite jusqu'à ce qu'ils ne puissent plus, et là ils font demi-tour), et peut être complexifier plus tard (leur permettre de sauter (à la manière des tortues volantes dans mario), de tomber, etc).

Wista a écrit:Je m'absente quelques jour, je reviens le jeu est presque finit!

Ce qui reste à faire (gestion des objets mobiles), est certainement (à mon avis) le plus compliqué. Le plus dur ça va être de les faire avancer sans faire tout boguer...
A la rigueur ce que je vais faire je pense c'est les faire avancer une fois tous les 2 tours (au moins mario pourra "courir" et aller plus vite qu'eux. Et aussi ça permet de ne gérer que la moitié à chaque fois, ça ira plus vite.

m@thieu41 a écrit:Ce qui reste à faire (gestion des objets mobiles), est certainement (à mon avis) le plus compliqué. Le plus dur ça va être de les faire avancer sans faire tout boguer...
A la rigueur ce que je vais faire je pense c'est les faire avancer une fois tous les 2 tours (au moins mario pourra "courir" et aller plus vite qu'eux. Et aussi ça permet de ne gérer que la moitié à chaque fois, ça ira plus vite.

Excellente idée je pense.

m@thieu41 a écrit:

Linka a écrit:Je pensais que les statplots pourraient gérer aussi des points, que ce soit des plateformes ou des objets.

Je ne comprend pas trop ce que tu veux dire, tu veux faire ça comment?
Stocker les positions dans des listes et les afficher grâce aux stat plot? Mais du coup tous les objets seraient des "+", ou autre marqueur disponible?

Hélas oui, on sera quand même limité par les graphismes.
On a trois marqueurs de points (.,carré,+).
Tu utilises le type Histogram(Diagramme) pour le terrain, on peut probablement aussi utiliser Scatter pour une catégorie d'objets ponctuels, et xyLine pour relier les points et représenter des choses plus complexes.

xyLine? Mais tous les objets seraient reliés entre eux?
Avec le scatter on peut mettre des genres de pièces à ramasser, ça donnerait un but provisoire au jeu.
Et il ne faut pas oublier qu'on est limité à 3 statplot...

trois statsplots, ca suffit largement sans arriere plan !
un pour les sprites, un pour les plateformes, ca devrait aller, hein?

Tu ne saisis pas bien le problème: si je me sers des statplots pour les sprites, on est limité à mettre: soit des points, soit des carrés, soit des croix. Donc comment veut tu différencier ennemis d'objets à ramasser ou encore de plates-formes?
En utilisant xline on pourrait faire des objets plus complexes (à dessiner), mais restera le problème de les identifier (pour l'algo), et qu'un sprite prend un statplots...
Bref 3 statplots soit ne suffisent pas, soit ne donnent pas assez d'informations sur l'objets (au joueur et/ou au prgm).

et bien tu mets des lignes pour faires les sprites, non?
tu dis que tu peux mettre des points, ben tu les regroupes!
je te dis pas de faires des goombas, mais faut pas dire que tu peux pas mettre des petit monstres qui bougent pas!!!

Ton idée n'est pas bête dans l'absolu, mais il n'y a pas que des problèmes d'affichages: comment savoir où est l'objet? comment savoir si c'est un ennemis? comment savoir si c'est un objet à ramasser? Et aussi ça réduit les possibilités: impossible de faire un objet qui bouge.
Et des objets qui ne bougent pas et que je peux reconnaitre dans le prgm j'en ai déjà inséré (cf mon screen).
Après non je n'utilises pas des lignes: pour l'instant j'affiche juste un caractère, mais après on doit se servir de Wlib pour afficher des sprites.

Sinon je viens de finir de coder la gestion des objets mobiles (pour l'instant juste les ennemis, qui peuvent nous tuer et qu'on peut tuer). Ils se déplacent horizontalement (en font demi tour en cas d'obstacles), et tombent au besoin.
Je poste le code et un nouveau screen dès que j'aurais recopié le code

Le problème d'utiliser les statsplots pour les sprites est moins d'afficher des formes complexes (si on peut dessiner un point, on peut dessiner ce que l'on veut) que d'actualiser l'écran tout entier à chaque mouvement de sprite, même le diagramme en bâtons qui représente la carte dans son ensemble.

NB : Je pense qu'il faudrait faire un plus grand défilement lorsque le joueur va "au bout" de l'écran.

Pour alléger l'algo de scroll, c'est mieux si c'est un multiple de 12.
Donc on a le choix entre: 1, 2, 3, 4 (qui sont trop petits), 12 (qui est trop grand) ou 6.
Donc 6 ça vous va?

m@thieu41 a écrit:Pour alléger l'algo de scroll, c'est mieux si c'est un multiple de 12.
Donc on a le choix entre: 1, 2, 3, 4 (qui sont trop petits), 12 (qui est trop grand) ou 6.
Donc 6 ça vous va?

Depuis quand 1, 2, 3, 4 et 6 sont des multiples de 12 ? C'en sont des diviseurs... Mais pourquoi cela pose-t-il problème avec ton algorithme ? Le temps de rafraîchissement de l'écran étant long, il serait préférable qu'il se fasse moins souvent... donc 8 aurait été mieux (voire 10), selon moi.

Oui des diviseurs pardon
Parce que Xmax=Xmin+12 donc si on incrémente Xmin et Xmax avec un pas qui n'est pas un multiple de 12, il faut tester si on ne sort pas de l'écran (si on ne veut pas scroller trop loin), et donc sauvegarder le nombre de scroll, or j'ai une matrice [B] dont je fixe les dimensions, si à chaque scroll il faut la redimensionner pour être sûr de ne pas dépasser la map ça va encore plus ralentir. En plus il faudrait retenir le nombre de scrolls pour remettre à jour la position du perso et tout, bref ce n'est pas pratique. Tandis que là il faut juqte que la taille de la map soit un multiple de 4 (ou 6) et c'est bon.
Et en plus le temps de rafraichissement augmente avec le nombre de scrolls...
10 je trouve ça trop (ça ne laisse pas assez de marge de manœuvre pour le joueur).