Re: Mes questions sur mon projet Coleco

[upsilandre]

Je me suis bien amusé a coder sur coleco tout ces derniers jours. Je me suis fais un petit exercice sympa, je vous montrerais ca demain apres le boulot je pense.
Par contre ca a renforcer mon affection pour le 6502. J'aime pas vraiment programmer sur le Z80, j'ai ete un peu decu sur certain point par rapport a ce que j'imaginais. J'essayerais d'en parler plus longuement pour donner mes premières impression (y a pas deja un topic Z80?) ou peut etre en video, je sais pas encore.

[upsilandre]

Voila mon premier (et probablement dernier) programme assembleur sur Colecovision

https://youtu.be/uD5omwFFnog (a regardez en HD pour avoir le 60fps)


Alors vous emballez pas, c'est juste des expériences d'affichage, y a aucune mecanique de jeu derrière. On controle le personnage au pad mais on peut juste marcher vers la gauche ou la droite. Je voulais surtout m'amuser a faire du smooth scrolling au pixel a 60fps (mettez la video en HD pour avoir le 60fps) sur cette machine ou y a aucun scrolling.
Je pré-shift simplement tout le tileset au démarrage du jeu. Le gros atout de la Colecovision a l'epoque c'etait d'avoir beaucoup de VRAM mais en général totalement gaché par le mode 2. Et combiner a la flexibilité de l'adressage de toutes les tables on peut pas mal s'amuser avec cette VRAM je pense. Donc je voulais faire un truc qui profite au max de ca (evidement le pré-shift c'est une autre facon de gaché la VRAM) d'autant que comme par hasard on peut justement adresser 8 bank differente pour le tileset et c'est exactement ce qu'il fallait pour faire un smooth scroll au pixel.
Au final une fois tout bien préparé au démarrage du jeu l’intégration du smooth scroll est extrement simple. Je prend les 3 bit de poid faible des coordonnée X de ma camera et je les envoie dans le registre d'adresse de la table du tileset et c'est tout. A ce moment la ca prend aucune ressource CPU, c'est comme si l'offset au pixel etait hardware (facon C64 ou Intellivision).
Reste quand meme a faire le scrolling lui meme qui est software et qui demande a mettre a jour toute la tilemap. Je le fais en double buffering etalé sur 3 frames et au final ca prend peu de ressource aussi.
En tout pour toute la gestion du scrolling de A a Z ca me prend a peine 20 scanlines (soit 7.5% de ressource CPU) et avec du triple buffering (ou un scorlling bloqué dans une seul direction genre Contra)  ca prendrait encore 2 fois moins. Et le Vblank est tellement long (ca fait bisarre quand tu viens de la NES) que ca rentre largement pendant le Vblank . Par contre ma tilemap n'est pas compressé donc ca simplifie beaucoup les choses evidement (et puis j'ai fait un petit script python pour transformer les 4 tilemap 256x192 en une seule tilemap 1024x192 pour que ce soit encore plus optimale)
Evidement c'est rigolo ce smooth scroll parfaitement fluide sur Coleco mais c'est beaucoup de contrainte pour la construction du background en terme de couleur et de variété de tuile (faut penser les tuiles en binome) mais ca reste faisable.
Par contre la partie sprite est completement bullshit, alors oui ca tourne sur Coleco mais on pourrait pas faire un vrai jeu avec des sprites de cette qualité, la je me suis fait plaisir sur la demo parce qu'il y a qu'un seul sprite et parce que je voulais tester aussi l'affichage de sprite.
D'ailleurs pour ceux qui n'ont pas reconnu le level est piqué en grande partie de Megaman 2 et le sprite de Shatterhand.

[TotOOntHeMooN]

Héhé... Oui, c'est ce qu'on peut appeler une démo technique. 
Le principal étant que tu te sois bien amusé à faire cela, surtout que c'est très réussi.

On pourrait quand même faire des choses super avec un écran incliné à 90° ! 

[vincent2105]

Très intéressant !
Et bravo ! total respect 

[Invité]

J'aime bcp, par contre forcement tu vas être limité au scroll H, parce que faire un scroll multidirectionnel comme ça, ça va être chaud en ressources .
Après pk pas faire quelques sprites soft pour garder ton sprites multicouleurs,finalement ça peut faire un jeu, même en ayant certaines limites (on est sur coleco en même temps)

[Invité]

Je suis d'accord avec TOUKO !

Pourquoi ne pas persévérer et réaliser un jeu, quitte à y passer quelques minutes par jour, comme le fait Vincent, et expliquer son cheminement étape par étape.
Ca permettrait de rendre "accessible" ce qui peut paraitre complétement obscur quand on n'a pas l'habitude de ce langage très bas niveau ( je ne parle que du langage bien sûr ! )

Parce que des projets Homebrew terminés et réalisés en "Full ASM", j'en vois pas des masses en fait.

[Invité]

Parce que des projets Homebrew terminés et réalisés en "Full ASM", j'en vois pas des masses en fait.

Pour ma part, ça vient plus de la limitation en place dispo, que du langage .
Si tu as un dev kit correct, même l'ASM ne prend pas plus de temps à coder .

Alors langage C + manque de ROM, ça fait pas bon ménage en général 

PS: essayes d'imaginer ton jeu avec juste 512 ko de rom par exemple 

[Tryphon]

Sik a fait plusieurs trucs très sympa sur MD en full ASM. Chilly-Willy peut-être (pas sûr que ça soit du full ASM)

[TotOOntHeMooN]

Après pk pas faire quelques sprites soft pour garder ton sprites multicouleurs,finalement ça peut faire un jeu, même en ayant certaines limites

Ce n'est même pas "quelques" sprites softs qui faudriat, mais tout tirs compris. Du coup, tu oublies le background.
Mais c'est certain qu'avec beaucoup de ROM il est possible de faire un truc vraiment bien.

[Invité]

Pas forcement, regarde sur C64 et le jeu enforcer, tout les tirs (et il y en a bcp) sont en tile en fond noir, et ça gêne pas .

[TotOOntHeMooN]

Pas forcement, regarde sur C64 et le jeu enforcer, tout les tirs (et il y en a bcp) sont en tile en fond noir, et ça gêne pas .

Les tirs oui ça passe, mais pas les ennemies.

[upsilandre]

N’espérez rien, je produirais sans doute jamais de jeu pour plein de raison, c'est pas vraiment ce qui m'intéresse   . Si vraiment je voulais poser et expérimenter des idées de gamedesign (ce qui est aussi tres intéressant) je le ferais alors surement sur PC avec des outils tres moderne et evolué pour etre focus sur ca.

La j'ai fais ca sur coleco (et ailleurs) juste pour mieux comprendre son identité et le TMS9918 et Z80. Ca m'a deja suffit pour découvrir et comprendre plein de truc sur le Z80 (et me rendre compte que j'aime pas du tout, j'essayerais de détailler), c'etait vraiment chouette rien que pour ca (ce qui m'ouvre aussi la porte pour un peu de hack de jeu Master System d'autant que j'ai du aussi touché un peu au debugger de Mekka). et meme le TMS9918 que je pensais bien connaitre j'ai découvert des truc, notamment un truc sur la gestion des sprites que je trouve assez cool.
Y a quasiment pas d'attribut pour les sprites (en dehors des attribut incontournable), c'est tres pauvres comme de la Master System (et tres loin de l'intellivision par exemple) mais par contre ils ont fait tout ce qu'il faut pour que les sprites puissent sortir et entrer proprement dans l'ecran sans aucun glitch quelque soit le bord. Y a une marge de coordonnée negative au dessus de l'ecran (-31 pixels) pour que ca glitch pas en haut (contrairement a la NES par exemple) et pour la gauche ils ont prevu un flag pour chaque sprite (le seul extra dans les attributs) qui permet en quelque sorte d'inverser le point de controle du sprite (a droite au lieu d'a gauche), de le décaler de 32 pixels, du coup meme sur la gauche tu peux faire entrer et sortir proprement un sprite (contrairement a la NES encore une fois) et meme dans leur format upscaler (32x32).
Couplé au format 16x16 (quasi incontournable ) ca donne une gestion des sprite assez agréable et avec au final a peu pret les meme capacité et performance d'affichage que sur les NES et SMS sauf que c'est du monochrome (ce qui est vite un probleme quand meme).
D'ailleurs c'est pour ca que ma demo est bourré de dizaine de sprite qui sont épingle sur le décors (tous les truc qui clignotent et meme les bloc gris) et qui entre et sorte de l'ecran proprement, il semble parfaitement intégré au décors. Ca faisait partie des truc que je voulais tester.

[upsilandre]

J'aime bcp, par contre forcement tu vas être limité au scroll H, parce que faire un scroll multidirectionnel comme ça, ça va être chaud en ressources .

Quand tu vois tous les classique NES qui se passe de scroll multi (meme un Megaman s'en passe) je pense pas que ce soit la priorité sur Coleco
De toute facon un smooth scroll multidirectionnel en software c'est pas vraiment possible avec du pré-shift a priori. faudrait faire le shift en temps réel (comme le fait Rare sur Battletoad NES pour le second plan d'un level).
Cela dit y a surement des truc amusant de ce type a faire sur Coleco car elle a quand meme un cpu tres puissant pour l'epoque (c'est quand meme le meme que la Master System) + un Vblank tres long et en gros la meme bande passante qu'une Master System mais des tuiles plutot 1bpp donc une capacité de transferts de tuile 4x superieur a la SMS et 2x pour la tilemap qui est plus légère aussi. Et aAvec beaucoup de VRAM assez flexible ca peut donner pas mal de possibilité de trick temps réel si on se limite a un visuel simple (en gros si on evite le mode 2 qui fou la merde).

[Stef]

Vraiment pas mal du tout ta petite démo
On a vraiment pas l'impression d'être sur un coleco avec ce scrolling fluide et le sprite super coloré, on pense plutot à de la NES, et même pour de la NES ça serait assez joli
Je suis sur que tu ferais un excellent codeur et pourrait nous pondre des perles, dommage que ça ne t'interesse pas plus que ça
Tu dis ne pas aimer le Z80, je serais curieux d'en connaitre les raisons.
Je n'aime pas ce CPU non plus (qui équipe également la MD)... je code un peu dessus (toujours en assembleur, pas vraiment le choix) et je trouve ce CPU vraiment mal fichu, il est difficile de tirer partie de ses capacités pourtant c'est un CPU 8 bits assez avancé... je me sens toujours frustré quand j'essai de gagner des cycles, tu te dis que les instructions sont mal fichues, le CPU n'est pas efficace pour moi (par efficacité j'entends ce que tu peux traiter comme donnée pour une mémoire donnée.. ici la mémoire tourne à 1/3 de la fréquence du CPU je crois).
Je ne sais pas si tu connais la variante du Z80 utilisée dans la gameboy, mais je la trouve déjà bien plus "fonctionnelle", ils ont viré tout ce qui était inutile (et il y en a des choses inutiles ^^) et ajouté 2/3 instructions qu'il manquait cruellement, le CPU en devient réellement meilleur (la mémoire passe à 1/4 de la fréquence je crois).. et ça permettait à BigN de s'affranchir d'un copyright ou je ne sais quoi à payer

Le 6502, je ne peux pas dire que je l'aime   mais au moins il a sa logique : il est hyper simpliste et c'était ce qu'on lui demandait (le plus économique possible). Tu as un seul accumulateur et tu dois tout faire avec, c'est relou mais tu piges vite les contraintes et tu ne peux pas avoir un CPU à la fois économique et efficace (voir ma définition de efficace au dessus).

Bon après quand tu es habitué au 68000 (qui n'est pas parfait non plus, j'y aurai bien ajouté 3 ou 4 instructions aussi ^^), revenir à un Z80 ou un 6502 ça fait quand même très mal, tu te sens très à l'étroit, t'as l'impression de gacher plein de cycle partout :p

[Invité]

j'essayerais de détailler

Perso ça m'intéresse de savoir ce que tu n'aimes pas dans le Z80 .
Le R800 qui est 100% compatible Z80, est très efficace niveau cycles/instruction .

[Invité]

Petite question technique concernant cette démo :
Comment obtenir un sprite si coloré sur une Coleco ?
C'est un assemblage de plusieurs sprites pour obtenir un avec plus de couleur d'ou la limitation d'un tel procédé pour un projet de jeu ?
Merci !

[Invité]

c'est un assemblage de plusieurs sprites . 

[upsilandre]

Oui c'est ca faut superposer les sprites. Pour avoir 4 couleurs tu superpose 4 sprites 1bpp (ce qui est pas tres rentable car avec un sprite 4bpp comme sur Master system t'as 15 couleurs) et 4 sprites c'est le max sur la scanline.
C'est utilisé sur SG1000/Coleco/MSX pour avoir des sprites en 2 couleurs ou meme sur NES pour avoir plus de 3 couleurs.

[Invité]

Ok merci !!

Et l'on peut faire un affichage de ces 4 sprites toutes les 4 frames sans clignotement, vu la persistance rétinienne, cela serait invisible non ?
Et du coup, faudrait synchroniser tous les sprites sur la même ligne histoire d'avoir un maximum de sprites colorés ... Ahah !!  
Si j'avais l'occasion de faire, je testerai tiens !!  

[Tryphon]

Non, je pense que ça clignoterait sensiblement...

[upsilandre]

Vraiment pas mal du tout ta petite démo
On a vraiment pas l'impression d'être sur un coleco avec ce scrolling fluide et le sprite super coloré, on pense plutot à de la NES, et même pour de la NES ça serait assez joli
Je suis sur que tu ferais un excellent codeur et pourrait nous pondre des perles, dommage que ça ne t'interesse pas plus que ça
Tu dis ne pas aimer le Z80, je serais curieux d'en connaitre les raisons.
Je n'aime pas ce CPU non plus (qui équipe également la MD)... je code un peu dessus (toujours en assembleur, pas vraiment le choix) et je trouve ce CPU vraiment mal fichu, il est difficile de tirer partie de ses capacités pourtant c'est un CPU 8 bits assez avancé... je me sens toujours frustré quand j'essai de gagner des cycles, tu te dis que les instructions sont mal fichues, le CPU n'est pas efficace pour moi (par efficacité j'entends ce que tu peux traiter comme donnée pour une mémoire donnée.. ici la mémoire tourne à 1/3 de la fréquence du CPU je crois).
Je ne sais pas si tu connais la variante du Z80 utilisée dans la gameboy, mais je la trouve déjà bien plus "fonctionnelle", ils ont viré tout ce qui était inutile (et il y en a des choses inutiles ^^) et ajouté 2/3 instructions qu'il manquait cruellement, le CPU en devient réellement meilleur (la mémoire passe à 1/4 de la fréquence je crois).. et ça permettait à BigN de s'affranchir d'un copyright ou je ne sais quoi à payer

Le 6502, je ne peux pas dire que je l'aime   mais au moins il a sa logique : il est hyper simpliste et c'était ce qu'on lui demandait (le plus économique possible). Tu as un seul accumulateur et tu dois tout faire avec, c'est relou mais tu piges vite les contraintes et tu ne peux pas avoir un CPU à la fois économique et efficace (voir ma définition de efficace au dessus).

Bon après quand tu es habitué au 68000 (qui n'est pas parfait non plus, j'y aurai bien ajouté 3 ou 4 instructions aussi ^^), revenir à un Z80 ou un 6502 ça fait quand même très mal, tu te sens très à l'étroit, t'as l'impression de gacher plein de cycle partout :p

oui la gameboy ca a l'aire plus intéressant deja, je regarderais ca.
Et puis un jour aussi le 68000 par l'intermediaire de la Megadrive certainement (le 8086 j'ai deja fais y a plus de 20 ans mais j'ai pas de souvenir)

[upsilandre]

Ok merci !!

Et l'on peut faire un affichage de ces 4 sprites toutes les 4 frames sans clignotement, vu la persistance rétinienne, cela serait invisible non ?

hein? j'ai pas compris, tu veux faire clignoter les sprites pour eviter les clignotements?
dépasser la limite d'affichage de sprite par scanline c'est ce qui se fait dans quasiment tous les jeux 8bit mais effectivement ca veut dire alterner l'affichage des sprites d'une frame a l'autre et c'est ca qui produit les clignotement qu'on connait.

[Invité]

Ok merci !!

Et l'on peut faire un affichage de ces 4 sprites toutes les 4 frames sans clignotement, vu la persistance rétinienne, cela serait invisible non ?

hein? j'ai pas compris, tu veux faire clignoter les sprites pour eviter les clignotements?

En même temps c'est pas comme si c'était pas fréquent comme technique 
Au lieu d'avoir le cinquième sprite qui disparait complètement, tu alternes le clignotement sur tout ou 1 de tes sprites de la ligne à chaque frame, ça donne un effet de transparence, au lieu d'un effacement total et continu d'1 seul sprite .
C'est une technique souvent utilisée sur coleco ou nes .

Tu peux doubler le nombre de sprites/ligne sans que visuellement ce soit gênant .

[vincent2105]

Je ne sais pas si tu connais la variante du Z80 utilisée dans la gameboy, mais je la trouve déjà bien plus "fonctionnelle", ils ont viré tout ce qui était inutile (et il y en a des choses inutiles ^^) et ajouté 2/3 instructions qu'il manquait cruellement, le CPU en devient réellement meilleur (la mémoire passe à 1/4 de la fréquence je crois).. et ça permettait à BigN de s'affranchir d'un copyright ou je ne sais quoi à payer

oui la gameboy ca a l'aire plus intéressant deja, je regarderais ca.
Et puis un jour aussi le 68000 par l'intermediaire de la Megadrive certainement (le 8086 j'ai deja fais y a plus de 20 ans mais j'ai pas de souvenir)

La gameboy ça me tenterais bien aussi, si tu t'y mets, je serai un de tes lecteurs les plus attentifs

[upsilandre]

Ok merci !!

Et l'on peut faire un affichage de ces 4 sprites toutes les 4 frames sans clignotement, vu la persistance rétinienne, cela serait invisible non ?

hein? j'ai pas compris, tu veux faire clignoter les sprites pour eviter les clignotements?

En même temps c'est pas comme si c'était pas fréquent comme technique 
Au lieu d'avoir le cinquième sprite qui disparait complètement, tu alternes le clignotement sur tout ou 1 de tes sprites de la ligne à chaque frame, ça donne un effet de transparence, au lieu d'un effacement total et continu d'1 seul sprite .
C'est une technique souvent utilisée sur coleco ou nes .

Tu peux doubler le nombre de sprites/ligne sans que visuellement ce soit gênant .

oui et c'est pour ca que ca clignote. On peut s'affranchir des limites d'affichage par scanline mais pas sans clignotement malheureusement. Si c'est bien la question de Vetea.

[Tryphon]

C'est pas comme ça que je l'ai comprise, mais comme je suis fatigué, je vais attendre qu'il la précise :)

[Invité]

Ah oui, ça clignotera tjrs forcement,la technique le rend bcp moins chiant visuellement et améliore le gameplay c'est tout .

@tryphon: moi je l'ai prise comme je l'ai expliqué, mais ct peut être pas à ca que vetea pensait .

[upsilandre]

Je ne sais pas si tu connais la variante du Z80 utilisée dans la gameboy, mais je la trouve déjà bien plus "fonctionnelle", ils ont viré tout ce qui était inutile (et il y en a des choses inutiles ^^) et ajouté 2/3 instructions qu'il manquait cruellement, le CPU en devient réellement meilleur (la mémoire passe à 1/4 de la fréquence je crois).. et ça permettait à BigN de s'affranchir d'un copyright ou je ne sais quoi à payer

oui la gameboy ca a l'aire plus intéressant deja, je regarderais ca.
Et puis un jour aussi le 68000 par l'intermediaire de la Megadrive certainement (le 8086 j'ai deja fais y a plus de 20 ans mais j'ai pas de souvenir)

La gameboy ça me tenterais bien aussi, si tu t'y mets, je serai un de tes lecteurs les plus attentifs

nan je peux jeter un oeil plus approfondie mais pas plus, les portables ca m'intéresse pas assez.

[TotOOntHeMooN]

Non, je pense que ça clignoterait sensiblement...

Dans le meilleur des cas, ça fera un effet "fantôme" entre sprite et background.
Après, c'est cool si le jeu c'est Ghostbusters. 

[Invité]

C'est le même effet que qd t'es bourrée en fait 

[bfg]

Voila mon premier (et probablement dernier) programme assembleur sur Colecovision

https://youtu.be/uD5omwFFnog (a regardez en HD pour avoir le 60fps)


Alors vous emballez pas, c'est juste des expériences d'affichage, y a aucune mecanique de jeu derrière. On controle le personnage au pad mais on peut juste marcher vers la gauche ou la droite. Je voulais surtout m'amuser a faire du smooth scrolling au pixel a 60fps (mettez la video en HD pour avoir le 60fps) sur cette machine ou y a aucun scrolling.
Je pré-shift simplement tout le tileset au démarrage du jeu. Le gros atout de la Colecovision a l'epoque c'etait d'avoir beaucoup de VRAM mais en général totalement gaché par le mode 2. Et combiner a la flexibilité de l'adressage de toutes les tables on peut pas mal s'amuser avec cette VRAM je pense. Donc je voulais faire un truc qui profite au max de ca (evidement le pré-shift c'est une autre facon de gaché la VRAM) d'autant que comme par hasard on peut justement adresser 8 bank differente pour le tileset et c'est exactement ce qu'il fallait pour faire un smooth scroll au pixel.
Au final une fois tout bien préparé au démarrage du jeu l’intégration du smooth scroll est extrement simple. Je prend les 3 bit de poid faible des coordonnée X de ma camera et je les envoie dans le registre d'adresse de la table du tileset et c'est tout. A ce moment la ca prend aucune ressource CPU, c'est comme si l'offset au pixel etait hardware (facon C64 ou Intellivision).
Reste quand meme a faire le scrolling lui meme qui est software et qui demande a mettre a jour toute la tilemap. Je le fais en double buffering etalé sur 3 frames et au final ca prend peu de ressource aussi.
En tout pour toute la gestion du scrolling de A a Z ca me prend a peine 20 scanlines (soit 7.5% de ressource CPU) et avec du triple buffering (ou un scorlling bloqué dans une seul direction genre Contra)  ca prendrait encore 2 fois moins. Et le Vblank est tellement long (ca fait bisarre quand tu viens de la NES) que ca rentre largement pendant le Vblank . Par contre ma tilemap n'est pas compressé donc ca simplifie beaucoup les choses evidement (et puis j'ai fait un petit script python pour transformer les 4 tilemap 256x192 en une seule tilemap 1024x192 pour que ce soit encore plus optimale)
Evidement c'est rigolo ce smooth scroll parfaitement fluide sur Coleco mais c'est beaucoup de contrainte pour la construction du background en terme de couleur et de variété de tuile (faut penser les tuiles en binome) mais ca reste faisable.
Par contre la partie sprite est completement bullshit, alors oui ca tourne sur Coleco mais on pourrait pas faire un vrai jeu avec des sprites de cette qualité, la je me suis fait plaisir sur la demo parce qu'il y a qu'un seul sprite et parce que je voulais tester aussi l'affichage de sprite.
D'ailleurs pour ceux qui n'ont pas reconnu le level est piqué en grande partie de Megaman 2 et le sprite de Shatterhand.

Je crois comprendre le principe, mais je comprends pas comment tu construis la map ... Les tiles sont forcément dépendantes les unes des autres, et je bloque à visualiser la truc ...