MSX Village forum

Reprise du message précédent

Bravo bravo bravo c’est super comme idée et réalisation

C'est bien le cas !
C'est même pas à cause de OpenMSX ou MSXBlue ; c'est simplement le clavier de mon PC qui détecte pas l'appuis sur la barre espace si j'ai les touches [Haut]+[Gauche], ou [Bas]+[Droit] enfoncées.
On peut tester son clavier ici : http://en.key-test.ru/
De mémoire, le MSX n'a pas ce problème.

Faudra mettre des bruitages pour le réalisme
Quelques pistes ici :
https://youtu.be/M-e3l5JCx3E
https://youtu.be/ZdyGoL34AiI
Enfin, si il reste des ressources hein

J'ai fini mon 2e joueur !


J'ai optimisé les poses pour limiter les cas ou j'ai besoin d'un sprite de plus pour la raquette (il n'y a plus que 3 frames ou c'est nécessaire).
Ca limitera les cas ou je dépasse les 4 sprites par lignes.
Du coup, je vais retaper les sprites du 1er joueur pour utiliser la même technique.

J'ai hâte de reprendre la programmation, mais je me serai quand même bien amusé en pixel art.

Merci.
Pour moi, c'est un jeu en lui-même que de faire un jeu sur MSX.
Toutes les contraintes techniques sont autant de règles du jeu qu'on peut s'amuser à essayer d'exploiter au maximum pour atteindre ses objectifs.
Le revers de la médaille, c'est que comme je m'amuse beaucoup à solutionner les puzzles techniques, j'ai du mal à finir mes jeux une fois que ça devient facile.
En tout cas, je suis bien motivé par celui-là qui a juste ce qu'il faut de challenges sans être non plus trop improbable.

Si un jour ça te ré-tente de faire une version MSX, tu trouveras ici des gens pour t'aider.

J'hésite entre deux approches pour mes données et j'espère que les experts en assembleur (Metallion par ex. ) pourront me donner leur avis.
Pour chaque frame d'animation de mes tennismen, j'utilise 9 patterns 16x16 de la Sprite Patterns Table du TMS9918 comme suit :

Comme mon personnage fait 16x24 pixels, sur ces 9 patterns 16x16, seuls 28 des 36 blocs 8x8 sont utilisés.
Sur l'image : En rouge, l'index du pattern. En bleu, l'index de l'attribue de sprite (hors sujet). En gris, les blocs non utilisés. En couleur, les groupe de blocs non-vides contiguës en VRAM.
(la "racket" est un cas particulier qu'on peut négliger)

J'hésite donc entre deux méthodes :

• Copier les 36 blocks (288 octets) d'un coup dans une seule boucle (les blocs vides étant simplement plein de 0)
• Copier les 28 blocks vraiment utilisés (224 octets) par groupe de blocs contiguës (il y en a 9 allant d'une taille de 8 à 72 octets)
  

Sur les 21 frames d'animation que compte chaque personnage, on aurait 1344 octets de blocs vides ; ce qui fait beaucoup, mais qui n'est pas vraiment un problème.
Ma problématique est surtout la vitesse de transfert de mes images en VRAM.
Comme je suis sur MSX1, en mode graphique 2 (Screen 2) et potentiellement hors V-Blank, je ne peux pas aller plus vite que 29 cycles pour l'écriture coté CPU pour laissé le temps au VDP d'écrire les données en VRAM.
Ma boucle de copie en VRAM est basé sur un outi + jp nz qui fait justement 29 cycles.
Le code assembleur que je compte utiliser fait 112 cc de setup + 29 cc / octet pour la copie.
Si je copie les 36 blocks dans une seule boucle (avec les blocs vides), j'ai calculé un total de 8464 cc (288 * 29 + 112).
Si je copie les 28 blocks en 9 fois, j'ai calculé un total de 7392 cc (224 * 29 + 112 * 9).
Il y aurait surement un petit surcout pour la copie en 9 fois sur le setup, mais d'un autre coté, aucune copie ne faisait plus de 256 octets, je pourrais optimiser le setup de la boucle (les deux doivent s'équilibrer à mon avis).
Si j'en crois ces chiffres, la deuxièmes solutions semble bien plus rapide.
Est-ce que ces résultats vous semblent cohérents ?

OK, je vais partir la dessus.



En temps normal, on aura que 3 ou 4 sprites par ligne :
- Black1 ou Black2 (l'alternance créé l'effet d'ombrage)
- Cloth (uniquement sur la partie 16x16 basse)
- White
- Skin

Il n'y a que 2 frames sur les 21 où la raquette sera sur une ligne ou y a déjà 4 sprites.
Et il y a évidemment la balle qui pourra passer à hauteur du joueur.

J'estime que 80% du temps, on aura aucun problème de prio.
Dans le cas ou la raquette ou la balle font dépasser la limite des 4 sprites, c'est la peau qui va sauter en premier (via le système de priorité dû à l'index des attribues de sprite). Comme c'est la même couleur que le terrain, l'impact sera potentiellement limité (si le joueur n'est pas au dessus d'une ligne blanche, il ne devrait même pas se rendre compte que le sprite de peau à disparu).
Dans le cas rare (en nombre de frame) où on aura la raquette et la balle sur la même ligne, c'est la couleur blanche qui va sauter en plus de la peau.

Il n'y a pas de magie, mais disons que le système est prévue pour limiter les cas d'outrepassements de la limite des 4 sprites et pour minimiser l'impact visuel qu'auront ces outrepassements.

EDIT : Avec un autre agencement des patterns en VRAM (en mettant tous les blocks 16x16 plein côte à côte), je descends à 8 groupes de blocks à envoyer. Ça confirme l'avantage de la 2e méthode.