[WIP] Nouveau projet Atari 2600 : Tsunami!

[Urbinou]

Salut !

Me revoila pour un petit projet Atari 2600 qui me trotte dans la tête
J'ai longtemps hésité à en parler ici avant d'avancer un peu, surtout après le fiasco de mon projet Sister's run, dans lequel j'ai péché par excès d'optimisme (pas assez de cycles machine pour mes objectifs en l'état, mais j'ai pas dit mon dernier mot).
Mais voila, je me suis dit que ça pourrait être amusant à suivre, enfin pour les 3 pelés ici présents qui s'intéressent à la fois à l'atari 2600 et à sa programmation assembleur

J'ai donc commencé à tester la viabilité de certaines idées.
Comme par exemple voir le nombre de cycles disponibles avec un playfield asymétrique.
Mais je brûle les étapes... quelques explications pour les personnes qui l'ignorent : cette console est totalement dépourvue de buffer d'affichage. Et elle a 128 octets de RAM. Oui. Donc pour afficher quelque chose à l'écran, il faut se faire copain avec le balayage de l'écran, et ne pas le lâcher d'une semelle. Et notre programme doit envoyer les infos nécessaires dans les bons registres au bon moment.
Pour afficher quelque chose, la console dispose de 2 sprites, 2 missiles, une balle et un playfield. C'est en gros une pong de luxe
Le playfield, c'est un affichage basse résolution qui sert généralement de décor, de 40 éléments horizontaux (vu leur taille, on appellera pas ça des pixels !) sur 192 lignes (ntsc). Mais bon faut pas rêver non plus, de base, vous pouvez choisir la composition des 20 premiers éléments, et les 20 suivants sont soit une copie des 20 premiers, soit leur miroir.

Un exemple très parlant : Combat


Un playfield asymétrique, c'est donc la possibilité d'afficher 40 éléments choisis. Comment ? Grâce à notre copain  le canon à électrons.
Pour afficher une ligne de balayage, le processeur a le temps d'exécuter 22 cycles machine avant la zone visible, puis 54 cycles machine dans la zone visible, sachant qu'une instruction consomme entre 2 et 6 cycles...   L'astuce, c'est donc de synchroniser le programme avec le début de la ligne, d'affecter les registres de playfield avant leur affichage, donc durant les 22 premiers cycles machine pour le premier (PF0), environ une trentaine de cycles pour le 2e (PF1), et encore une vingtaine de plus pour le 3e. Il faut ensuite très rapidement les réaffecter avec les valeurs de la 2e partie, avant que le balayage n'atteigne la 2e moitié de la zone visible. Fastoche.

Test effectué et concluant, il y a un peu de marge avant et après pour faire diverses choses, tous les espoirs sont permis  


Oui, c'est très spectaculaire, j'en conviens.

A bientôt pour la suite de mes trépidantes aventures

[bfg]

J'avais maté quelques tutos sur la prog A2600 ... Je ne comprends même pas comment on arrive à faire des jeux avec des contraintes pareilles :) :) Chapeau !

[Invité]

Ouhaou, je suis quand même impressionné par ton sister's run, dommage que ca se soit pas concrétisé, des sprites aussi colorés sur vcs c'est pas courant il me semble ..

Comme bfg, quand on voit ce que les gens arrivent à faire avec 

[Urbinou]

J'avais maté quelques tutos sur la prog A2600 ... Je ne comprends même pas comment on arrive à faire des jeux avec des contraintes pareilles :) :) Chapeau !

Oui, je suis très admiratif des programmeurs de l'époque, parfois des morceaux de programme qui tiennent du génie, et tout ça à une époque où il n'existait pas d'émulateur pour tester en live et débugger. Et quand je vois ce que les programmeurs homebrew actuels nous pondent, je suis juste une toute petite crotte
Le chapeau est un peu prématuré, je l'accepterai si j'arrive au bout de ce que je veux faire

[Invité]

Allez courage Urbinou.
Ne lâches pas l'affaire, on est tous dans ce petit bateau et on rame tous ensemble.
Tous mes encouragements pour cette nouvelle aventure !
Et aussi mon admiration, car coder en asm avec des contraintes d'il y a presque 40 ans, je te tire mon chapeau.

[Urbinou]

Ouhaou, je suis quand même impressionné par ton sister's run, dommage que ca se soit pas concrétisé, des sprites aussi colorés sur vcs c'est pas courant il me semble ..

Comme bfg, quand on voit ce que les gens arrivent à faire avec 

Bah oui, si c'est pas courant, c'est sans doute pour une bonne raison  Une fois que tu as affiché ton joli sprite, il ne reste quasiment plus de temps cpu pour faire autre chose (ici afficher le playfield asym en l'occurence). J'y reviendrai sans doute plus tard, en utilisant un format de cartouche qui embarque de la ram, pour pouvoir bufferiser le sprite et gagner quelques cycles. Mais je ne sais même pas si ce sera possible comme ça. Même si j'aurais bien aimé coller aux contraintes de l'époque, soit ram standard 128 bytes et rom de 4K.

En tout cas, si je t'ai impressionné, je suis super fier

[Urbinou]

Allez courage Urbinou.
Ne lâches pas l'affaire, on est tous dans ce petit bateau et on rame tous ensemble.
Tous mes encouragements pour cette nouvelle aventure !
Et aussi mon admiration, car coder en asm avec des contraintes d'il y a presque 40 ans, je te tire mon chapeau.

Aurais-je une tête à chapeau ?
Merci Vetea. A toi aussi je pourrais dire la même chose à chacun de tes posts "papi"
Chacun à notre façon on aime relever les défis posés par ces vieilles bécanes.

[Invité]

En tout cas, si je t'ai impressionné, je suis super fier 

Eh ,oh je suis pas david perry non plus ,je suis comme vous, et c'est couillus de coder sur vcs alors oui je suis impressionné ..

[vingazole]

Mais voila, je me suis dit que ça pourrait être amusant à suivre, enfin pour les 3 pelés ici présents qui s'intéressent à la fois à l'atari 2600 et à sa programmation assembleur

Avec moi ça fait 4 pelés

Encore un beau challenge, cette histoire de playfield asymétrique, chapeau pour ton courage !

[Urbinou]

Bienvenue dans le club des pelés

[chiss]

moi je suis tondu...je peux ?

[vincent2105]

INC pelés 

Merci pour ce topic  Urbinou 

[Invité]

Que des tarés dans ce topic 

[Urbinou]

Bonjour à tous les pelés et tondus tarés

J'ai tenté de faire un petit effet sympa : un cycle de couleurs montantes et descendantes imbriquées pour représenter... non, je ne vais pas le dévoiler tout de suite !

J'ai dessiné un petit playfield de 22 lignes :


Voila, très simple à mettre en place, c'est un playfield en mode copie. Les data sont en rom.
Comme les registres PFx conservent leur valeur tant qu'on ne les modifie pas, pour éviter de voir la dernière ligne répétée jusqu'en bas de l'écran, j'ajoute une 23e ligne à 0 qui sera traitée comme les 22 autres.

Pour rappel, l'assignation des couleurs de fond et de playfield se font à la volée à chaque balayage écran, la saisie de la donnée à envoyer doit donc se faire très rapidement, on ne peut se permettre de décaler des valeurs en ram, de faire des tests avec retour au début du cycle etc..., ni d'ailleurs de gaspiller 22*2 octets de ram sur les 128 disponibles !
Vu que nous avons profusion de rom à notre disposition (4K, c'est Byzance !), les données de couleurs y seront stockées. Pour générer l'effet de cycle, j'ai dupliqué les données. J'ai donc 22+22 couleurs * 2 (fond et PF) qui peuvent être lues en séquence, seul le point de départ sera augmenté à chaque image.
Voici ce que ça donne :


C'est pas très visible dans la vidéo, mais pour obtenir l'effet que je souhaite, les couleurs montantes sont plus lentes que les descendantes.
J'ai également affiché un sprite qui va me servir de cobaye, prépare-toi à souffrir sprite
Je vous en reparle bientôt.

Voila, n'hésitez pas à me dire si je vous saoûle, ou si vous voulez des explications plus précises sur certains points, mon but ici est juste de décrire les spécificités du bestiau, les moyens de contourner les contraintes et de donner un aperçu du développement dessus.
A bientôt !

[Invité]

sympa le truc, on dirait que tu fais une sorte de swap de couleurs, c'est pas ce que tu cherches à faire en fait non ??

Sur le coup je pensais à une sorte d'effet de vague .

[Urbinou]

sympa le truc, on dirait que tu fais une sorte de swap de couleurs, c'est pas ce que tu cherches à faire en fait non ??

Qu'entends-tu par "swap" ? J'ai fait un ensemble de couleurs sombres qui montent et des plus claires qui descendent pour donner un effet "rouleau". Ca ne se voit pas très bien sur la vidéo...

Sur le coup je pensais à une sorte d'effet de vague .

...mais finalement on dirait que je suis arrivé à mes fins  

[philip]

Ouhaou, je suis quand même impressionné par ton sister's run, dommage que ca se soit pas concrétisé, des sprites aussi colorés sur vcs c'est pas courant il me semble ..

Comme bfg, quand on voit ce que les gens arrivent à faire avec 

Bah oui, si c'est pas courant, c'est sans doute pour une bonne raison  Une fois que tu as affiché ton joli sprite, il ne reste quasiment plus de temps cpu pour faire autre chose (ici afficher le playfield asym en l'occurence). J'y reviendrai sans doute plus tard, en utilisant un format de cartouche qui embarque de la ram, pour pouvoir bufferiser le sprite et gagner quelques cycles. Mais je ne sais même pas si ce sera possible comme ça. Même si j'aurais bien aimé coller aux contraintes de l'époque, soit ram standard 128 bytes et rom de 4K.

En tout cas, si je t'ai impressionné, je suis super fier

L'affichage d'un seul sprite qui monopolise autant, c'est hallucinant, du codage en mode very hard. Bon courage pour la suite.

[Urbinou]

L'affichage d'un seul sprite qui monopolise autant, c'est hallucinant, du codage en mode very hard. Bon courage pour la suite.

Merci  
Il faut savoir qu'un sprite est monochrome, mais on peut bien sûr changer cette couleur à chaque ligne. Dans ce cas précis, pour avoir autant de couleurs, j'ai superposé les 2 sprites et, à chaque ligne pour chaque sprite je dois leur donner une forme (les pixels) et une couleur. Tout ça en adressage indirect indexé qui bouffe plein de cycles, et voila comment on a plus le temps de rien faire d'autre !

[Invité]

mais finalement on dirait que je suis arrivé à mes fins  

Ouai c'est bien ce qui me semblait ..

C'est pas ce genre d'effet de couleurs que tu cherchais à faire ??
https://youtu.be/5CUUOlYxlZ8?t=1m15s

Celui du fond ..

[Urbinou]

Ah ça ! Depuis le C64, j'appelle ça des rasterbars moi
J'ai choisi mes couleurs pour simuler une surface "plate" qui monte, pas pour faire des tubes dégradés, mais oui sinon c'est le même principe.

[Invité]

lol, donc ok c'est pas des rasterbars alors .. 

[Urbinou]

Désolé, ça fait un moment que j'ai quitté la demoscene (si on peut dire que j'en ai jamais fait partie), vers 88, la terminologie a bien évolué

[65c02]

pelé++

Tiens mon grand, pour la peine, je t'ai fais un effet de "raster" sur vcs.

[Urbinou]

Merci, très joli effet !
Mais... je n'ai pas voulu faire des rasters

[65c02]

Mince, pour une fois que c'était facile de faire un effet sur vcs... 

Blagues à part, j'ai pas mal fait de tests sur les playfield asymétriques alors n'hésites pas a lancer des discussions pointues sur le sujet  .

Par exemple, j'ai remarqué qu'il vaut mieux avoir les deux colonne sau centre, identiques.
Sur émulateur, ça marche bien mais sur une vrai vcs, l'update du playfield prend parfois le nouveaux dernier bit du pf2; parfois l'ancien.
C'est comme si la synchro du bouzin était "analogique" et qu'on tombait dans un effet d'arrondi de virgule.
J'ai essayé d'écrire un cycle cpu plus tôt, mais j'ai comme prévu eu l'update trop tôt des 3 pixels sur le pf2 gauche.
Du coup, sur bomb on pixel city tu remarquera que les immeubles au centre ont un espace plus grand. 

[Urbinou]

Par exemple, j'ai remarqué qu'il vaut mieux avoir les deux colonne sau centre, identiques.
Sur émulateur, ça marche bien mais sur une vrai vcs, l'update du playfield prend parfois le nouveaux dernier bit du pf2; parfois l'ancien.
C'est comme si la synchro du bouzin était "analogique" et qu'on tombait dans un effet d'arrondi de virgule.
J'ai essayé d'écrire un cycle cpu plus tôt, mais j'ai comme prévu eu l'update trop tôt des 3 pixels sur le pf2 gauche.
Du coup, sur bomb on pixel city tu remarquera que les immeubles au centre ont un espace plus grand.

Tiens, tu m'étonnes... parce qu'on a vachement le temps (pour une fois) d'updater les PF après (à gauche) et avant (à droite) leur affichage.
Tu n'aurais pas plutôt du écrire un cycle plus tard justement ? Je vérifierai sur la console (il me semblait l'avoir fait ceci dit), mais en théorie pour ce que je veux faire, le centre devrait de toutes façons être identique.

[philip]

C'est jolie.

[65c02]

Tiens, tu m'étonnes... parce qu'on a vachement le temps (pour une fois) d'updater les PF après (à gauche) et avant (à droite) leur affichage.
Tu n'aurais pas plutôt du écrire un cycle plus tard justement ? Je vérifierai sur la console (il me semblait l'avoir fait ceci dit), mais en théorie pour ce que je veux faire, le centre devrait de toutes façons être identique.

En fait, tu n'as pas tant de temps que ça parce que tu ne dois pas modifier les registres avec les données de la partie droite, tant qu'ils n'ont pas servit à l'affichage de la partie gauche.
En plus, le registre modifié est instantanément pris en compte. Si tu écris dans pf2 alors qu'il a affiché la moitié de celui ci, la deuxième moitié sera remplit de tes nouvelles valeurs.

Je réalise en écrivant tout ça que pour bomb on pixel city j'utilisais le mode miroir pour avoir un jolie cadre noir autour du jeu et que c'est ça qui m'a compliqué la vie.
Je devais modifier pf2 pile poil à la fin de son affichage de la partie gauche, au color cycle près.
hors c'est impossible car 1 cpu cycle fait 3 color cycles et que le multiple ne tombe pas dans le bon timing.

Bref tout ça pour dire qu'il faut éviter le mode miroir en playfield asymetric (sauf si on veut un cadre trop la classe )

[Urbinou]

Figure-toi que J'ai failli te demander si tu n'avais pas fait ton pf asym en miroir, puis je me suis dit meuh non quelle question idiote !!!  

PS: vachement le temps, tout est relatif hein, on est pas à 1ou 2 cycles quoi

[65c02]

remarque le mode miroir ne m'a pas donner que le cadre noir (pf0  = 0b111)
il m'a permis d'avoir 4 colonnes successive alignées sur un octet. Ce qui est super utile pour afficher les immeubles sans aucun traitement. Comme le PF0 ne fait que 4 bits, ta ligne est structurée 488884.
si j'avais pris l'autre mode, j'aurais eu 488488 et ça aurait été couteux en data pour faire le même rendu.
Comme au final je ne suis vraiment pas loin des 4 Ko, j'aurais été forcé de faire un jeu en 8Ko. Juste pour avoir un espace plus petit entre les deux immeubles du centre.

En plus je n'avais que pf1 et pf2 à gérer sur chaque ligne, car mon pf0 est constant pour le cadre.. 
Gros gain de cycle.
Donc le mode miroir peut être très très utile. Mais faut accepter de payer le prix des deux colonne du centre parfaitement identiques.