Re: [WIP] Nouveau projet Atari 2600 : Tsunami!

[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.

[Urbinou]

Je vois, c'est une approche très originale et astucieuse du problème, c'est couillu !
Pour ma part, je pense faire des "unités" de 4, qui seront en plus bufferisées en ram, le problème ne se pose donc pas.

[Invité]

Ca fait plaisir de voir 65c02 poster
Bel effet raster l'ami,et si il n'y avait pas le mot vcs dans le titre du topic, je jurerai que vous parlez d'amiga ..
C'est incroyable les similitudes .

En tout cas continuez, la vcs est une machine incroyable .

[65c02]

Normal, l'amiga et la vcs ont le même papa 

bon sinon, Urbinou, je t'ai fait deux petits tableaux qui montrent à quel color cycle et cpu cycle commencent les affichages des registres playfield.

En mode miroir

68 22.6 pf0
84 28 pf1
116 38.6 pf2
148 49.3 pf2
180 60 pf1
212 70.6 pf0

En mode normal
68 22.6 pf0
84 28 pf1
116 38.6 pf2
148 49.38 pf0
164 54.60 pf1
196 65.38 pf2

Donc, en mode normal, tu dois taper dans 
pf0 après le cpu cycle 28 et avant le cpu cycle 148
pf1 après 39 (j'arrondi au dessus pour éviter tout glitch) et avant 54 (j'arrondit au dessous pour la même raison)
pf2 après 50 et avant 65

[Urbinou]

Minimum 15 cycles, tu vois hein qu'on a vachement le temps !
Merci beaucoup pour ce tableau très précis. Jusqu'ici j'ai fait plus ou moins au pif puis ajustements, il me sera donc bien utile.

[65c02]

Tu rigoles, 15 cycles c'est byzance. C'est presque la HBL
Pour le tableau, c'est tout bidon si tu gardes en tête qu'un cycle cpu fait 3 color cycles.
Et qu'une ligne d'image est composée de 68 color cycle de hbl puis 160 color cycle d'image.
Après tout se déduit : 76 cpu cycle par ligne, 22 cpu cycle dans la hbl, etc...
C'est easy, il faut juste oser 

[Urbinou]

Salut !

Non non, je n'ai pas encore abandonné ! Reprise du boulot oblige, j'ai pu un peu bidouiller à nouveau cette bonne vieille console  Ça fait du bien la programmation VCS, ça me fait un peu penser au RPG traditionnel pour ceux qui connaissent, où l'on est captif d'une boucle machine (ici le balayage écran).

Retour dans le source de mon petit projet, que j'aurais du documenter un peu mieux d'ailleurs, j'ai eu du mal à me relire ! Après avoir débuggé mon cycle de couleurs qui saccadait parfois (hé non, ce n'était pas du à youtube), j'ai mis en place une zone de jeu à scrolling vertical avec vitesse variable.
Le sprite bouge, je m'en sers pour faire varier la vitesse, à fins de test bien sûr.

Alors un petit mot à propos des sprites... vous savez déjà qu'il n'y a aucun buffer, il faut envoyer les données de sprite ligne par ligne, et bien horizontalement, c'est encore plus chaud ! Pour le placer sur X, il faut alimenter un registre pile au moment où le canon à électrons est à l'emplacement souhaité. Je vous passe d'autres détails hallucinants à ce sujet, mais c'est vraiment très chaud, croyez-moi ! Mais ne réinventons pas la roue, des routines géniales ont été développées, sachez seulement qu'une scanline doit être sacrifiée dans l'opération. Vous reconnaitrez la ligne, c'est celle qui affiche un artefact caractéristique à gauche.

Pour la zone de scrolling, j'ai mis en place un système avec des éléments de 8 points de haut, un buffer de 10 éléments pour le moment + 1 pour le shift (bye bye 66 octets de ram ). Dans un souci d'économie de rom, j'utilise des modèles de 3 octets, utilisables aussi bien pour la partie gauche du playfield que pour la partie droite. Toujours par mesure d'économie, vu que les modèles sont lus par adressage indirect, je les ai définis dans la zone FE00-FEFF. Ainsi, seul l'octet de poids faible doit être connu, et ça nous laisse plus de 80 modèles différents, ça devrait suffire. La définition d'un niveau de jeu se résume alors à une succession de paires de modèles.

Je n'ai pas encore parlé du "scénario". Son nom ? Tsunami! Vous êtes un pauvre surfeur piégé par un tsunami soudain, qui va devoir éviter les écueils et ruines  qui affleurent l'eau. Détails à suivre

Voici une petite vidéo de l'état actuel, rien de définitif bien sûr, on en est toujours à du proof of concept :

[Urbinou]

Je viens d'intégrer ma routine de sons, tout roule mais... il me reste 18 octets de ram. Va falloir être économe

[lulrik]

Je suit avec intérêt bon courage !

[upsilandre]

Alors un petit mot à propos des sprites... vous savez déjà qu'il n'y a aucun buffer, il faut envoyer les données de sprite ligne par ligne, et bien horizontalement, c'est encore plus chaud ! Pour le placer sur X, il faut alimenter un registre pile au moment où le canon à électrons est à l'emplacement souhaité. Je vous passe d'autres détails hallucinants à ce sujet, mais c'est vraiment très chaud, croyez-moi !

Je me souviens je trouvais que cette facon de gérer la position horizontal des objets etait vraiment la plus grosse lacune de la VCS. On se dit mais pourquoi ne pas juste avoir un registre 8bit ou t'indique la position H que tu souhaites plutot que devoir faire des resets ou des incrémentations?     Dès que tu veux afficher plus de 2 sprites ca devient une galère (meme si a la base la VCS est plutot concu pour des jeux comme combat qui dans ce cas pose pas vraiment de probleme).

Mais en fait tout ca est un soucis d’économie de transistors, le TIA c'est 6000 transistors, c'est tellement peu!!
Du coup la position des sprites est géré par un simple compteur 6bit polynomial (le type de compteur incremental le plus economique en transistors) et il sert a la fois de compteur et aussi a donner le signal de depart de l'affichage du sprite (quand le compteur reboucle a zero)  du coup effectivement pour modifier la position du sprite il faut forcer le reset de ce compteur a l'endroit de la scanline que tu souhaites. Et on comprend mieux aussi le fonctionnement du Hmove qui se contente au final de bloquer l’incrémentation du compteur (ce qui decale alors le sprite vers la droite) ou a l'inverse de l'autoriser pendant une phase ou il n'est pas censé l'etre (pour décaler vers la gauche) c'est a dire pendant le Hblank (en vrai c'est un peu plus subtile que ca car il va par defaut décaler systematiquement le Hblank de 8 pixels pour retarder l'incrementation des compteurs et donc décaler tous les objets de 8 pixels vers la droite et ensuite il va activer ou pas l'incrementation des compteurs des objets pendant le Hblank sur un délaie entre 0 et 15 clock selon les valeurs choisie pour les redécaler vers la gauche) , du coup on comprend aussi les glitch du Hmove et ses contraintes particulière d'usage.

Mais au final tout ca permet aussi pas mal de trick.
Pour mon space invader j'avais ete contraint de me pencher vraiment sur le fonctionnement interne du TIA pour pouvoir bien exploiter tout les trick qu'il permet.
Comprendre aussi que les registres GRP sont en fait des registres double et le fonctionnement du VDELP qui en decoule peut etre utile aussi. j'avais trouvé ca intéressant comme proposition d'autant que ca a du leur couter (mais je me souviens plus si au final j'en avais eu besoin)

[upsilandre]

En tout cas j'aime bien ta démarche de partir sur un projet completement original

[Urbinou]

Un petit point rapide sur mes progrès :
Le sprite est dessiné (7 positions) et ses mouvements gèrent la vitesse horizontale et verticale.
Il est intégré au décor, chose qui semble banale, mais ne l'est pas !
J'ai revu le "moteur" de scrolling, car je voulais une vitesse plus importante. Donc à faible vitesse, on se contente de compter les images entre les décalages, à plus haute vitesse, on doit décaler plusieurs fois par image.
J'ai mis en place un écran titre - vide, avec sa musique spécifique. Le bouton lance le jeu.

Voila, ça n'a l'air de rien comme ça, mais je suis assez satisfait



Qu'est ce que vous en pensez, ça commence à ressembler à quelque chose, non ?

[drfloyd]

le sprite est super réaliste ! J'adore.

[lulrik]

pas mal !! je connais la musique d'intro, tu l'avais montré tu a bien fait de l'utiliser

[vingazole]

[Urbinou]

Merci
La musique, c'est temporaire. J'essaierai de faire un thème plus tard, ou bien je lui demanderai, après tout il est bien plus doué que moi ! Vous pouvez aussi proposer hein
Pour le sprite, il n'y a que les quadra+ pour s'extasier devant 8 pixels, notre imagination a été aiguisée

[Invité]

Résultat vraiment intéressant ! 
Et tout ça en asm, moi ça me troue le c..., vous étés trop forts les gars. Respect.
Bon courage pour la suite. :)

[65c02]

Excellent !
j'adore la vague du haut et le gameplay semble bien fun 

[Urbinou]

Merci les amis

Tiens 65c02, tu n'avais pas un truc à nous montrer à la rentrée ?  

En tout cas j'aime bien ta démarche de partir sur un projet completement original

Je dois humblement avouer que je me suis quand vachement inspiré d'un autre jeu dans son concept : paper planes

[upsilandre]

L'aire de rien l'ajout du sprite est une etape importante car c'est lui qui permet de comprendre le contexte. Et comme tu l'as tres bien réussit ca fonctionne.

[upsilandre]

Je dois humblement avouer que je me suis quand vachement inspiré d'un autre jeu dans son concept : paper planes

A partir du moment ou les mecaniques de jeu sont simples (ce qu'elles sont en général sur VCS) en général elles existent ailleurs. Je pensais surtout au contexte (mais tu me dira que ca peut rappeler California game mais la création c'est souvent ré-assembler differement des truc qui existe deja, y a pas de quoi en rougir)

[Urbinou]

A partir du moment ou les mecaniques de jeu sont simples (ce qu'elles sont en général sur VCS) en général elles existent ailleurs. Je pensais surtout au contexte (mais tu me dira que ca peut rappeler California game mais la création c'est souvent ré-assembler differement des truc qui existe deja, y a pas de quoi en rougir)

Je n'avais jamais vu le california games vcs (je viens d'aller voir sur youtube), c'est du haut niveau !
C'est vrai que c'est très difficile, après des décennies de jeux vidéos, de trouver un concept original. Je suis très admiratif de ceux qui y arrivent encore et qui exploitent un élément de gameplay nouveau.
Mon but ici, c'est avant tout de me faire plaisir, de tomber sur un problème, le contourner ou le résoudre, et de tenter de réaliser un jeu de a à z, sur une console dont à l'époque, je n'imaginais même pas que ça puisse être programmé. J'espère en plus que ce sera au moins un peu fun à jouer, et vos commentaires font beaucoup de bien, parce qu'on s'interroge énormément quand on se lance dans un projet de ce genre, si simple soit-il.

[Invité]

Je n'avais jamais vu le california games vcs (je viens d'aller voir sur youtube), c'est du haut niveau !

Moi non plus et je doit dire que je suis   tout plein ..
Encore plus impressionnant que DK ..

kung fu master aussi est une belle conversion officielle de 87 quand même ..

[upsilandre]

California game j'aimais bien l'utilisé comme exemple pour montrer le carnage de la console Secam qu'on a eu en france (qui fonctionne en faite toujours en mode "noir et blanc" recolorisé en output).

Du coup nous en France on ne sait pas a quelle point l'Atari 2600 avait une palette riche, il a fallu atteindre la PC-Engine pour avoir mieux il me semble (ou le MSX2 si on le considere comme une console ce qui n'est pas vraiment le cas).

[Urbinou]

La palette, ça a toujours été le point fort des Atari, et ce depuis Pong !
Ah ouais, la version secam, ça donne tout de suite envie... de gerber !
A l'époque en France (début 80), en majorité les télés étaient exclusivement secam, ou pal/secam ? Et dans ce cas une console pal aurait pu être utilisée.
Mais même en PAL, certaines conversions NTSC ont été baclées, Battlezone par exemple :


Je ne comprends d'ailleurs pas pourquoi la palette pal a été revue et chamboulée de la sorte... 128 vs 104 couleurs, et disposées autrement

[upsilandre]

La transition du Secam au PAL a débuté seulement debut 1980 donc assez tard (la meme année ou la pertiel RGB est devenu obligatoire en France ce qui cette fois a l'inverse nous a valut d'avoir la meilleur Master System au monde niveau qualité d'image apres avoir eu la pire VCS au monde).

[Urbinou]

Je ne me suis jamais plaint de mes connexions antenne, mais c'est vrai que ça m'intriguait beaucoup vos fiches peritel

[upsilandre]

Je ne comprends d'ailleurs pas pourquoi la palette pal a été revue et chamboulée de la sorte... 128 vs 104 couleurs, et disposées autrement

A mon avis elle a pas ete revu, c'est juste que le signal PAL est different et que pour avoir la meme palette qu'en NTSC ca aurait sans doute demander un peu plus d'electronique j'imagine, sur une machine aussi simple c'est embêtant, la particularité de la VCS c'est sa maitrise des couts.
Sur la palette d'origine tu as 16 valeurs de chrominances et 8 de luminances. A priori la facon de produire le signal de chrominance par le TIA ne donne pas les meme couleurs en PAL, et y a notamment 4 valeurs sur les 16 qui en PAL produisent le meme effet d'absence de chrominance (qui sert donc pour le blanc et ses variantes) ce qui veut dire 3 valeurs de chrominance perdu d'ou les 3x8=24 couleurs en moins.

[upsilandre]

Je ne me suis jamais plaint de mes connexions antenne, mais c'est vrai que ça m'intriguait beaucoup vos fiches peritel

Avec la master system on avait l'arcade a la maison

[vingazole]

Oui mais l'arcade du début des années 80, alors

[Invité]

La SMS est une bonne machine