[TERMINE] Bomb On Pixel City / Atari 2600

[65c02]

Le truc chiant quand on fait des homebrew sur des consoles anciennes, c'est que personne pige vraiment ce qu'on fait.
On est tout seul comme un con quand on a pigé la maitrise un comportement bizarre du hardware.
On voit des choses géniales et on est tout seul dans sa bulle pour en profiter.
On n'ose pas trop en parler sur les forums parce qu'on ne veut pas faire le gars qui se la raconte.
On aimerait bien partager mais on ne sais pas avec qui.
On a peur de déranger.
La seule chose qu'on peut faire, c'est finir un jeu et le distribuer en espérant qu'un de ceux qui le testeront en 15 secondes, pigera le travail qui se cache derrière.
...
C'est le truc chiant quand on fait des homebrew sur des consoles anciennes
...
Mais sinon, c'est génial de faire des homebrew !!!
J'en ferais jusqu'à la mort
:) !!!

[Jean-Jean]

(...) en espérant qu'un de ceux qui le testeront en 15 secondes, pigera le travail qui se cache derrière.(...)

Juste un poil méprisant. Juste un poil.

[r_songo]

Je partage ton point de vu, même si je ne fais plus de homebrew.

[65c02]

(...) en espérant qu'un de ceux qui le testeront en 15 secondes, pigera le travail qui se cache derrière.(...)

Juste un poil méprisant. Juste un poil.

Pourquoi te sens tu visé ?

Je t'assure que pas mal de gens qui testent les jeux le font comme ça.
J'en croise tout les jours.

Beaucoup s'en foutent, et regardent par curiosité.
Limite, une vidéo youtube les arrangerait.

Ce n'est pas méchant ni méprisant, c'est juste comme ça.

Et puis, pourquoi devraient ils s'intéresser plus que ça de toute façon ?
Beaucoup ne connaissent pas les contraintes technique des vieilles consoles et ne mesurent donc pas vraiment la complexité d'une réalisation.

Faut pas le prendre négativement...

[Jean-Jean]

Oh non, je ne me sens pas visé. je ne pas pas 15 secondes sur les jeux que j'essaye, aussi mauvais soient-ils.

Je trouvais juste que c'était un raccourci un peu facile. Je ne doute pas qu'il y a une masse de gens qui s'en branlent et qui sont exactement comme tu les décris, mais il y a aussi des gars qui apprécient énormément la scène HB et qui savent savourer les réalisations quand celles-ci en valent la peine.

Je trouvais juste la généralisation dommage.



EDIT: Je précise que perso, je suis fasciné par le travail de ceux qui développent aujourd'hui des jeux pour les vieilles bécanes. J'aimerais tellement le faire... Mais on peut pas tout faire non plus dans sa vie.

[65c02]

Ce n'est pas une vérité, c'est plus l'idée que je me fait...

[Docteur Nambu]

Yo.

T'inquiètes, y'a pas qu'en faisant du homebrew. Même au taff, ton patron fait la même chose... il en a rien a branler du boulot que t'as fait, des décisions que t'as prises, des problèmes gérés (du moment qu'ils sont résolus dans les faits et dans les délais)

Au final, tu te feras presque toujours juger sur ce qui marche pas, et rarement sur ce qui marche, car on trouve ça "normal", c'est ce qu'on attend de toi. N'attends pas d'applaudissements ou d'encouragement, car le retour n'est jamais garanti.


Si t'as passé 3 semaines pour faire une animation de perso réussie sur un vieux hardware, pleins de mecs trouveront ça "normal" et verront même pas le défi technique relevé.

Mais bon, c'est la vie, qu'est-ce que tu veux ? Du moment que toi ça t'as permis de trouver un intérêt dans ta matière, continues; tu peux stocker toutes tes observations dans un fichier joint en expliquant par quels stades tu es passé, il y aura malgré tout peut-être quelqu'un qui va te répondre et te dire "yo mec c'est cool j'apprécie ton dévouement, bravo pour ça et ça !"

Et pis si y'a personne, garde ça en souvenir.

A plus et continues. Au moins toi tu sais !

Docteur N.

[65c02]

En fait, le malentendu est dans ton "qui en valent la peine"
Un le but d'un dev homebrew (pour moi) c'est plus un exercice de maitrise que épater la galerie sur de vieille techno.
Du coup le gars qui veux consommer du jeux (avec indulgence) ne se posera aucune question sur l'aspect technique.
Seul le résultat comptera

Si il joue a stratogem deluxe sur vcs (par exemple)
Il se dira "chouette" ou "je préfère columns" mais pas "ouah pas mal ! il a mis 6 sprites de couleurs différentes sur une ligne"

C'est ni un bien, ni un mal, c'est comme ça.

[65c02]

Exactement ça docteur N
et oui, c'est la vie, c'est comme ça.
Je dis juste que je trouve ça chiant :)

[Jean-Jean]

En fait, le malentendu est dans ton "qui en valent la peine"
Un le but d'un dev homebrew (pour moi) c'est plus un exercice de maitrise que épater la galerie sur de vieille techno.
Du coup le gars qui veux consommer du jeux (avec indulgence) ne se posera aucune question sur l'aspect technique.
Seul le résultat comptera

Si il joue a stratogem deluxe sur vcs (par exemple)
Il se dira "chouette" ou "je préfère columns" mais pas "ouah pas mal ! il a mis 6 sprites de couleurs différentes sur une ligne"

C'est ni un bien, ni un mal, c'est comme ça.

Après y'a aussi le fait que le profane ne comoprend justement pas forcément ces défis techniques. Et comme dit Nambu, si tu joins à ton jeu un genre de carnet de développeur sympa dans lequel tu expliques les contraintes et comment tu les as contournées, ben au final même si ton jeu c'est un pixel qui se ballade à l'écran, les gens interessés apprécieront le taff.

Les autres, tu t'en branles.

"Haters gonna hate"

[oleglenorvegien]

tu as fait des homebrew sur quelles machines ?

[65c02]

C'est difficile à décrire parce que je reste souvent au niveau de la beta.
C'est plus histoire de faire pour apprendre.

J'ai fait un peu de gp32, un peu de gameboy, un peu de gba, un peu de nds, un peu de nes, un peu de lynx, un peu de master system

Mais je fais beaucoup plus sérieusement de la vcs 2600.
C'est mon terrain de jeu préféré.

[Jean-Jean]

Tu devrais nous montrer ce que tu fais...

[65c02]

Ok
Ça me donnera envie de les finaliser

[Jean-Jean]

Ben ouais. Et puis perso ça m'intéresse de voir ce que tu fais. Surtout sur des machine saussi diversifiées que celles que tu as cité.

[Invité]

Tu devrais nous montrer ce que tu fais...

C'est le seul moyen, et ça peut intéresser du monde.

[65c02]

ok ok
En ce moment je tente un portage sur vcs de bomb on pixel city.
J'avance pas mal (quoi que sur vcs c'est pas le démarrage le plus dur c'est plus de tout caser dans la rom)
Si ça vous tente je peux vous faire un post sur ce forum pour montrer l'avancement. Ça vous donnerait une sorte de making of en direct.

Mais bon, je ne suis pas david crane, n'attendez pas la lune :)

[Jean-Jean]

Ouiii !

[oleglenorvegien]

ok ok
En ce moment je tente un portage sur vcs de bomb on pixel city.
J'avance pas mal (quoi que sur vcs c'est pas le démarrage le plus dur c'est plus de tout caser dans la rom)
Si ça vous tente je peux vous faire un post sur ce forum pour montrer l'avancement. Ça vous donnerait une sorte de making of en direct.

[Invité]

Volontiers.

[pigachemike]

Je suis aussi très intéressé par ton travail. Ca m'éclate de nouveaux jeux sur de vieilles consoles. Ca permet de leur donner une seconde jeunesse.

[65c02]

Tant de gentillesse me touche

sérieux :)

[Jean-Jean]

Ben voila ^^

Tu vois, quand on secoue un peu la branche, y'a des machins qui tombent.

[65c02]

Bon, plutôt que de faire un autre post qui perdrait tout lien avec celui ci, je mets à la suite comme ça on a le making of du making of :)

Voila la gueule du jeu aujourd'hui.



Pour que vous puissiez comprendre l'évolution du jeu et les contraintes que j'ai: je dois vous expliquer deux trois trucs sur la vcs.

1- j'ai 128 octets de ram
2- j'ai 4Ko de rom
3- les registres graphiques sont hyper rudimentaires et ne permettent que de définir une seule ligne.

Pour le 1 et le 2 ça parle de lui même.
Pour le 3 je développe :
La vcs posséde 6 objets graphiques que l'on peut régler à travers différents registres.
On les appellent :
-player 0 (8x1 pixels)
-player 1 (8x1 pixels)
-playfield (20x& pixels)
-ball (1x1 pixel)
-missile player 0 (1x1 pixels)
-missile player 1 (1x1 pixels)

* le playfield c'est un peu l'objet décor de fond. C'est par exemple, le terrain dans combat. On définit ses 20 pixels à travers 3 registres. L'image résultat remplit la moitié gauche de l'écran et suivant le réglage d'un autre registre, elle est dupliqué à droite ou mise en miroir.

* les players peuvent avoir des modes d'affichage dupliqués ou grossis. On peut avoir 2 ou 3 player 0 qui se suivent ou avoir des players plus gros.

* les missiles peuvent être grossis eux aussi.

Si on veut afficher un sprite d'une résolution supérieur à 1 ligne, on doit changer les registres avant l'affichage sur la ligne suivante.
En gros le code s’exécute en même temps que le canon à électron parcours l'écran et on doit jongler avec les registres pour changer les valeurs avant que l'objet soit affiché.
Notez que pendant un cycle CPU du 6507, 3 pixels sont affiché sur l'écran. Et, sachant que la plus rapide des instructions 6502 fait 2 cycles, une ligne assembleur coutera 6 pixels minimum.
Notez enfin que le HBlank laisse 20 cycles CPU (période qu'il faut au canon pour revenir du bord droit au bord gauche) et qu'une ligne fait 76 cycles au total (en NTSC)

On doit donc choisir quel registre graphique va être modifié car il n'est pas possible de tous les changer à sa guise.

Maintenant parlons du positionnement des objets graphiques en X.
Ce truc est souvent le coup de grâce pour ceux qui s'essaye à la vcs.
Le objets graphique n'ont pas de position en x paramétrable.

Le TIA de la vcs (la carte graphique si vous préféré) marche un peu comme si elle avait des chrono en tête. Elle "attend" un certain temps après chaque début de ligne avant d'autoriser l'affichage d'un objet.
Coté programmation, il n'existe pas de registre pour écrire ce temps. Par contre il existe des strobes. Ce sont des registre qui marche un peu comme le bouton d'un chrono.
Lorsqu'on écrit dans un registre strobe de position d'un objet graphique, le TIA note le moment ou on a écrit dedans et à la ligne suivante, il affichera l'objet au même moment.
Mais je vous ai dit tout à l'heure qu'un cycle faisait 3 pixels. Du coup, juste avec les strobe il serait normalement impossible de positionner finement les objets.
Du coup, on a droit à des registres de mouvement qui déplacent de façon relative les objets de +7 à -8 pixels. C'est comme un réglage fin.

Finalement, pour positionner un objet sur une coordonnée absolue il faut une ligne complétement dédié à ça.

Bon, j'arrête là mon pavé.
C'est le minimum à connaitre pour bien comprendre la suite.

Je ferais un autre post plus tard pour vous expliquer comment j'ai construit la version actuelle, les problèmes que je rencontre et l'évolution de tout ça.

[Invité]

Si l'opération va au bout, je propose d'archiver ce "journal de bord" de 65c02 et de le publier sur Gamopat (le blog).

Ça, c'est de l'immersion en terrain barbu.

[65c02]

Avant de décrire l'existant je vais faire un résumé des épisodes précédents.
j'ai commencé par la ville.
Comme je voulais que la ville occupe tout l'écran, j'ai choisi d'utiliser le playfield.
Mais là, premier problème : le playfield ne définit que la moitié de l'écran.
L'autre moitié est une copie ou un miroir
Si ABC est mon playfield sur l'écran on verra soit ABCABC soit ABCCBA.
Pour régler ce problème il existe une technique qui s'appelle le playfield asymetrique.
L'idée est de changer les registres du playfield après que le raster l'ai utilisé pour afficher sa partie.
J'ai donc fait un petite routine qui mets à jour les registres et attend que le raster ai suffisamment avancé pour pouvoir redéfinir le graph avec les datas de la partie droite.

J'ai enfin intégré un changement de couleur du playfield pour voir ce qu'il me resterai en cycle cpu par ligne.

Pour économiser de la rom j'ai fait que les datas du playfield ne change que tous les n ligne (J'appellerai ces tranches des étage désormais)

Avec n = 4, le résultat fut :


Ensuite j'ai commencé à chercher à intégrer les sprites.
Il faut pouvoir redéfinir les deux sprites par ligne si je veux faire l'avion plus des tank, des dca ou des croix d'hopitals.
Mais là : problème avec mon code de playfield asynchrone j'avais déjà bouffé une grande partie de mon temps de HBlank. J'avais bien des cycles en rab entre la définition du playfield à gauche et celle a droite mais le raster est au milieu et tout changement à ce moment ferait potentiellement un glitch.
Je n'avais pas le temps de définir les deux sprites mais j'avais le temps pour un.
J'ai donc dupliquer ma fonction pour qu'elle définisse une ligne le player 0 et la ligne suivante le player1.
A partir de là je pouvais afficher deux sprites sur une ligne mais je devais encore pouvoir les positionner. Hors à cause du système de strobe j'ai besoin d'une ligne complète pour faire ça précisément.
C'est la raison pour laquelle vous pouvez voir entre chaque étage un espace de séparation. Cet espace me sert à positionner les sprites du décor. Le sprite avion étant lui positionné sur une des lignes du début de vbl.

J'ai aussi commencé à structurer les datas pour en faire des vrais levels et j'ai un peu optimiser la rom. Du coup les étages sont devenu plus grands.

J'ai enfin ajouté du code pour pouvoir lâcher une bombe.

Le résultat:


Comme je manque de cycle pour avancer j'ai ensuite changer ma routine de playfield asymetrique. Avant j'était en mode ABCABC du coup j'avais le temps de B+C pour changer A. Mais je devais écrire dans les 3 registres 2 fois pour faire une ligne.
Hors un des registres (le A) n'a que 4 pixel de définition. Je me suis dit que ce serait mieux de ne pas écrire dedans et de le laisser à 0 tout le temps
mais pour que ça marche, je dois être en mode ABCCBA et là c'est plus chaud
En fait on ne peut pas changer assez rapidement C mais si on va le change pile au milieu de la raster line, la partie droite du dessin de C sera affichée dans la partie gauche de son miroir mais le reste sera mis à jour. Et comme mes immeubles doivent être séparé par un espace, c'est le meilleur endroit pour le coller.

Donc nouvelle contrainte de level design un espace au centre :)

Je ne sais pas si je garderais ce schéma jusqu'au bout. Je ne suis même pas certain que ça marche sur une vrai console. Pour l'instant ça tourne.

Ça commence à prendre forme mais c'est encore loin d'être fini. Je vais maintenant me concentrer sur la destruction des immeubles

[Invité]

[Jean-Jean]

Je comprends pas tout, mais c'est beau.

[Invité]

Pourrais-tu renommer ton topic, du coup, en un truc genre "Bom On Pixel City 2600: Work In Progress" ?

[pigachemike]

Je comprends pas tout non plus, mais ça a l'air de bien avancer.