[WIP] Sisters' run ATARI 2600

[Urbinou]

Allez, après moult hésitations, je me lance !

J'ai décidé de rassembler et mettre en pratique mes quelques connaissances éparses acquises en programmation vcs, dans un projet de petit jeu. Si j'ouvre ce topic, c'est en espérant qu'il me motive, m'encourage et me dissuade d'abandonner. N'espérez évidemment pas un chef-d'oeuvre, c'est ma première réalisation, il faudra être indulgent   

Voici le scénario : (et déjà ici un premier appel à votre indulgence    )

Giana et Maria, les célèbres soeurs, sont très irritables depuis qu'elles ont fait ce rêve zarbi (cf notice).
Pour se détendre, elles décident de sortir en boite ce fameux soir. La soirée se passait très bien, jusqu'à ce qu'elles flashent toutes les deux pour le même beau jeune homme. Vu leur tempérament latin, elles commencèrent à se créper le chignon en public, ce qui fit fuir à toutes jambes l'objet de leur discorde. Elles décidèrent alors de se mettre à sa poursuite, en se promettant que la perdante se retirerait de la compétition.

Hum.. voila...  

Il s'agira donc d'un runner, jouable à 2, dans lequel j'espère insuffler suffisamment de gameplay intéressant. J'espère pouvoir proposer différents modes de jeu ou, qui sait, une ia pour prendre la place du joueur 2.

Mais ne brûlons pas les étapes, je n'en suis qu'au proof-of-concept :



Le sprite en 4 étapes a été rippé de la version C64 et adapté. Sa forme n'est pas encore définitive.

Voila, à bientôt (j'espère    ) !


Edit :

Les stats :
- ram : 17 octets (+ 3 pour la pile)
- code : 453 octets
- data : 234 octets
- vbl : 89 cycles

[chiss]

bah rien que le sprite est deja tres bien dessiné pour de la 2600 !!!! moi je dis OUI !!!!!   

courage et determination !!! tu y arriveras ! j'admire tout cela et je suis tres respectueux de ce travail !!

bon courrage et tiens nous informé !!!!

[Invité]

Bonjour Urbinou !

C'est bien de se lancer dans l'aventure et crois moi qu'ici, on est pas mal de malades !!
Mais on se croise les coudes et on s'encourage pour avancer et faire perdurer nos folies ludiques !!

A bientôt et au plaisir de découvrir tes avancées !

[fanoplusplus64K]

rigolo comme concept , bon courage !

[Urbinou]

Merci pour tous vos encouragements les gars  

[drfloyd]

Super projet !!! On va suivre ça et t'encourager !

le sprite est vraiment incroyable pour de l'Atari 2600 !!!

Mais pas trop compris le concept du jeu, c'est une course à obstacles ? ou façon Decathlon ?

[Urbinou]

Oh rien d'exceptionnel dans le sprite, j'ai juste superposé les 2 players vu que je compte me servir du playfield pour les obstacles, et des missiles/ball pour d'autres trucs... en espérant que ce soit convaincant. Je ne suis pas encore au niveau des mecs qui ont fait le nouveau donkey kong   

C'est un runner, donc le personnage avance tout seul, de plus en plus vite au fur et à mesure. J'envisage aussi de déplacer le perso vers la droite au bout d'un moment, ça laisse moins de temps pour réagir. Et je réfléchis au moyen d'interagir entre les persos, genre jeter une peau de banane à son adversaire.

Bref j'avance tout doucement quand j'ai le temps (tu sais ce que c'est), je verrai ce qu'il est possible de faire. Et qui sait, grâce à ce fil, de bonnes idées pourraient venir de vos suggestions  

[drfloyd]

tu programmes en quoi ?

[Urbinou]

Assembleur, c'est là tout le plaisir de la chose

[drfloyd]

je voulais savoir car il y a eu beaucoup de jeux dév en Batari ces derniers temps.

C'est tout à ton honneur !!!!  

[Urbinou]

J'ai beaucoup de mal à faire confiance à un produit dont le nom commence par "batar"   

Plus sérieusement, le BBasic est un produit assez incroyable, mais je préfère avoir les pleins pouvoirs, et puis bon, l'asm c'est un peu ma madeleine de Proust.

[Invité]

Les personnes qui maitrisent l'Asm sont pour moi des Chevaliers Jedi.
Que la force soit avec toi !  

[drfloyd]

J'ai beaucoup de mal à faire confiance à un produit dont le nom commence par "batar"   

Plus sérieusement, le BBasic est un produit assez incroyable, mais je préfère avoir les pleins pouvoirs, et puis bon, l'asm c'est un peu ma madeleine de Proust.

C'est clair

Même si certains ont réussi a faire des jeux largement supérieurs à beaucoup de jeux d'epoque avec BATARI

[Urbinou]

Hello !

Episode 2 de ma petite aventure :

Après le proof-of-concept de la semaine passée, j'ai mis en place l'aire de jeu.
A grands renforts de pointeurs, la routine d'affichage a été généralisée. Du coup, Giana et Maria ont maintenant leurs propres affichages et couleurs. De même, maintenant chacune a son sol et sa vitesse qui lui est propre. Le score lui est par contre toujours commun, je n'ai pas encore eu le temps de le dissocier.

Comme toujours en programmation vcs, il s'agit d'un savant dosage entre le code, la ram et les cycles cpu : la routine d'affichage est commune, cela économise du code mais consomme de la ram (2 octets par pointeur, et il en faut 3 par sprite) et du temps cpu puisqu'il faut initialiser les pointeurs avant appel à la sous-routine. Pour le scrolling du sol par contre, chacune a sa routine, cela économise des pointeurs mais en contrepartie consomme du code.

Le sprite en lui-même a été un peu retouché, mais je ne suis pas encore satisfait de l'animation des jambes. Je vais bientôt être obligé de faire du motion-capture, quelqu'un pour me prêter sa fille ?   



Pour terminer, voici mes petites stats hebdomadaires :

- ram : 62 octets (+ 3 pour la pile)
- code : 1063 octets
- data : 382 octets
- vbl : 489 cycles

Rendez-vous au prochain épisode ?  

[grostonton]

C'est vachement courageux de ta part de t'attaquer à de la prog assembleur, chapeau.

Juste un truc, il me semble que l'animation du personnage en bas est plus lente que celle d'en haut, c'est normal ?

[Urbinou]

Merci Tonton   
Oui c'est normal, je l'ai fait pour tester la gestion des différentes vitesses de façon indépendante.
Mais bien vu, toutes les 6 frames pour Giana, toutes les 8 frames pour Maria, il fallait le remarquer  

[65c02]

Urbinou développe un jeu sur VCS 2600 ?!
Et en asm en plus ?!
Et c'est beau ?!
 
Yes !

[Urbinou]

Hééé y vit toujours mon copain ?   
Content de te revoir par ici !
Sois pas trop pressé pour le "jeu", vu la vitesse à laquelle j'avance   

[65c02]

Au moins t'avance
j'aime beaucoup le choix des couleurs du sol et des persos 
prends tout ton temps

[drfloyd]

Oui le choix des couleurs est excellent

[Meeyavi]

carrément pas mal vivement la suite :)

[drfloyd]

Je ne suis pas encore au niveau des mecs qui ont fait le nouveau donkey kong  

Justement toi qui connait l'assembleur et l'Atari 2600, explique moi comment ils ont fait :



Perso j'avais cru au fake tellement c'est enorme

[Invité]

[Urbinou]

Il faudrait poser la question à 65c02, je crois qu'il avait jeté un oeil au code, contrairement à moi
Mais selon toute vraisemblance, il est plus que probable que c'est un format de cartouche/rom qui embarque (beaucoup) de la ram supplémentaire. Ca permet de garder en mémoire un buffer d'affichage.
Ensuite les sprites sont probablement affichés en plusieurs images de façon à avoir plusieurs couleurs, la rémanence de l'écran faisant le reste. Mais c'est très fort, parce que le clignotement est à peine notable.
Le kernel (la partie qui du programme qui gère l'affichage ligne à ligne) doit être assez monstrueux et doit être préconstruit, peut-être par auto-modification de code en ram comme notre ami upsilandre a fait pour son impressionnant space invaders, parce qu'il met en oeuvre diverses techniques permettant d'avoir plus de 2 sprites par ligne sans clignotement, spécifiques à chaque cas.
Certaines cartouches/roms utilisent aussi des coprocesseurs, un peu comme pitfall 2, dans ce cas le kernel devient juste un programme d'affichage, mais je ne sais pas si c'est le cas de celui-ci. C'est un grand débat parmi les développeurs homebrew, jusqu'où peut-on aller ? Peut-on considérer qu'un programme qui se contente de recevoir des datas et de les afficher, le process se faisant dans la cartouche, est fidèle à la philosophie hb ?
A l'occasion, j'y jetterai un oeil et je vous ferai part de mes découvertes.

[65c02]

Il faudrait poser la question à 65c02, je crois qu'il avait jeté un oeil au code, contrairement à moi
Mais selon toute vraisemblance, il est plus que probable que c'est un format de cartouche/rom qui embarque (beaucoup) de la ram supplémentaire. Ca permet de garder en mémoire un buffer d'affichage.
Ensuite les sprites sont probablement affichés en plusieurs images de façon à avoir plusieurs couleurs, la rémanence de l'écran faisant le reste. Mais c'est très fort, parce que le clignotement est à peine notable.
Le kernel (la partie qui du programme qui gère l'affichage ligne à ligne) doit être assez monstrueux et doit être préconstruit, peut-être par auto-modification de code en ram comme notre ami upsilandre a fait pour son impressionnant space invaders, parce qu'il met en oeuvre diverses techniques permettant d'avoir plus de 2 sprites par ligne sans clignotement, spécifiques à chaque cas.
Certaines cartouches/roms utilisent aussi des coprocesseurs, un peu comme pitfall 2, dans ce cas le kernel devient juste un programme d'affichage, mais je ne sais pas si c'est le cas de celui-ci. C'est un grand débat parmi les développeurs homebrew, jusqu'où peut-on aller ? Peut-on considérer qu'un programme qui se contente de recevoir des datas et de les afficher, le process se faisant dans la cartouche, est fidèle à la philosophie hb ?
A l'occasion, j'y jetterai un oeil et je vous ferai part de mes découvertes.

Je suis ABSOLUMENT d'accord avec TOUT ce que dit urbinou 

[Invité]

Il est incroyable ce DK, rien à dire .
@doc:fake ??, non je pense que quitte à faire un fake, il aurait animé le feu dans le tonneau .

[upsilandre]

C'est vrai que c'est dommage de pas avoir animé le feu du tonneau de depart alors que tout le reste est tres bien animé. A priori une simple modification de pointeur devrait suffire pour avoir au moins 2 frames d'animations si il reste la place sur la cartouche. Si jamais il peut le faire ca serait intéressant a ajouter comme dernier détail car ca fait partie des signatures reconnaissables du jeu.

Par contre il a pas l'aire d'utiliser une cartouche special. Y a pas de customisation dedans comme dans Pitfall 2. C'est juste une grosse cartouche de 32Ko, la plus grosse qui ait existé sur VCS (Utilisé pour Fatal Run une sorte de Pole position) mais ca a existé et avec 128 octets de RAM ce qui double la capacité de la console (ce qui n'est pas le max, quelques jeux officiels utilisent 256 octets de RAM dans la cartouche).
En gros c'est la meme cartouche et le meme type de mapper que Millipede mais avec 2 fois plus de bank (ou exactement la meme cartouche que Fatal Run). Donc ca reste "correct".

Quand tu fais usage de toute la capacité d'affichage de sprite en exploitant le double buffering des registres sprites et les 3 registres du 6502 tu peux faire un sprite de 48 pixels de large (avec des pixels qui font le double de ceux d'une Megadrive donc l'equivalent en taille d'un sprite 96 pixels sur MD), c'est souvent utilisé pour afficher du texte et c'est ce qu'ils font sur Donkey Kong.
La ou ca devient galère je pense c'est quand faut le deplacer a l'horizontal comme il fait avec Donkey kong parfois.

Il fait surtout un usage impressionnant du flikering pour multiplier les couleurs!
Donkey Kong par exemple a jusqu'a 4 couleurs sur la meme ligne! (et pas juste sur des lignes successive ce qui est tres different). A la premiere frame il fait dabord une couche monochrome en beige et pour le blanc des yeux et des dents il utilise de facon ingenieuse le playfield (le background). Puis il fait une seconde couche de marron a la frame suivante et avec des superpositions avec la couche precedente pour crée un 3eme marron intermédiaire (ce qui d'ailleurs ajoute donc de nouvelles couleurs a la palette qui est deja riche sur VCS on oublie souvent de le rappeler).

Pour la zone de jeu elle meme Mario se réserve un sprite hardware pour lui (avec flikering pour ajouter des couleurs et aussi du changement de couleur plus classique selon la ligne) et le second sprite hardware est reservé pour les obstacles du jeu (tonneau, boule de feu, plat de nouille). Le jeu a ensuite ete adapté en terme de leveldesign pour qu'il n'y ai qu'un seul obstacle par etage (ou alors une duplication hardware).
Le marteau lui utilise ingénieusement le premier "missile" hardware qui n'est pas tout a fait un sprite mais qui permet de simuler des sprites simple et "plein" comme celui la.

Mais ce que j'aime bien aussi c'est le fait d'avoir ajouter du scrolling vertical. J'aime bien voir du scrolling sur VCS, ca rappelle que son hardware est d'une certaine facon mieux lotie sur ce point qu'un MSX ce qui est cocasse.

Le resultat de tout ca combiné donne un truc vraiment classe et parfait (manque juste effectivement l'animation de la flamme du premier tonneau :) )