MSX Village forum

le noob ici c'est moi

J'ai une question d'ailleurs pour les experts. ça se passe comment l'interaction sprites/décors en screnn2 par exemple.
Je sais comment faire en basic, mais existe-t-il des routines ou méthodes en ASM pour ça?

aïe, je m'exprime mal.

Dans un jeu tu peux avoir besoin de gérer les tiles suivant la position de ton personnage. Par exemple: tu rencontre un mur tu es bloqué, tu passe sur une clé tu le ramasses, tu rencontre une porte tu l'ouvres si tu as la clé, etc.

Lecture de la tuile sous le pixel (x,y):
ld d,$18
ld a,(x)
and $f8
rrca
rrca
rrca
ld e,a
ld h,0
ld a,(y)
and $f8
ld l,a
add hl,hl
add hl,hl
add hl,de
jp $4a

Yep.
Tu as plusieurs solution pour faire ça efficacement.

Soit utiliser des flags pour identifier des comportements particuliers à traiter.
Par ex. :
- Tous tes objets collectables peuvent avoir un numéro de pattern avec le bit#7 à 1
- Les objets qui demande une interaction du joueur (un click de bouton par ex.), avoir le bit#6 à 1
- etc.

L'autre méthode, que je préfère, c'est d'avoir tous tes tiles interactifs en début de ta table de pattern (appelons N le nombre de pattern interactive dont tu as besoin pour ton jeu ; 8, 16, 32, ...).
- Quand tu récupères le pattern où se trouve le joueur, tu tests si sont numéro est inférieur à N (si c'est pas le cas, c'est qu'il est pas interactif et tu t'arrêtes là)
- Préalablement, tu as préparé un tableau de taille N avec les adresses des différentes fonctions qui vont traiter les interactions avec les tiles
- Du coup, tu as juste besoin de faire un truc du genre :

- Ce qui est cool avec ce système, c'est que ton tableau peux être modifié d'un niveau à l'autre en fonction des besoins (s'il est en RAM évidement) et que plusieurs cases du tableau peuvent pointer vers la même fonction.

Si ça vous voulez, je peux détailler un peu plus l'une et/ou l'autre de ces techniques.

Bon, je vais vous faire ça en pseudo-code assembleur (ça sera plus compact et bcp plus facile pour moi à écrire).
Prenons un exemple concret (fictif) d’un jeu avec des tuiles représentants :
- les fond de décors (aucune interaction)
- les murs/sol (qui bloquent le joueur)
- de potions de vie/mana (qui remonte les HP/MP quand on passe dessus)
- des portes (qui s’ouvrent quand on passe dessus)
- des portes verrouillées (qui ne s’ouvrent que si on a une clef à utiliser)
- des clefs (qu’on peut accumuler)

Les murs/sols ne sont pas vraiment des objets interactifs donc je vais pas rentrer dans le détail. Il faut juste tester les coins du sprite du personnage avec ces tiles et ajuster sa position en fonction des collisions.

Méthode 1

Pour méthode 1 de gestion des interactions, on pourrait par ex. coder les numéros de pattern avec les règles suivantes :



En résumé :
- Les objets de fond du décor ont une valeur binaire de la forme [0XXX XXXX] (ou X peut prendre n’importe quelle valeur).
- Les murs/sols (blocker) ont une valeur de la forme [10XX XXXX].
- Les objets ramassables : [110X XXX]
-- Les clefs :[1100 0XXX]
-- Les potions de vie : [1101 0XXX]
-- Les potions de mana : [1101 1XXX]
- Les portes : [111X XXXX]
-- Les portes normales : [1110 0XXX]
-- Les portes verrouillés : [1110 1XXX]

L’avantage, c’est qu’on peut faire des traitements à différents niveaux de spécialisation de l’objet interactif. Par ex., une clef et une potion de vie étant tous les deux des « objets ramassables », on peut les faire disparaître quand le joueur passe dessus. Voici un pseudo code de traitement de ces objets :



Voilà.
Cette technique a ses avantages et ses inconvénients.
Elle peut être utile quand vous avez beaucoup d’objets différents mais qui partagent une grosse partie de leur traitement.
Si vous avez peu d’objet, la méthode 2 (ou un mix) est sûrement plus intéressant.
Mais ça, c’est une autre histoire…

Méthode 2

La methode 2 est encore plus simple.
Il suffit de réserver un nombre de tuile pour celles qui sont interactives.
Dans l’exemple précédent, réservons 8 tuiles et affectons les index suivants :
- 0 : Une clef
- 2 : Une potion de vie
- 3 : Une potion de mana
- 4 : Une porte normale
- 5 : Une porte verrouillée

Le pseudo code de traitement serait alors :



Le code est beaucoup plus performant que dans la méthode 1 (très peu de test pour accéder au code spécifique à chaque interaction).
Le seul défaut c’est la nécessité d’allouer un peu d’espace à la table de saut (celle qui relie un numéro de pattern avec une routine dans le programme) et les risques de redondance.

J’ai présenté ces deux techniques de façon séparée par souci didactique, mais en vrai, si j’étais confronté à cette situation, je ferais sûrement un mix des 2 techniques.
Par exemple, pour check si une tuile est un bloqueur (mur/sol), j’utiliserais plutôt le check de bit, alors que pour le reste, j’utiliserai plutôt une table de saut.
Pour les objets dont le traitement est très proche – comme la potion de vie et de mana – je garderais des bits pour les différencier et j’utiliserai un code générique. Par ex., on pourrait avoir un tableau avec la vie comme entrée d’index 0 et la mana comme entrée 1 ; on pourrait alors avoir un code commun qui incrémente la valeur dans le tableau en fonction du bit#0 du Pattern, sans tester s’il s’agit d’une potion de vie et ou de mana.

Voilà, j’espère que ça vous est utile.