Supa Zazai - VCS 2600

[65c02]

Bonjour,

Avec Supa Zazai, Doc vient de nous pondre un petit chef d'oeuvre.
Je me suis penché un peu sur le portage sur atari VCS 2600.

C'est faisable si on accepte de tordre un peu le gameplay.
Juste assez pour que ça marche mais pas trop pour ne pas perdre les joueurs

Je me propose d'utiliser ce projet pour vous expliquer la démarche.
Cela vous permettra de mieux comprendre les portages VCS du passé.
Et comme lorsque l'on comprend mieux, on aime plus, cela fera votre bonheur jusqu'a la fin des TV cathodiques 

Avant de commencer, je vais rappeller rapidement les contraintes technique de la VCS 2600
- 128 octets de ram
- le TIA (chip graphique) ne sait gérer q'une seule ligne. On doit modifier sans cesse les registres pour faire une image)
- 2 sprites de 8 pixels de large.
- un playfield de 20 pixels doublé ou en mirroir remplit la ligne. il faut écrire 3 registres définir totalement le playfield.
- 3 pixels appellés missile 0 missile 1 et balle.

Autre contrainte le CPU tourne à 1Mhz et il affiche 3 pixel TV pour un cycle CPU.
Dit autrement on a 76 cycles CPU disponible pour une ligne écran dont 20 cycles se déroule hors affichage.
Dit encore autrement, toute modification des registres vidéo pendant les 20 premiers cycles se fera sans soucis et toute modification entre les cycles 20 et 76 sera succeptible de produire un glitch à l'écran.
Sachant qu'il faut 3 cycles pour écrire dans registre on peut facilement taper dans 2 ou 3 registres par ligne, après ça devient du sport. 

[Urbinou]

Bon courage

[vincent2105]

Super ! Je vais suivre le topic avec autant d'intérêt que celui que tu avais ouvert pour Bomb on Pixel city sur VCS 2600. 

[65c02]

Si j’analyse le gameplay de façon subjective, le joueur doit en permanence doser sa prise de risque.
Il doit éviter ennemi et boulettes mais aussi prendre les bonus et se mettre sur la trajectoire des ennemis pour les tuer et gagner du score.

Le joueur et les ennemis doivent pouvoir se balader sur tout l’écran.
Sur un plan technique cela veut dire que j’ai besoin au minimum de 5 éléments sur la même ligne : joueur, ennemi, boulette, bonus, tir joueur

Si je veux plus d’une boulette par ligne cela veut dire que je dois utiliser le playfield pour les afficher.

Mais Supa zazai est un shmup horizontal et le playfield ne peut bouger.
Le playfield est une suite de 20 gros pixels (de 4 pixels écran chacun) qui remplissent la moitié de l’écran. L’autre moitié étant une copie ou un miroir.

Donc si je veux que les boulettes se déplacent de façon smooth, je dois passer le jeu en vertical.

Première concession.

Autre problème, le playfield n’a qu’une seule couleurs par ligne.
Si je veux utiliser le playfield pour les boulettes et pour les bonus, je dois faire en sorte qu’ils ne partagent pas les même lignes.

Je fais donc une deuxième concession : alternance de boulettes et de bonus.

Autre problème, le playfield est copié ou en mirroir, si je veux avoir une répartition des boulettes et des bonus sur toute la largeur, je dois jongler avec les registres du TIA d'une manière qui me bouffe presque tous les cycles CPU de la ligne et ne me laisse pas le temps de gérer les deux autres sprites.

Je fais donc une troisième concession en mettant le playfield en mirroir. Les schéma de boulette seront donc forcement symétriques

Tout ça une fois codé donne ça



Il me reste encore à trouver les cycles pour intégrer l'affichage des ennemis avant de pouvoir dire que ce portage est possible de cette façon.

A suivre

[Urbinou]

Je comprends bien ta concession 3 pour les boulettes, mais... les trucs verts, c'est les bonus ? Tu ne les feras pas disparaitre quand on les ramasse alors ?

En alternant une ligne (vide) de mise en place et deux lignes de PF asymétrique pour les boulettes +2 missiles (éventuellement x3) pour les bonus, ou vice-versa, ce serait chaud évidemment, mais ça ne le ferait pas ? On réserverait la ball pour les tirs du joueur. Note, j'ai toujours été un peu trop optimiste dans mes tentatives
On peut aussi alterner ligne vide, 2 lignes PF, ligne vide, deux lignes missile, ball (players si on a le temps)...

Par contre, tu comptes faire ça avec les 128 bytes de base ?

C'était mes deux centimes

[65c02]

Alors oui, les trucs verts c'est les bonus. 

Je peux les faire disparaitre un par un, car j'ai la grille de registres PF en ram.
Je n'ai qu'un and a faire en ram pour en virer un.

Cela tient sans pb en ram je consomme la moitié là.

Pour l'idée d'utiliser le missile à la place, pourquoi pas.
Mais on va avoir un color clash quand le joueur et ou l'ennemi se mettront sur la ligne des bonus.
Car sprite et missiles se partagent la même couleur.

[drfloyd]

Si j’analyse le gameplay de façon subjective, le joueur doit en permanence doser sa prise de risque.

Tu as tout compris, on est en permanence confronté à la prise de risque, c'est le concept.

[Urbinou]

Je peux les faire disparaitre un par un, car j'ai la grille de registres PF en ram.
Je n'ai qu'un and a faire en ram pour en virer un.

Ton PF est asymétrique alors ? Ou alors si tu manges un bonus à gauche, il disparait aussi à droite ?

Mais on va avoir un color clash quand le joueur et ou l'ennemi se mettront sur la ligne des bonus.
Car sprite et missiles se partagent la même couleur.

Bon, alors les ennemis et le joueur seront verts aussi

N'oublions pas, il reste aussi la solution du flicker qui permettrait de doubler (au moins) les objets. On préfère toujours éviter, mais une frame sur 2 sur une cathodique, c'est à peine perceptible après tout. Tu as du le remarquer dans ton étude des pacman

[Top l'âne]

Je me pose en spectateur attentif.

[65c02]

Mince, c'est vrai ça. Bouffer un bonus à gauche le fait disparaitre à droite  
D'un autre coté, pourquoi pas. Si c'est assumé 

Tout en vert, ce n'est pas possible, ça casserai le code couleur qui dit évite / attrape.

Le flickering, c'est moche, et ça bouffe du cycle pour l'identifier. 
Ou alors c'est l'open bar du flickering et on fait une frame sur deux bonus ou ennemi 

Mine de rien, tout cela mérite d'être testé...

Là on mesure bien toute la difficulté des concessions de portage.

[Urbinou]

Mince, c'est vrai ça. Bouffer un bonus à gauche le fait disparaitre à droite

C'est à ça que ça sert les brainstormings, moi je n'avais pas pensé aux color clashs

J'ai beaucoup de mal à imaginer le jeu avec un PF miroir... on peut assumer les bonus, mais ça veut aussi dire que si tu tues l'ennemi de gauche, celui de droite ne boulette plus ? Alors que des boulettes arrivent du néant à gauche ?

En testant quelques cartouches récemment, je suis un peu revenu sur mon à priori sur le flickering, avec parcimonie ce n'est pas si gênant je trouve.

J'avais envisagé il y a un moment de faire un genre de manic en "hires" monochrome avec les 6 players imbriqués et centrés, c'est peut-être le moment d'exhumer l'idée ?
Bon, ça ça va bouffer de la ram par contre !


Edit : sinon, je ne l'ai pas dit, mais même en l'état, ta vidéo est déjà très impressionnante

[65c02]

Concernant le coté mirroir, j'ai deux idées en tête à tester.

1 - on s'en fout, le vaisseau ennemi n'est pas l'origine des émissions de boulettes. Ils provoque juste l'apparition de patterns pré-determiné. Si on shoot l'ennemi dans la partie haute de l'écran la ligne de boulette n'apparait pas.

2- les ennemis font des mouvements gauche / droite en descente. Ils ne tirent que lorsqu'ils croisent le centre et la logique symétrique est bonne.

J'avais envisagé il y a un moment de faire un genre de manic en "hires" monochrome avec les 6 players imbriqués et centrés, c'est peut-être le moment d'exhumer l'idée ? 

Bonne idée, tu titilles ma curiosité 

[drfloyd]

Faudrait demander à David Crane de passer sur le topic pour qu'il donne son avis ?

[Urbinou]

Quand je serai grand, je ferai pareil que ça


(bon ok c'est de la triche, c'est une rom DPC+ ! (processeur ARM additionnel)).

[drfloyd]

je reve de me mettre à l'ATARI 2600 pour réaliser Pitfall 3... Mais c'est juste un fantasme

[65c02]

Bon, j'ai  avancé sur ce que je vais appeler le moteur V1 = bonus et boulettes en playfield

J'ai ajouté un ennemi et au niveau du nombre de cycles, cela tient la route.
Pour l'instant l'affichage de l'ennemi repose sur une astuce et ne me coute que 8 cycles par ligne.
Par contre si je veux mettre plus d'ennemi je vais devoir insérer un ligne de positionnement par ennemi et ça pose un problème.

Avant de vous expliquez le problème je vais vous expliquer ce qu'est une ligne de positionnement.
Sur VCS les sprites peuvent avoir une position en x.
Mais cette position ne se définit pas en écrivant un chiffre dans un registre.
Pour définir la position en x, il faut écrire dans un registre spécifique (strobe) pile au moment où le canon à électron est à la bonne place.
C'est un peu comme si le TIA avait un chronomètre qui démarrait à chaque début de ligne et que les objets position-nable se déclenchait suivant leur minutage spécifique.
C'est un truc de fou.

Donc si vous voulez choisir une position il faut attendre le début d'une ligne, puis consommer le nombre de cycles nécessaire pour que le canon arrive à la position souhaitée.

Cela veut aussi dire qu'on peut très difficilement gérer un affichage sur cette ligne puisque qu'on doit passer son temps à attendre.
Dans 99% des cas, ces lignes sont vides.

Et donc, si je veux afficher plusieurs ennemis, je dois impérativement "neutraliser" une ligne avant chacun d'entre eux.
Si les ennemis avancent à la vitesse du playfield, pas de soucis, mais comme je veux en plus que mes ennemis aient une vitesse différente, cela rend la tache très très compliquée.
Je risque de faire disparaitre une ligne des boulettes ou les bonus.

A moins de trouver une astuce de fou, je pense donc faire une nouvelle concession : pas plus d'un ennemi à la fois sur l'écran.

Par contre, je pense pouvoir faire ce que me conseillait urbinou à savoir utiliser les missiles pour faire les bonus.
J'aurais, là aussi, une ligne de positionnement mais comme j'arrive à gérer mes deux sprites dans les 20 cycles de début de ligne avant l'affichage. Je peut avoir la boucle d'attente pour le positionnement en plus.

Ce sera l'objet de mon prochain test, le futur moteur V2

[Invité]

Excellent de te voir coder à nouveau 

Bon c'est clair que ça va être du sport de coder ça sur VCS,et vu la vidéo ça s'annonce plutôt bien, faut juste éviter le couloir sans boulettes  ..

[drfloyd]

c'est bien, tes explications nous permettent de réviser le fonctionnement tordu de l'affichage sur Atari 2600

[65c02]

Quand je serai grand, je ferai pareil que ça


(bon ok c'est de la triche, c'est une rom DPC+ ! (processeur ARM additionnel)).

Quand tu viendras manger à la maison, on discutera de "comment on fait un zaxxon" 

[Urbinou]

Je ne doute pas que ça captive nos moitiés

[drfloyd]

au fait, il est toujours possible de l'acheter BOMB ON PIXEL CITY sur Atari 2600 ??? Le type qui l'a mis en ligne gère toujours son affaire ?

[Urbinou]

Oui oui, Hozer officie toujours, c'est fabriqué à la demande.

[65c02]

J'ai tout repris de zéro pour tenter une autre approche.
J'utilise uniquement la balle.
J'ai 64 balles, une toutes les deux lignes.
Une ligne de positionnement et une ligne d'affichage.
Je suis assez agréablement surpris de l'effet produit.
On peut simuler beaucoup d'objets avec juste cette technique.
D'autant plus que je peut changer de couleur pour chaque boulette.

(J'ai ajouté un petit effet de cosinus pour rendre le tout moins fade )


Pour que ce test soit totalement validé je dois ajouter deux sprites et un tir par ligne.
Cela ne me semble pas impossible, j'ai énormement optimisé l'algo de positionnement.
Autre bonus de cette technique, je peut remettre le scrolling horizontal du jeu original.

A suivre....

[drfloyd]

ah là je suis content, Supa Zazai c'est forcement horizontal

[65c02]

ah là je suis content, Supa Zazai c'est forcement horizontal

Si on était dans les années 80 je t'aurais dit de poser ta TV sur la tranche

[Invité]

ah là je suis content, Supa Zazai c'est forcement horizontal

Si on était dans les années 80 je t'aurais dit de poser ta TV sur la tranche

[drfloyd]

65c02, toi qui connait bien l'Atari 2600 et la prog assembleur... quels sont les jeux de l'époque Atari 2600 (1977-1984 on va dire) qui t'impressionnent le plus techniquement ???

[Invité]

65c02, toi qui connait bien l'Atari 2600 et la prog assembleur... quels sont les jeux de l'époque Atari 2600 (1977-1984 on va dire) qui t'impressionnent le plus techniquement ???

E.T ?? 

[vincent2105]

sinon Doc, dans le même genre t'as ceux là :

Spoiler:

[Invité]

( sans être hors Topic, Pitfall sur Vcs 2600 était un putain de jeu ... )