MSX Village forum

Si je rode à nouveau sur le village, c'est pas juste pour parler technique (même si c'est toujours sympa d'apprendre de nouveaux trucs).
En fait, ça faisait un bout de temps que je me disais que s'il y a un domaine que j'affectionne mais où le MSX n'a pas excellé à l'époque, c'est bien les jeux de sport (mise à part l'excellent Pennant Race 2 et les Track & Field).
Du coup, j'ai envie de combler ce vide.
J'avais d'abord dans l'idée de faire un jeu de tennis, mais n'ayant pas trouvé de sprites qui me plaisent sur le net, je me suis rabattu sur... le foot.
Techniquement, c'est très compliqué car on a besoin d'un grand terrain et de 22 personnages !
J'ai fait un premier test très sommaire (vous pouvez essayer la ROM) qui utilise 2 pages statiques dans le VRAM pour le terrain (256x512px) et des sprites bitmap en 16x16.
L'avantage, c'est que le terrain pourrait être joli et très détaillé vu que c'est un bitmap (les joueurs pourraient même facilement laisser des traces dans l'herbe), et que je n'ai pas besoin de gérer le scrolling en déplaçant des données. J'ai "juste" à jouer sur le registre de scrolling vertical et, là où ça devient plus technique, changer la page affichée en plein milieu de l'affichage de l'image.
Le gros problème, c'est que je ne peux pas faire de double-buffering (écrire dans une page pendant que j'affiche l'autre) car j'ai plus de place en VRAM.
Du coup, je dessine en même temps que l'image s'affiche et c'est compliqué de ne pas avoir les sprites qui se mettent à scintiller.
De toute façon, même en limitant le nombre de personnage qui bougent, ça semble compliqué de gérer 22 personnages.
Je vais tester une solution hybride avec des sprites hardware en plus des bitmaps, mais je pense que LA solution c'est... d'être plus raisonnable.
Je vais donc certainement plutôt tenter le Futsal, la version 5v5 du foot qui se joue sur de petits terrains.
Avec un terrain de 256x384 en double buffer et à 30 Hz (donc 2 frames pour déplacer les sprites bitmaps), ça devrait déjà être bien plus réaliste.
Voilà, c'est tout pour le moment.
Je vous tiendriez au courant de l'avancé du projet.

22 personnages ça me semble compliqué en effet.
j'ai pas souvenir de jeux de foot 8bits avec autant joueurs.
il y en avait combien sur Konami Soccer ?

en tout cas je croise les doigts pour que tu ailles au bout de ce projet

Ouah l'autre hé... 3 Hyper sports, 2 Hyper Olympic (ou Track & Field effectivement), Konami's football, Konami's tennis et Konami's Ping pong et je ne compte pas les jeux de bagnole. Là je te trouve difficile

Ah oui, j'ai oublié Konami Ping Pong qui était vraiment bien.
Mais dans les sports populaires (foot, tennis, basket, volley, etc.) c'est la dèche (qualitativement).
En tout cas, c'est mon avis.

Pour du 11v11, c'était au contraire déjà trop petit.
Là je vise plus du 7v7, voir du 5v5 donc ça ira très bien avec mon terrain en 256x384.
J'ai fait un plan de la VRAM et tout semble tenir (les 2 terrains pour le double-buffering, les sprites bitmap des 2 équipes, les sprites hardware et les zones où je backup le terrain avant de dessiner sous les joueurs).
Si tout va bien, je n'utiliserai les sprites hadwares que pour le score et le timer.
Reste à voir combien de personnages je suis capable de faire bouger à 30 ou 25 Hz...

Beau projet, mais y a du taf
Je pense surtout a IA, game play, 1,2 joueurs, vs computer,.... Ah oui j'oublier ,...... La Baballe, c'est prévu ? car ça aussi ça va prendre du travail système

Bon, je ne m'attend pas a tout les joueurs bougent systématiquement vers la balle, sinon ça ressemblera plutôt à une mêler de rugby

Donc j'imagine que Ça sera au tour par tour, genre tout est statique qd la Baballe bouge et seul le joueur a la Baballe et le joueur sélectionné adverse peut bouger ? Tandis que les autres joueurs adverses non sélectionnés se comporteront soit en défenseurs avec positions pré définis et les joueurs de la Baballe en attaque.. Car si c'est trop prévisible, ça, ressemblera plus à un jeu d'échec. Je ne veux pas embrouillé les esprits, mais c'est plus complexe, la gestion des "sprites" questions IA et game play que ça en a l'air

En mode de jeu caché, j'imagine un mode entraînement ou les joueurs des 2 équipes alignés doivent traversé le terrain qui est en cour de tonte, (avec déplacement d'un joueur à la fois et la tondeuse qui traverse latéralement) le premier qui arrive au bout à gagné la manche. Et à chaque manche on rajoute une tondeuse ...... Un Frog Foot quoi
Comme IA, la tondeuse (de la ligne concernée) sera attirée par la Baballe, il y a moyen de se la jouer stratégie pour éliminer avec la tondeuse les joueurs de l'équipe adverse

Bon... Vous savez tous que j'adore le foot ...... Surtout quand c'est amusant
Edité par TurboSEB Le 11/12/2020 à 06h40

Si c'était du Basic...

1) Du Screen 5 devrait suffire.
2) Le scrolling Horizontal hardware VDP (27) est très facile a mettre en oeuvre.
3) Un terrain d'une longueur de 512x192 serait doublement intéressant.
4) Le terrain pourrait être aisément construit sous forme de bribes verticales.
- La page 0 => page visible 256x192 / La page 1 "moitié Gauche du terrain 256x212" / La page 2 "Moitié Droite du terrain 256x212" / La page 3 "256x212 entièrement disponible!"
- Une copie de bribes depuis les page 1 ou 2 vers la page 0 permet de se débarrasser d'un "nécessaire double buffering"
- Des bribes verticales de 2 pixels permettent un scroll horizontal sans saccade apparente.
- Les scrolling diagonaux doivent se faire par "Pas de 1 pixels" (1 pixel Vertical puis 1 Horizontal) pour rester cohérent au scrolling horizotal par "Pas de 2 pixels".
- La limitation verticale de l'image "visible (focale!)" en 192 permet un petit scrolling "hardware" vertical de 44 pixels. (nulle besoin de repositionner "Y Sprites")
- Le scrolling Horizontal fait "scroller" les Sprites horizontalement sur 512 pixels totalement gratuitement. (nulle besoin de repositionner "X Sprites")

Au final:
Seuls X et Y du "ballon" et du/des "Héros" répondants aux contrôles du/des joueur/s doivent être reconsidérés à chaque "cycle"
Seul la bribe "droite" ou "gauche" doit être "COPY" à chaque cycle.
Seul VDP(27) est sollicité pour scroller un total de 256 pixels horizontaux.
Un petit scroll de 44 pixel verticaux sans solliciter de ressources juste parce que la "focale" est de 192 pixels alors que le "background fait 212".

Point Négatif => faut un VDP 9958 (Msx2+) pour bénéficier de ce hardware

Bref... Ca reste seulement mon point de vu avec une approche sous Basic

Je m'en va Edité par igal Le 12/12/2020 à 11h53

N'ayant aucune expérience autre que le Basic Msx, peux tu me dire si il existe "une opération" ou "série d'opérations" équivalente à ton processus permettant de "scroller" depuis la [page 0] à la [page 1]?

Encore une fois, En basic, soit j'affiche directement un bloc depuis une source stockée sur un média comme je sais le faire avec les "Bribes d'une image" comme si c'était "streamé" en live, soit je fais une copie d'image depuis une [page Non visible] vers la [page visible] que je fais scroller