Re: [TERMINE] Bomb On Pixel City / Atari 2600

par pigachemike Mer 8 Fév 2012 - 14:39

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

par **65c02** Mer 8 Fév 2012 - 15:03

Désolé si ce n'est pas trop clair, j'ai un peu de mal avec le français : trop de registres :)

par Invité Mer 8 Fév 2012 - 15:08

Non, c'est juste un soucis de vocabulaire, très spécifique, forcément, vu que tu sais de quoi tu parles.

Mais t'en fais pas, on fera un lexique après, si besoin.
Continue!

par Jean-Jean Mer 8 Fév 2012 - 18:37

Oui c'est ça voila. Tes explications sont très claires, mais ça reste compliqué pour un profane. Un peu comme les équations à 3 inconnues et plus...

par **65c02** Jeu 9 Fév 2012 - 8:03

d’où mon post de départ
Ce n'était pas dit méchamment: c'est juste comme ça :)

par **65c02** Ven 10 Fév 2012 - 8:33

Ok, donc j'en suis là :
Je sais afficher 2 sprites par étage mais j'ai la contrainte de devoir aligner les sprites avec les étages. Une sorte de mode tile.
C'est parce que, pour le moment, la lecture des datas des sprites se sert du compteur de ligne de l'étage. Ça me permet une sacrée économie de cycles.
Par contre quand la bombe tombe, ce n'est pas smooth.
Quand j'aurai posé tout le jeu j’essaierai de voir si je ne peut pas rendre ça plus smooth. Par exemple, en distribuant l'affichage sur deux étages et en décalant le départ des sprites (mais j'aurai une déformation sur l'espace inter-étage) .
Ou en utilisant un missile plutôt qu'un sprite (j'y gagnerai 5 cycle à ne pas lire les datas graphiques).
Ou en faisant une "animation" dans les tiles.
Je verrai plus tard suivant ce qu'il me reste de cycles.

Comme vous pouvez le voir j'ai mis un changement de couleurs aux sprites du décor pour pouvoir faire les croix d’hôpital. Ce concept de tour à préserver me semble suffisament important pour être conservé.

Notez d'ailleurs que j'ai passé la moitié du temps pour caser ces sprites dont la seule utilité est de pouvoir afficher les croix qui vont indiquer où sont les hôpitaux.
Au passage je pourrais ajouter d'autre trucs de gameplay si j'ai de la marge ou juste du décor.

Pour finir, je vais vous expliquer d'où viennent les petites lignes noires à gauche de l'écran.

Précédemment je vous ai expliqué comment on positionnait un objet en X.
Je vous ai dit qu'il existait des registres permettant de bouger la position en X des objets en relatif.
Il faut savoir que l'écriture dans ces registres de déplacement n'applique pas immédiatement le déplacement, elle ne fait que stocker sa valeur.
Pour appliquer le déplacement il faut exécuter une écriture sur un registre appelé HMOVE. Ce registre déclenche tous les déplacements en même temps.

Et de là existe une autre contrainte:
Après un appel à HMOVE il faut un certain temps au TIA pour appliquer ces déplacements.
Il est donc fortement recommandé de ne pas redéfinir les registres de déplacement pendant les 20 cycles suivants. Sinon on risque des glitch si le TIA bouge un objet pendant son affichage, il est aussi demandé de ne faire les HMOVE qu'en début de ligne. Et, pour une raison qui m'échappe, un HMOVE pile en début de ligne fait un trou noir.

Maintenant vous saurez quand le code fait des HMOVE pour bouger ses objets en relatif, rien qu'en regardant l'écran. :)

Enfin, si vous voulez briller en soirée, sachez que le jeu Cosmic Ark "utilise"
un glitch de HMOVE pour afficher les étoiles du fond. Le glitch déplace
l'objet et du coup le ré-affiche plusieurs fois, mais c'est une autre histoire. :)

[TERMINE] Bomb On Pixel City / Atari 2600 - Page 2 Bombci11

[TERMINE] Bomb On Pixel City / Atari 2600 - Page 2 Bombci11

par **65c02** Mar 14 Fév 2012 - 8:32

..- Dans l'espace on ne vous entendra pas coder -..

Suite de mon making of :

J'ai fait une fonction "dessinant" les tours à partir d'une table de hauteur.
Ça va me servir lors des explosions.
Ça m'a permis aussi d'économiser en rom. la définition du playfield est passée de 40 octets à 8.
J'ai cleané le code d'init du jeu et j'ai définit vite fait 8 levels.
Vu la taille actuelle d'un level je peux surement en mettre plus.
Je verrai ça plus tard.
Maintenant que j'ai intégré la fonction de dessin des tours j'ai une nouvelle contrainte : 8 tours max.
Ceci est du à la structure des registres playfield.
Petite explication rapide:
Le playfield est composé de 3 registres PF0, PF1 et PF2
les bits de ces registres décrivent le dessin du playfield
Le truc chiant c'est que les bit ne sont pas lu dans le même sens suivant les registres
Exemple
Pour PF0 qui décrit la partie à gauche, c'est le quartet haut qui est prit à l'envers (le bit 7 décrit le pixel le plus à droite).
Pour pf1 c'est dans l'ordre de lecture et pour pf2 c'est encore à l'envers.
Et comme je suis en asymetrique, c'est linverse pour le coté droit de l'écran.
Bref, c'est compliqué.
Donc, pour avoir un système efficace, je travail par quartet avec une table.
Pour chaque tour à afficher, je sais grace à la table quel quartet doit être prit.
Du coup, pas de calcul inutile, ni de perte de puissance.
Une tour est donc large d'un quartet et comme je n'utilise plus que pf1 et pf2 cela me fait 2 * 2 * 2 = 8 tours

Ensuite, comme j'avais 18 cycles inutilisés pour la synchro du playfield asymetrique des lignes impaires, j'ai fait un bout de code qui affiche un missile sur la ligne que je veut.

Je voulais tester si ce ne serait pas mieux d'avoir une bombe missile en smooth plutôt qu'une bombe en sprite avec un saut par étage.

L'animation en smooth est beaucoup plus jolie mais ma bombe est vraiment moche (un pixel). Du coup, pour l'instant, je garde le bout de code du missile pour une éventuelle DCA et je reste sur mon système de sprite pour la bombe.
J'ai encore quelques idées à tester pour améliorer le mouvement de la bombe en sprite :)

Là, je suis en plein dans ce qu'est un développement VCS.
Je suis loin des avancés rapides que peuvent constituer la première compilation ou le premier affichage.
Je creuse pour trouver le juste équilibre, la bonne synchro.
Chaque pas en avant demande beaucoup de temps et d'essais.
J'ai d'ailleurs installé un serveur svn en local pour garder un historique des sources parce qu'on a vite fait de moisir un source assembleur avec plein de tests.
Je n'imagine pas la galère des développeurs de l'époque qui n'avaient pas autant d'outils à leur disposition.

A suivre

par Invité Mar 14 Fév 2012 - 8:37

Classe, merci.

par **drfloyd** Mar 14 Fév 2012 - 19:13

On va la faire notre version cartouche !!! On va la faire !!!!!!!! cheers

(Je t'ai répondu à ton email sinon)

par **65c02** Mar 14 Fév 2012 - 20:46

ahahah cette pression de fou.
Ce serait un vrai bonheur en effet :)

par SxT Mar 14 Fév 2012 - 23:42

Putain je pige rien en technique mais c'est passionnant à lire !

par **drfloyd** Mar 14 Fév 2012 - 23:53

Sinon tu comptes mettre un ecran titre ou on sera direct sur le jeu ?

par **65c02** Mer 15 Fév 2012 - 7:55

Je vise un super écran titre.
J'ai plein d'idées sur ce point.
Mais je me réserve ça pour la fin.
J'ai besoin de savoir combien d'espace rom il me reste pour bien viser et je me dit que ça me détendra de finir sur ça.

par **65c02** Mer 22 Fév 2012 - 14:14

Petite semaine sur bomb city, perte d'énergie et de temps (mais comment font les autres?).
Bref... :)
J'ai enfin trouvé une technique sympa pour animer la bombe.
J'ai ajouté un espace vide avant et après le sprite de la bombe et au lieu d'afficher celle ci sur un étage unique, je l'affiche sur deux étage successif en "scrollant" les tiles suivant la position en Y.
Comme je suis obligé de couper l'affichage entre chaque étage j'ai toujours la coupure mais l'animation est smooth comme j'aime.
[TERMINE] Bomb On Pixel City / Atari 2600 - Page 2 Bombci14

[TERMINE] Bomb On Pixel City / Atari 2600 - Page 2 Bombci14

J'ai fait la routine de collision de la bombe sur les tours et pour le moment, je détruit entièrement une tour avec un impact.
Bizarrement, j'ai un bug qui rend deux tours indestructibles.
C'est surement une histoire d'arrondi à la con dans le calcul de conversion x -> index de tour.

A suivre...

par Invité Mer 22 Fév 2012 - 14:32

Thanks, et courage!

par jouk_tarakanovitch Mer 22 Fév 2012 - 14:48

Passionnant tout ça :)

par **65c02** Ven 24 Fév 2012 - 16:18

Heureusement que je vous ai :)

par **philip** Ven 24 Fév 2012 - 23:00

65c02 a écrit:Heureusement que je vous ai :)

houa, la vcs n'a plus de secret pour toi maintenant, plus d'excuse, Wink

c'est déjà beau, alors tu dois aller jusqu'au bout. :)

par **drfloyd** Sam 25 Fév 2012 - 0:20

On y croit !

Il n'y aura pas de possibilité de représenter les immeubles autrement et sans coupure ?

par **65c02** Sam 25 Fév 2012 - 11:28

Pour la représentation des immeubles ce n'est pas simple.
La résolution du playfield ne me donne que 4 "pixels" par immeuble. Je ne peut espérer faire mieux qu'en ajoutant des trous dedans. Si j'arrive à trouver des cycles pour le faire, ça ferais des fenêtres dans ce genre:
====
=_==
==_=
====

Quant aux coupures, elles sont là pour repositionner les sprites de décor.
il me faut une ligne complète pour repositionner un sprite à une coordonnée variable et comme le playfield asymétrique demande lui aussi une ligne quasi complète de code: c'est soit l'un soit l'autre.
Mais si je "vire" les sprites du décor je ne pourrait plus indiquer quels sont les immeuble hopitaux (chose qui me semble importante pour le game play)

D'un autre coté j'ai un autre soucis en approche.
Je ne repositionne pas à chaque étage le sprite joueur qui me sert pour l'avion et la bombe (sinon j'aurai une ligne de plus dans la coupure inter étage)
Du coup, la bombe tombe en restant sous l'avion. D'un point de vue jeu ce n'est pas trop mal et je pense qu'en ajoutant une accélération de gravité ça peut donner un gameplay intéressant. Par contre si j'ai des immeuble hôpitaux c'est en contradiction car un immeuble hôpital interdit de détruire la zone en bas à gauche.

Du coup je me demande si les hôpitaux vont survivre au portage.

Les seules certitudes que j'ai c'est :
- il est impossible de dessiner un playfield asymétrique et définir la position en X d'un sprite sur une même ligne.
- il est impossible de définir la position deux sprites sur une même ligne si ceux si n'ont pas une position relative connue d'avance.

Tiens, petit sondage; préférez vous :
1 - une ville sans coupures et sans hôpitaux
2 - le rendu avec coupures et les hôpitaux
?

par **drfloyd** Sam 25 Fév 2012 - 11:36

si ca peut t'inspirer :

RAMPAGE sur ATARI 2600

[TERMINE] Bomb On Pixel City / Atari 2600 - Page 2 Rampage-6

par Invité Sam 25 Fév 2012 - 11:37

Si vous parvenez à le sortir sur cartouche, et tout, je vous garantis que je l'achète.
Day one.

drfloyd a écrit:RAMPAGE sur ATARI 2600

J'aimais beaucoup.

par **drfloyd** Sam 25 Fév 2012 - 11:40

Ouais_supère a écrit:Si vous parvenez à le sortir sur cartouche, et tout, je vous garantis que je l'achète.
Day one.

drfloyd a écrit:RAMPAGE sur ATARI 2600

J'aimais beaucoup.

1 vente assurée ! [TERMINE] Bomb On Pixel City / Atari 2600 - Page 2 97220

par **65c02** Sam 25 Fév 2012 - 11:51

Oui pourquoi pas mais ça ne fait plus que 4 tours max.
Et il n'y a que deux colonnes de sprites dans ce jeu.
Une colonne pour le perso dans l'immeuble et une pour le monstre du joueur.
Surement définient en haut de l'écran quand le ciel devient noir (a cause du hmove qui fait un artefact noir)

Du coup ils n'ont pas a redéfinir une position en x pendant le dessin des tours.

Donc je peut compliquer mon algo de dessin de tour pour ne pas être sur des quartet et faire des fenêtres à trous mais ça ne règle pas mon soucis lié aux hôpitaux.

par **65c02** Sam 25 Fév 2012 - 11:58

ou alors (t'as raison ça m'inspire)
je mets les croix d’hôpitaux dans le graph des tours mais ça impose de faire des tours d'au moins 5 pixels de large (en résolution playfield)
=====
==_==
=___=
==_==
=====
Dans ce cas je n'ai plus besoin du deuxième sprite.
mais ma bombe suit toujours l'avion

par **65c02** Sam 25 Fév 2012 - 12:00

remarque pour la bombe je peut faire bouger la bombe en relatif entre chaque étage pour compenser et la freiner... ça peut marcher, ça dépend de la hauteur des étages. A tester

Je sent que j'ai pas fini de tout refaire :)

par **65c02** Sam 25 Fév 2012 - 12:02

Ou, encore plus simple, un sprite pour l'avion, un pour la bombe et hop c'est réglé

par **philip** Dim 26 Fév 2012 - 12:00

2. le rendu avec coupures et les hôpitaux
Et après avoir vu le screenshot de rampage, c'est sans l'ombre d'un doute qu'il faut conserver coupures et hôpitaux. Je pense qu'il faut avoir un esprit "concepteur de game&watch" aussi bien pour le code que pour le désign.

par **philip** Dim 26 Fév 2012 - 12:20

La petite séparation entre les blocs donne un style artistique, ou schémamatique, selon sa sensibilité. Ça fait moins maternelle que les immeubles grossiers de rampage. Faut rappeler que tu fais le jeu sur vcs, avec des contraintes inouis. Cela impose une recherche technique très ardu, mais aussi artistique. D'où l'esprit game&watch (avec certes des graphismes bien moins fins mais colorés). :)

par **65c02** Dim 26 Fév 2012 - 12:40

J'ai entièrement refait le noyaux de rendu pour mettre la priorité sur le rendu de la ville.
Maintenant j'ai un système de tileset sur un playfield asymétrique complet avec deux colonnes de sprites (un sprite différent par étage mais tous les sprites sur la même colonne).

Ça me permet de faire des dessins sophistiqués dans le playfield (parfait pour les hôpitaux)
J'ai aussi fait une petite application flash qui convertit un png en source asm pour vous faire de jolis immeubles

Par contre j'ai du pas mal jongler pour que ça passe.
J'ai un double tableau de pointeurs pour pointer sur les info de tile.
Normalement il faut un pointeur par tile soit 6 pointeurs pour une ligne de playfield.
Mais cela suppose aussi que les 6 pointeurs sont redéfinis entre chaque ligne de tile set.
Hors, à la fin d'une ligne de playfield, je n'ai le temps de redéfinir qu'un seul pointeur.
Alors j'ai dérouler mes boucles et fait deux tableaux de pointeurs; un tableau pour les lignes de tileset pair et un pour les lignes de tileset impaire.
Ensuite, sur les 6 premières lignes écran de mon tileset pair, je prépare un par un les pointeurs de la prochaine ligne de tileset impaire et ainsi de suite
Note: je me doute que c'est obscure abscons etc, mais ça fait partie du jeu du "making of" :)

en décomposé ça donne:
- dessin d'une ligne de tiles sur la base des ptrTilePaires - ligne 1 et redéfinition du ptrTileImpaire 1
- dessin d'une ligne de tiles sur la base des ptrTilePaires - ligne 2 et redéfinition de ptrTileImpaire 2
- dessin d'une ligne de tiles sur la base des ptrTilePaires - ligne 3 et redéfinition de ptrTileImpaire 3
- dessin d'une ligne de tiles sur la base des ptrTilePaires - ligne 4 et redéfinition de ptrTileImpaire 4
- dessin d'une ligne de tiles sur la base des ptrTilePaires - ligne 5 et redéfinition de ptrTileImpaire 5
- dessin d'une ligne de tiles sur la base des ptrTilePaires -ligne 6 et redéfinition de ptrTileImpaire 6
- dessin d'une ligne de tiles sur la base des ptrTilePaires pour les lignes suivantes

et pour le ligne de tile suivante c'est l'inverse

- dessin d'une ligne de tiles sur la base des ptrTileImpaires -ligne 1 et redéfinition de ptrTilePaire 1
- dessin d'une ligne de tiles sur la base des ptrTileImpaires -ligne 2 et redéfinition de ptrTilePaire 2
- dessin d'une ligne de tiles sur la base des ptrTileImpaires -ligne 3 et redéfinition de ptrTilePaire 3
- dessin d'une ligne de tiles sur la base des ptrTileImpaires -ligne 4 et redéfinition de ptrTilePaire 4
- dessin d'une ligne de tiles sur la base des ptrTileImpaires -ligne 5 et redéfinition de ptrTilePaire 5
- dessin d'une ligne de tiles sur la base des ptrTileImpaires -ligne 6 et redéfinition de ptrTilePaire 6
- dessin d'une ligne de tiles sur la base des ptrTileImpaires pour les lignes suivantes

Du coup mes boucles sont déroulé et ça bouffe un max en rom mais ça marche et j'ai un plan de tileset sans aucunes rupture avec deux colonnes de sprites en plus.

En ram ça consomme aussi car deux liste de pointeur ça fait 24 octets juste pour ça.
Mais bon, ça tient, c'est le principal

Je finalise tout ça et je vous fait une jolie image bientôt :)

par **philip** Dim 26 Fév 2012 - 13:16

Fait une sauvegarde de l'ancienne version, au chaud sur une clé usb... ton code se complique vachement et ça bouffe plus de mémoire, ça risque de te jouer des tours cette histoire là.

Alors que c'est juste une histoire d'esthétisme des immeubles. Quand tu décidera de faire plusieurs niveaux ou modes de difficultés, tu trouvera cool de faire une version nuit. Les blocs noirs deviendront blancs ou jaunes pour représenter une ville plongée dans la nuit...

Ceci dit j'ai hâte de voir ce que tu as obtenu. :)