[ NES ] Alex Kidd in Miracle World

[upsilandre]

Exercice: Refaire le level 1 d'Alex Kidd Master System sur la NES


Le lien de la ROM que je mettrais a jour chaque fois que je bosserais dessus
#############################################################
# https://drive.google.com/open?id=0B399kteofpYuT0tnd0lzZmFHcjQ #
############################################################


Voila c'est partie, j'ouvre un topic dans le prolongement de la conversation débuté sur cette autre topic https://www.gamopat-forum.com/t81679p25-besoin-d-aide-pour-un-redone-de-ghost-n-goblins-sur-nes (si vous voulez le début de l'histoire)
Je me suis donc décidé a mettre les mains dans le cambouis la semaine dernière. On peut pas vraiment appeler ca un projet, c'est plus un exercice de programmation pour acquérir des bases. J'ai pas l'intention a priori de faire plus que le premier level (qui est emblématique). Et ca sera au rythme de mes disponibilités et mes envies, j'ai pas d'objectif, c'est pour le plaisir.  
Il sagit bien sur de programmation assembleur et "from scratch" comme on dit.


Apres de long ajustements je suis assez content d'avoir réussit a reproduire correctement le background malgres les spécificité de la NES (pas de palettes RGB, seulement 3 couleurs par pattern, seulement 4 palettes de 3 couleurs, seulement une palette par metatile). Visuellement au moins ca fonctionne. Ca m'a retardé dans le code mais j'avais besoin de savoir.  
J'ai aussi refais et upgradé le sprite par rapport a la derniere fois pour etre vraiment pixel perfect avec l'original (a par quelque nuances de couleurs). Pour arriver a faire un beau sprite comme sur SMS avec la NES ca demande de la bidouille et + de budget sprite. Je me suis autorisé a augmenter le budget du sprite d'alex car apres calcule et avec un peu de bidouille ca devrait passer (je parle au niveau flickering, d'autant que sur la version Master System les sacs de pognon sont des sprites ce qui est idiot et ajoute une charge inutile dont je ferais l’économie en les intégrants au background), j'avais ete un peu strict sur mon premier jet (je voulais pas surcharger car je connais les limites de la machines) mais ca vaut le coup qu'il soit réussit.


J'ai donc aussi commencé a implémenter l'animation et le controle d'Alex au pad. On peut se deplacer (j'ai laissé le scrolling horizontal mono-screen), s'accroupir, donner un coup de poing. Manque le saut et y a bien sur aucune interaction pour l'instant, on en est loin.  
Mais rien que sur ces premiers elements de controle je me suis acharné a reproduire parfaitement le comportement original comme la durée des frames d'animations, les coefficients d'accélérations et de décélération (j'ai récupéré les valeurs de la version SMS), les 10 frames de freeze quand tu fais un punch, le fait de garder l'inertie de décélération en position accroupi (glissade) ou de pouvoir se retourner, le fait que la sequence d'animation de la marche se prolonge meme une fois lacher le stick tant que la décélération n'est pas terminé, le fait de pouvoir cumuler la décélération naturel + l'accélération en sens inverse quand tu fais un demi-tour, de pas pouvoir prolonger les 10 frames de punch en appuyant tres vite ect...
C'est tout les petits détails qui font qu'on a l’impression ou pas de controler l'original donc c'est important.

[upsilandre]

La version Master System




Le truc intéressant c'est qu'avec la NES on a + de résolution vertical et justement sur SMS avec ce démarrage en scrolling vertical descendant on etait un peu a l'etroit, ca genait un peu le gameplay, sur NES on sera plus a l'aise pour ce genre de scrolling (surtout en emulation ou l'on voit toutes les lignes).

[Alucardark]

Ah oui, je viens de tester la Rom et effectivement on a l'impression d'avoir la version Master System  en main (il manque l'action du saut pour être vraiment sûr, mais je chipote). En tout cas bravo, avec une première démo tu nous vends du rêve (entre toi qui veut nous faire un Alex Kidd sur NES et gvx32 qui nous fait un Megaman 2 sur Master System, les prochains mois risquent d'être intéressants).

P.S. : Si jamais t'as besoin d'aide pour les tiles, fais-moi signe.
P.P.S. : Tu vas rigoler, mais il y a 2/3 ans j'avais testé le sprite d'Alex Kidd avec le CSA Editor (via Megaman 4).

[upsilandre]

Ca ne m'etonne pas
Et je vois que t'avais encore utilisé tous le budget dans le sprite
Alex kidd SMS c'est 6 sprites, dans le tiens je dirais 12 sprites avec la moitié du budget par scanline sur toute la hauteur du sprite et 3 palettes sur 4. C'est moins pire que pour Arthur mais va falloir changer ces mauvaises habitudes    ou alors effectivement passer sur PC-Engine/Supergafx, pour un graphiste je pense que c'est bien plus intéressant (t'as 32 palettes et 16 couleurs par palettes) tu devrais essayer. Ca reste oldschool (c'est plus ou moins encore de la 8bit) mais deja beaucoup de liberté pour un graphiste, infiniment plus que sur NES.

La palette de ton Alex Kidd m'intrigue aussi, c'est pas la palette Fceux. Ca ressemble a la palette de la version RGB des PPU utilisé pour la version Arcade de la NES.
C'est difficile de choisir les couleurs sur NES car y a pas de consensus sur la facon d'emuler la palette (au moins sur SMS c'est du pure RGB, y a rien a emuler). Tu m'as donnée envie de faire un peu plus de test. Au final j'ai modifié la couleur du visage et le bleu des chaussures (mais pas applicable au ciel comme sur SMS ou se sont les memes)

Ca passe a peu pret dans divers situations

P.S. : Si jamais t'as besoin d'aide pour les tiles, fais-moi signe.

Tu remarquera que j'ai du refaire la pattern végétale car je pouvais pas mixer l'herbe et la roche dans le meme bloc sur NES, c'etait compliqué pour moi  

[Alucardark]

Ca ne m'etonne pas
Et je vois que t'avais encore utilisé tous le budget dans le sprite
Alex kidd SMS c'est 6 sprites, dans le tiens je dirais 12 sprites avec la moitié du budget par scanline sur toute la hauteur du sprite et 3 palettes sur 4. C'est moins pire que pour Arthur mais va falloir changer ces mauvaises habitudes

C'est mon côté graphiste acharné qui parle, il faut toujours que j'en fasse trop.  
J'utilise effectivement 12 tiles pour Alex (6 pour le survet et le contour des cheveux, puis 6 autres pour la tête, les mains et les cheveux). Par contre j'utilise 2 palettes pour Alex. Mon but était de voir combien de tuiles il fallait pour faire un Alex à l'identique, et j'ai vu qu'il fallait quand même utiliser l'équivalent de deux sprites pour le représenter à l'identique! De là je me suis dit qu'un GNG sur Master System utiliserait moins de ressources graphiques pour avoir quelque chose proche de l'arcade!

 ou alors effectivement passer sur PC-Engine/Supergafx, pour un graphiste je pense que c'est bien plus intéressant (t'as 32 palettes et 16 couleurs par palettes) tu devrais essayer. Ca reste oldschool (c'est plus ou moins encore de la 8bit) mais deja beaucoup de liberté pour un graphiste, infiniment plus que sur NES.

Ah mais si je devais passer sur Supergrafx, ça serait pour quelque chose de complètement original (mais le problème resterait le même, à savoir qu'il me faudrait un programmeur ).

La palette de ton Alex Kidd m'intrigue aussi, c'est pas la palette Fceux. Ca ressemble a la palette de la version RGB des PPU utilisé pour la version Arcade de la NES.
C'est difficile de choisir les couleurs sur NES car y a pas de consensus sur la facon d'emuler la palette (au moins sur SMS c'est du pure RGB, y a rien a emuler). Tu m'as donnée envie de faire un peu plus de test. Au final j'ai modifié la couleur du visage et le bleu des chaussures (mais pas applicable au ciel comme sur SMS ou se sont les memes)

Alors pour la palette, j'ai laissé celle par défaut sur FCEUX (donc probablement du RGB). J'ai testé le mode NTSC de l'émulateur et on a effectivement des couleurs plus ternes (mais plus proches de la NES).

Tu remarquera que j'ai du refaire la pattern végétale car je pouvais pas mixer l'herbe et la roche dans le meme bloc sur NES, c'etait compliqué pour moi  

Et tu as remarquablement bien fait car il t'aurait été difficile de faire mieux, surtout que sans le MMC5, tu ne peux utiliser une palette que sur des bolcs de tiles de 16x16 pixels (alors qu'avec le MMC5, tu peux utiliser une palette sur 8x8 pixels).

[Révo]

Quelle drole d'idee de convertir ce jeu sur systeme inferior.

En tout cas c'est original, je te souhaite bon courage.

[upsilandre]

Je pense que c'est un projet typiquement franco-francais    .
Je me rend compte que Alex Kidd a plus marqué les francais que les autres pour divers raisons local. Au US ou au Japon je crois que tout le monde s'en fou de ce jeu ce qui explique peut etre qu’apparemment ce type de portage homebrew (qui semble pourtant un classique a nos yeux) n'a pas deja ete fait semble t'il.

Et je trouve que le premier level de ce jeu est l'un des meilleur premier level pour un jeu de l'epoque (alors que le reste est plutot moyen). C'etait une superbe invitation au voyage.
Démarrer direct par un scrolling vertical (clairement pour le contre-pied de Super Mario, d'ailleurs le créateur a meme avoué avoir inversé le bouton saut pour la meme raison meme si il admet que c'etait un peu puéril) et qui descend au lieu de monté pour s'enfoncer jusqu'a finir par plonger dans une sorte de source souterraine en switchant sur un scrolling horizontal. Un beau moment a l'epoque. C'etait assez marquant quand tu decouvrais les jeux video sur ces nouvelles consoles 8bit (et souvent quand t'etait gamin t'allais pas forcement plus loin car c'etait assez difficile comme jeu mais tu gardais ce bon souvenir).


Par contre le fait d'avoir débuter mon pèlerinage par l'Atari 2600 ou j'avais commencé par un jeu qui utilisait 64 octets de RAM (et 2Ko de ROM) sur NES avec ses 2Ko de RAM j'ai l'impression que c'est Byzance, je sais pas quoi faire de toute cette RAM d'autant que je peux pas m’empecher d'optimiser le moindre octet (ou la moindre instruction) par réflexe. Je pense que je perd souvent du temps pour rien mais j'aime bien.
Mais j'avais quand meme bien perdu les quelques reflexes 6502 que j'avais acquis, le démarrage etait laborieux.

[upsilandre]

Par contre j'utilise 2 palettes pour Alex.

Exacte j'avais pas vu que t'avais fait l'economie d'une couleur de la version original (dans l'oreille) pour eviter d’empiéter sur une 3eme palette, comme quoi tu fais quand meme des efforts d'optimisations .

Alors pour la palette, j'ai laissé celle par défaut sur FCEUX (donc probablement du RGB). J'ai testé le mode NTSC de l'émulateur et on a effectivement des couleurs plus ternes (mais plus proches de la NES).

Je trouve pas ces couleurs sur mon Fceux, peut etre les "emphasis bits" mais je crois pas qu'ils soient utilisé sur Megaman. Peut importe de toute facon, y a tellement de variante dans l'emulation.

[Alucardark]

Exacte j'avais pas vu que t'avais fait l'economie d'une couleur de la version original (dans l'oreille) pour eviter d’empiéter sur une 3eme palette, comme quoi tu fais quand meme des efforts d'optimisations  .

Oui, je sais faire des concessions quand même   (ceci dit, il aurait fallut une 3e palette pour avoir exactement le même nombre de couleurs que sur Master System).

Je trouve pas ces couleurs sur mon Fceux, peut etre les "emphasis bits" mais je crois pas qu'ils soient utilisé sur Megaman. Peut importe de toute facon, y a tellement de variante dans l'emulation.

Je regarderai ça plus en détail ce soir histoire de voir ce quel mode de couleur a été utilisé.

Sinon pour ma part je vais voir comment je peux adapter les tiles sur NES, ça me permettra de voir le nombre de palettes nécessaires au premier niveau (à mon avis il en faudra plus que 4 pour se rapprocher de la version originale). Par contre je ferai ça sans passer par le MMC5 (donc par une version non hacké de Megaman 4) dans un premier temps.

[upsilandre]

Je regarderai ça plus en détail ce soir histoire de voir ce quel mode de couleur a été utilisé.

Le plus simple c'est de partager les codes couleurs, chaque couleur NES a un code hexa et ca au moins y en a qu'un, ca permet de savoir si c'est la meme couleur ou pas. (ou simplement ouvrir le fichier .pal de la palette et copier la ligne de texte sur le forum comme cela: 11 0F 01 16 11 0F 20 27 , ca c'est la palette de mon Alex sachant que le $11 ne compte pas puisque c'est la transparence)

Sinon pour ma part je vais voir comment je peux adapter les tiles sur NES, ça me permettra de voir le nombre de palettes nécessaires au premier niveau (à mon avis il en faudra plus que 4 pour se rapprocher de la version originale). Par contre je ferai ça sans passer par le MMC5 (donc par une version non hacké de Megaman 4) dans un premier temps.

Sur mon screenshot y a deja toutes les tiles utiles pour la premiere partie (scrolling vertical). Une palette pour la roche (et les blocs destructibles), une palette pour l'herbe (avec du marron pour la transition), une palette pour les nuages (qui servent aussi pour les sacs de pognon) et une palette pour les bonus (mais impossible d'avoir du jaune sur NES a moins de sélectionner l'emulation RGB de l'arcade mais c'est plus la NES, et a defaut de pouvoir ajouter aussi du noir j'ai utilisé la couleur bleu du background, ca passe)

Si j'arrive jusque la, pour la seconde partie dans l'eau meme si c'est les memes couleurs agencé différemment j'utiliserais probablement un trigger pour modifier certaines palettes pendant le plongeon quite a rallonger la hauteur du plongeon pour aider la transition, c'est pas simple (d'autant qu'il faudra probablement changer la couleur de fond pour passer du $11 du ciel au $21 de l'eau). Va falloir trické. Les sprites ennemis aussi (y a un seul ennemis dans la premieres parties donc ca ira mais 3 dans la seconde + le fantome, l'homme grenouille va poser probleme en couleur et en taille + ses projectiles)

La palette de mon screenshot d'accueille que j'avais mis en "custom" c'est apparemment la palette standard Nestopia YUV (sélectionnable dans Fceux)



Le MMC5 c'est toujours tentant a utilisé, j'aime bien l’ingéniosité du truc, je vois bien tout ce que ca permet mais ca me plairait pas de l'utiliser dans un projet personnel malgré la tentation car ca dénature trop le hardware original et ca colle pas avec ma demarche, je programme sur NES ou sur Atari 2600 avant tout parce que je m’intéresse a leur hardware.
Le MMC5 c'est pas non plus le niveau de transgression des copro de la SNES ou la c'est vraiment plus de la SNES que tu programme mais on se rapproche un peu alors que jusque la les mappers NES etaient de vulgaire mapper mémoire tout ce qu'il y a de plus basique (contrairement a ce qu'on entend dire parfois) comme il y en a aussi dans chaque cartouche SMS (meme si mieux integré), au mieux t'avais juste un simple compteur de scanline comme commodité bonus et dont on peut se passer (Quand tu vois ce que Rare a fait sur NES en raster effect avec des mapper encore plus basique que ceux de la SMS). Le MMC3 c'est le max autorisé pour moi (si t’enlève le compteur de scanline y a rien, c'est juste un mapper avec une bonne granularité)
La dessus j'ai pas mal de principe meme si c'est des lignes qui bouges, sur Atari 2600 je voulais pas utiliser de mapper alors que ca me dérangerait pas d'en utiliser sur NES car a mon avis elle a ete concu avec les mappers en tete, vu son potentiel en scrolling et sprites elle a pas ete concu pour se limiter a 8Ko de pattern graphique ou 32Ko de rom pgr.

[philip]

Oui cela explique la longévité de cette console, elle a bien résisté face à la concurrence.

[upsilandre]

Oui et pas a cause d’hypothétique copro comme on entend trop souvent, y a pas de puissance caché dans les cartouches comme on a eu sur SNES.

Les seuls copro ca serait les chips sonores qui existent dans quelques cartouches mais ca se compte sur les doigts de la main et seul la Famicom peut utiliser ce genre de cartouche, la NES n'est pas cablé pour ca (l'audio passe pas par le port cartouche), et donc le MMC5 qui a un statut un peu intermediare mais qui se compte aussi sur les doigts de la main (c'est un mapper nintendo et meme nintendo ne l'a pas utilisé)

[Invité]

Je trouve que ton adaptation from scratch est la bonne chose à faire, bcp de boulot, mais tellement plus formateur et valorisant,en plus alex kid est un jeu génial sur SMS .

En plus ça commence déjà for bien .
je suis curieux de comment tu vas implémenté la physique d'alex en 6502 .
Bon courage en tout cas .

Sans raster counter c'est très difficile de faire plus d'une rupture sur snes, à moins de perdre bcp de CPU ou d'utiliser le swap de tiles pour simuler les parallaxes.
L'astuce souvent utilisée est de jouer avec l'interruption générée par la collision du sprite 0 .

je sais pas quoi faire de toute cette RAM d'autant que je peux pas m’empecher d'optimiser le moindre octet (ou la moindre instruction) par réflexe. Je pense que je perd souvent du temps pour rien mais j'aime bien.

Je suis pareil, et ce qui est fait n'est plus à faire au moins 

[upsilandre]

je suis curieux de comment tu vas implémenté la physique d'alex en 6502 .
Bon courage en tout cas .

Deja rien que d'avoir du faire un peu d’arithmétique 16bit signé pour bien gérer l'acceleration/deceleration ca m'a obligé a me remettre dans le bain du 6502. mais j'aime bien ce cpu, il est marrant. C'est fascinent d'ailleurs de le regarder fonctionner de pret grace aux simulations "level transitor" qui existe (les mec ont quand meme reussit a simuler la VCS et la NES en photographiant et en retracant de facon vectoriel a la main chaque transitors), y a tellement peu de transitors et pourtant ca fonctionne (et bien).

Sans raster counter c'est très difficile de faire plus d'une rupture sur snes, à moins de perdre bcp de CPU ou d'utiliser le swap de tiles pour simuler les parallaxes. L'astuce souvent utilisée est de jouer avec l'interruption générée par la collision du sprite 0 .

Je sais meme pas si on peut encore parler d'astuce vu que c'est la principale fonction de cette feature de collision sur NES et elle etait tout le temps utilisé meme dans les premiers jeux (et dans super mario aussi).
Ce qui me fait marrer c'est vraiment Rare et battletoad, ils ont utilisé le pire mapper de l'histoire NES/SMS, pire que les tout premiers mapper NES, y a rien dedans, évidement pas de compteur de scanline (alors que c'est le jeu qui utilise le plus de raster effect a ma connaissance), meme pas de mirroring de la VRAM histoire de compliqué aussi le scrolling et la pire granularité de bank switching, juste 3bit pour choisir parmis 8 bank de 32Ko qui est donc la totalité de la rom adressable alors que tous les mappers (nes ou master system) propose au moins une granularité 16Ko pour pas bank switcher toute la rom adressable a chaque fois pendant l'execution ce qui doit etre tres chiant.
bref c'est des malades et en plus leur rom est l'une des mieux optimisé en terme d'occupation (tres peu de redondance et d'espace vide) malgres les contraintes (notamment sur le bank switching)

Je suis pareil, et ce qui est fait n'est plus à faire au moins 

ouai je pense qu'il faut jamais trop relacher l'effort sans forcement chercher l'opti 100% car c'est sans fin (et ca consiste souvent a compliqué la lisibilité du code)
Ce soir j'ai rien fait, j'ai juste remis de l'ordre dans la mise en page de mon code et ajouté plein de commentaire. Je reprendrais peut etre plutot ce week end.

[Invité]

Je sais meme pas si on peut encore parler d'astuce vu que c'est la principale fonction de cette feature de collision sur NES et elle etait tout le temps utilisé meme dans les premiers jeux (et dans super mario aussi).

Oui mais pas pour servir à faire des effets rasters,si ?? ..
Elle est peu utilisée car seul le sprite 0 permet la détection de collision, c'est trop léger pour l'utiliser dans un jeu .
Le problème c'est que cette astuce ne peut servir qu'une fois / frame .

ouai je pense qu'il faut jamais trop relacher l'effort sans forcement chercher l'opti 100% car c'est sans fin (et ca consiste souvent a compliqué la lisibilité du code)

C'est vrai, moi je cherche d'abord à ce que je veux faire marche, ensuite j'optimise le plus possible pour ne plus y revenir (sauf si j'ai une révélation lol) .

[upsilandre]

Oui mais pas pour servir à faire des effets rasters,si ?? ..
Elle est peu utilisée car seul le sprite 0 permet la détection de collision, c'est trop léger pour l'utiliser dans un jeu .

Si a priori c'est utilisé quasi uniquement pour les raster effect, c'est pas destiné a gérer les collisions (c'est pour ca que ca concerne que le sprite 0), sa fonction c'est vraiment de compenser l'absence de compteur de scanline qui est un gros manque. Et c'est utilisé dans beaucoup de jeu, par exemple dans Super mario le HUD c'est un raster effect au sprite 0, c'est l'usage classique.

[upsilandre]

Voila ou se trouve le sprite 0 dans Super Mario



il est en priorité low donc le reste de la piece (qui est une tile de bg) s'affiche partiellement par dessus et a 3 pixels successif qui entre en collision avec le sprite 0 et qui sera le signal pour modifier l'offset du scrolling.

[Invité]

c'est pour ca que ca concerne que le sprite 0), sa fonction c'est vraiment de compenser l'absence de compteur de scanline 

Non là je suis pas d'accord, sur PCE tu as aussi cette interruption de collision sur le sprite0, et pourtant tu as aussi des interruptions HSYNC .
C'est absolument pas pour compenser sur nes, car tu ne peux que l'utiliser 1 seule fois /frame (donc ça limite fortement son intérêt), le multiplexage de sprites est impossible sur nes .
Donc justement il est utilisé quand tu as un HUD qui ne scrolle pas .

Et c'est utilisé dans beaucoup de jeu, par exemple dans Super mario le HUD c'est un raster effect au sprite 0, c'est l'usage classique.

Ca je veux bien te croire, mais c'est plus une astuce que réellement pensé pour ça à la base,autant mettre un vrai compteur à la place, bien plus utile et efficace en plus de pas te bouffer ta BP de sprites .

il est en priorité low donc le reste de la piece (qui est une tile de bg) s'affiche partiellement par dessus et a 3 pixels successif qui entre en collision avec le sprite 0 et qui sera le signal pour modifier l'offset du scrolling.

Oui juste le minimum pour générer une interruption, pas con l'astuce .


Y'a un topic intéressant sur les rasters nes :
http://forums.nesdev.com/viewtopic.php?f=2&t=13188

[upsilandre]

Je me demande quand meme a quoi d'autre peut servir la collision du sprite 0?  
Pour savoir si le sprite 0 est en contact avec un autre element y a plein d'autre moyen assez simple, ca me parait un peu ridicule de l'utiliser pour ca. L'interet de ce flag c'est pas l'information qu'il donne mais bien le moment ou il la donne (le moment ou il est rasterisé).
Ou alors c'est juste une relique du passé (car c'etait present dans les premieres consoles mais sur tous les sprites, ce genre de flag de collision doit pas couter chère en transistors)

Je me demande aussi si sur NES y a pas des raster effect qui exploite l'IRQ du canal audio DMC. On peut le caler sur divers frequence.

[Invité]

Je me demande quand meme a quoi d'autre peut servir la collision du sprite 0?  

La nes est une console de 85, les collisions hardware sur les sprites dans les consoles ça courait pas les rues .
Je pense qu'à la base les ingés voyaient les jeux assez simplement , un jeu style mario peut très bien utiliser le sprite 0 et utiliser la détection de collisions .
Un space invader où le tir du joueur est le sprites 0, etc ..

Ca permet soit de faire du pixel perfect avec 0% de CPU, ou bien de déclencher un test par bounding box seulement quand c'est utile, et non à toutes les frames .
Avec les jeux qui se sont complexifiés, son utilité est devenue quasi nulle, sauf pour l'effet raster, mais comme le sprite n'est pas repositionnable dans une même frame l'intérêt reste très limité(dommage d'ailleurs) , mais utile sans interruptions raster pour un HUD par exemple.

Pour ma part je vois un compteur raster bien plus simple à réaliser et moins consommateur en transistors qu'une détection de collision, même sur un seul sprite,mais je me trompe peut être .

Je me demande aussi si sur NES y a pas des raster effect qui exploite l'IRQ du canal audio DMC. On peut le caler sur divers frequence.

C'est fort probable aussi .
Juste un compteur 8 bit incrémenté à chaque ligne et comparé à une valeur sur 8 bit de référence, si compteur++ = raster_de_ref alors interruption .

Ou alors c'est juste une relique du passé (car c'etait present dans les premieres consoles mais sur tous les sprites, ce genre de flag de collision doit pas couter chère en transistors)

Oui tu confirmes ce que je pense aussi, et je pense pas qu'un compteur raster soit plus consommateur niveau transistors .

L'interet de ce flag c'est pas l'information qu'il donne mais bien le moment ou il la donne (le moment ou il est rasterisé). 

Oui mais les sprites sont parsés surement dans le hblank, donc l'interruption claque en début de ligne je pense, et non quand le faisceau parcoure l'écran .

[upsilandre]

La nes est une console de 85, les collisions hardware sur les sprites dans les consoles ça courait pas les rues .

Si justement c'etait present dans toutes les consoles qui précedait la NES dès qu'il y a eu des sprites. L'Atari 2600, l'Odyssey2 / Videopack ou l'Intellivision ont un systeme de flag hardware de collision des sprites mais justement c'etait bien plus evolué que sur NES, t'avais plusieurs flags pour identifier tous les type de collision qui t'indique quelle sprite a touché quelle sprite ou le background.
L'intellivision (1979) c'est 80 flags hardware dédié aux collision pour seulement 8 sprites a l'ecran contre 1 seul flag sur NES pour 64 sprites (l'equivalent NES serait 4220 flags).
L'Odyssey 2 (1978) c'est l'equivalent de 49 flags hardware pour les collisions (en 2 passes).
l'Atari 2600 (1977) c'est 15 flags hardware pour les collisions.

Je pense qu'à la base les ingés voyaient les jeux assez simplement , un jeu style mario peut très bien utiliser le sprite 0 et utiliser la détection de collisions .

Impossible ca te donne aucune information, c'est juste un seul sprite alors qu'un personnage c'est plusieurs sprite et en plus il t'indique pas si y a une collision avec un autre sprite, il t'indique juste si tu touche dans le background une couleur qui n'est pas la couleur 0 et qui peut etre n'importe quelle element cosmetique du décore comme les buissons de mario par exemple qui n'est pas un obstacle mais le flags ne fera pas la difference et t'indiquera meme pas de toute facon ce que c'est donc tu sera obligé quoiqu'il arrive de traiter en software meme cette unique test de collision du pied droit de mario avec le buisson (en plus des autres).
L'information qu'il te donne est insignifiante pour un moteur de collision d'un jeu NES meme le plus basique (comme je disais plus haut pour avoir l'equivalent de la gestion hardware des collisions de l'intellivision faudrait 4220 flags sur NES). C'est evident qu'il est pas la pour ca.

Perso j'ai pas d'autre exemple d'utilisation du sprite 0 sur NES que le raster effect mais doit peut etre y en avoir mais je suis a peu pret certain que les autres utilisations sont tres minoritaire si y en a.

C'est fort probable aussi .
Juste un compteur 8 bit incrémenté à chaque ligne et comparé à une valeur sur 8 bit de référence, si compteur++ = raster_de_ref alors interruption .

Par contre le DMC permet pas une interruption a chaque ligne, au mieux 4 lignes et surtout c'est pas des chiffres rond (ca va etre 3.8 lignes ect...) et puis ca cause des conflit je crois avec d'autre I/O, bref je sais pas trop si des jeux l'utilise de cette facon.

Oui mais les sprites sont parsés surement dans le hblank, donc l'interruption claque en début de ligne je pense, et non quand le faisceau parcoure l'écran .

Meme dans ce cas ca reste quand meme le moment ou il te donne l'information (meme si c'est dans le hblank) plutot que l'information elle meme du flag qui a un interet.

[Invité]

Si justement c'etait present dans toutes les consoles qui précedait la NES dès qu'il y a eu des sprites. L'Atari 2600, l'Odyssey2 / Videopack ou l'Intellivision ont un systeme de flag hardware de collision des sprites mais justement c'etait bien plus evolué que sur NES, t'avais plusieurs flags pour identifier tous les type de collision qui t'indique quelle sprite a touché quelle sprite ou le background. 

Oui c'était faisable car ces machines possèdent peu de sprites,ça devient plus compliqué avec /32/64 sprites .

Impossible ca te donne aucune information, c'est juste un seul sprite alors qu'un personnage c'est plusieurs sprite

Pas forcement, un tir de space invader par exemple, un sprite suffit, je je suis sur que pas mal de premiers jeux snes n'utilisaient pas plus d'un sprite pour le joueur .

Perso j'ai pas d'autre exemple d'utilisation du sprite 0 sur NES que le raster effect mais doit peut etre y en avoir mais je suis a peu pret certain que les autres utilisations sont tres minoritaire si y en a.

Tu as raison, son utilité en tant que sprite est très limité ,sur PCE elle est jamais utilisée, car trop limitée et surtout tu peux pas masquer le sprite 0 avec les autres sprites .

[upsilandre]

Oui c'était faisable car ces machines possèdent peu de sprites,ça devient plus compliqué avec /32/64 sprites .

On est daccord, sur NES faudrait plusieurs milliers de flags pour que ca ait la meme fonction que sur ces vieilles consoles, c'est bien pour ca que le fait de passer a un unique flags (alors qu'il y en avait des dizaines avant) est bien la preuve que les ingés l'on pas mis pour cette information de collision mais pour le moment ou il donne l'information. Ca coute apparemment rien en transitsors.

Pas forcement, un tir de space invader par exemple, un sprite suffit, je je suis sur que pas mal de premiers jeux snes n'utilisaient pas plus d'un sprite pour le joueur .

meme dans ce cas l'interet est totalement insignifiant. Faut pas que la cible soit un sprite mais un element de décore et meme dans ce cas tu saura pas du tout ce que tu as touché dans le décore, ni a quelle endroit, ni si c'est cosmetique ou pas. Au final t'es a peu pret certain de perdre plus de cycle CPU que d'en gagner en faisant de ce flag un cas particulier exterieur a ton moteur de collision software qui reste de toute facon indispensable. Meme si tu gagnais 2 ou 3 instructions sur une frame ca pourrait pas justifier.

[Invité]

meme dans ce cas l'interet est totalement insignifiant. Faut pas que la cible soit un sprite mais un element de décore et meme dans ce cas tu saura pas du tout ce que tu as touché dans le décore, ni a quelle endroit, ni si c'est cosmetique ou pas. Au final t'es a peu pret certain de perdre plus de cycle CPU que d'en gagner en faisant de ce flag un cas particulier exterieur a ton moteur de collision software qui reste de toute facon indispensable. Meme si tu gagnais 2 ou 3 instructions sur une frame ca pourrait pas justifier

C'est vrai, mais tu vas déclencher ton test en bounding que lorsque une collision arrive, et pas tout le temps,donc non tu vas en gagner c'est certain,car des tests de collision de 1 avec Xsprites à chaque frame,sera toujours plus consommateur que 1 sur Xsprites seulement si il y a collision .
Mais bon son utilisation reste limité dans des cas assez simples, où le joueur est constitué d'un seul sprite, où dans le cas du tir, si il est au coup par coup .
Je m'en suis servi quand je faisais mummuse sur PCE avec une adaptation de galaxian,ça marchait bien . .

dans le cas d'alex tu peux t'en servir pour la partie du corps par exemple, ça pourrait marcher pour les collisions sprites/sprites, de toutes façons une box ne prend en général pas tout le sprite .

[upsilandre]

C'est vrai que ca peut etre pas mal pour un tire mais si ta frame peut supporter la charge du test bounding de ton tire alors les autres frames peuvent le supporter aussi, au final le test du flag ne fait qu'ajouter quelques cycles en plus du bounding et donc devient une charge supplémentaire plutot qu'une economie en plus de couter un sprite.

C'est valable si t'es dans une optique ou t'accepte des chutes de framerate quand tu fais le bounding de ton tire (accepter 2vbl au lieu d'1 a ce moment la) et que tu veux donc limiter les moments ou ca chutes (et aussi a condition d'avoir un background sur un fond uni et vide ou les seuls element graphique sont les obstacle aux tire sinon le bounding va s'activer tout le temps) mais ca me convainc pas vraiment a vrai dire.

dans le cas d'alex tu peux t'en servir pour la partie du corps par exemple, ça pourrait marcher pour les collisions sprites/sprites, de toutes façons une box ne prend en général pas tout le sprite .

Ca ne fonctionne pas pour les collisions de sprite seulement pour la collision sprite 0 et bg en couleur 1,2,3. C'est vraiment tres limité. Sur PCE ca flag aussi avec les sprites?
De toute facon je vois vraiment pas ce que j'en ferais de bien utile (d'autant que de toute facon je compte pas accepter de chute de framerate donc je me doit de supporter tous les type de test de collision dans la frame, pas la peine d'essayer d'en esquiver un), ca serait gaché un sprite.

[Invité]

Ca ne fonctionne pas pour les collisions de sprite seulement pour la collision sprite 0 et bg en couleur 1,2,3. 

Ah oui, intérêt 0 alors .. 
Ou alors pour le poing d'alex si il touche des tiles par exemple .

Sur PCE ca flag aussi avec les sprites?

C'est le contraire lol, sprite 0 et les autres sprites mais pas le background ..

[upsilandre]

Apres le premier jet qui m'a permis d'avoir rapidement un aperçu concret j'ai finalement presque tout recodé car certain aspect me convenait pas trop (j'avais intriqué des truc qui pour la suite nécessitait d'etre mieux dissocié) et puis c'etait un moyen de continuer a m'exercer encore un peu sur le code 6502 et retrouver un bon niveau de trick avant de continuer, je me sens bien dérouillé maintenant.
J'ai aussi revu mes regles de syntaxe et de mise en page et ma methodologie pour partir vraiment sur un truc propre. C'est pas la partie que je préfère mais quand t'es pas programmeur de formation t'es obligé d'etre rigoureux pour remplacer les reflexes que t'as pas.
Une fois retrouvé le niveau de la demo précédente j'ai pu corriger quelques truc et en ajouter.

Deja j'ai bloqué le scrolling dans un seul sens comme c'est le cas dans Alex kidd meme si je l'ai pas fait pour ca. C'etait surtout pour dissocier le sprite d'alex du scolling. Maintenant le sprite d'alex se deplace vraiment sur l'ecran (avant il etait fixe au centre, le scrolling faisait le reste) et enclenche le scrolling seulement en mid-screen.
Ca m'a aussi obligé a borné un peu les déplacements pour pas qu'il sorte de l'ecran et a faire aussi un peu de clipping a cause du coup de poing (quand on se collait a gauche de l'ecran en frappant, le poing apparaissait a droite).

Puis je me suis attelé au plus important, le saut qui est tres particulier dans Alex kidd (surtout sa hauteur qui ne dépend pas seulement de la durée d'appuie sur le bouton mais aussi de sa velocité horizontal) et donc devoir déterminer tous ses paramètres de facon empirique. Il a fallu aussi que je borne Y pour définir un sol (a défaut d'avoir un vrai moteur de collision).

J'ai donc maintenant un controle d'alex complet et sub-pixel perfect.
Je me suis bien prit la tete a analyser la VO frame par frame, pixel par pixel, a faire des dizaines de tests en frame advance sur les 2 versions cote a cote pour bien cerner chaque parametre.
Fallait deja comprendre que la position d'alex est géré au subpixel. Un pixel = 256 subpixel. Ensuite fallait trouver les coefficients d'acceleration et de décélération qui ne sont pas les memes et qui sont encore different en l'aire et au sol et different aussi a l'horizontal et a la vertical. definir les vitesse max (ca c'est facile) et plus chiant fallait aussi déterminer quelle variable est mis a jour avant ou apres quelle autre ou quelle process car ca implique ou pas une frame de lag qui modifie légerement les resultats. Et puis l'ensemble de conditions qui doit etre réunis pour chaque mouvement.

Au final sur ce genre de phase ca prend bien plus de temps de devoir copier un jeu que de faire un truc perso (sauf si ont est pas aussi pointilleux). Mais bon j'ai une demo NES qui reproduit le comportement d'Alex kidd au pixel pret et ca fait deja plaisir, c'est a priori pas grand chose mais pour moi c'est deja un gros morceau car c'est le coeur du jeu et pas le plus simple a reproduire de facon empirique. A vrai dire je pensais pas pouvoir le faire pixel perfect.

https://drive.google.com/open?id=0B399kteofpYuT0tnd0lzZmFHcjQ


Par contre y a une liberté que j'ai prise par rapport a la VO. Si vous avez été joueur de Alex kidd vous vous souvenez sans doute qu'on pouvait s'accroupir dans l'elan d'une course pour glisser sous un bloc et ensuite se déplacer accroupi sous le bloc sauf que sur la version SMS pour s'accroupir il faut lacher la direction et appuyer sur bas ce qui n'etait pas du tout naturel dans l'elan d'une course, si tu faisais la diagonale il ne s'accroupissait pas et s'etait super désagréable en terme d'ergonomie, je détestais ca. Donc la j'ai corrigé, il est plus facile de s'accroupir pendant une course. Dites moi si vous pensez que c'est trahir le gameplay original.

[Invité]

Ca avance bien dis donc, si t'as le temps de faire une p'tite vidéo, je suis preneur ..

Fallait deja comprendre que la position d'alex est géré au subpixel. Un pixel = 256 subpixel.

Ca apporte quoi concrètement ??
J'avoue que j'ai du mal à saisir cette notion de subpixel dans les déplacements ou un collisions et surtout son intérêt, à part fonctionner comme un compteur de frame .
je suppose aussi que tu traites la physique en 8.8 ??

[upsilandre]

Ca avance bien dis donc, si t'as le temps de faire une p'tite vidéo, je suis preneur ..

rooh un emulateur NES t'as pas ca sous la main? tout l'interet est ici dans le controle.  
Je ferais une video un jour mais quand j'aurais un peu plus de chose.

Ca apporte quoi concrètement ??
J'avoue que j'ai du mal à saisir cette notion de subpixel dans les déplacements ou un collisions et surtout son intérêt, à part fonctionner comme un compteur de frame . Confused

C'est je pense plus simple tout en etant tres precis (si t'as des accélérations et decelerations a gérer).
Par exemple pour les deplacements horizontaux y a une accéleration de 64 subpixels/frame/frame et une deceleration de 32 subpixels/frame/frame (16sp et 8sp quand t'es en l'aire)
Si t'appuie pendant 3 frame vers l'avant et que tu relaches pendant 3 frames ca donne:
velocité:
frame 1> 64 subpixel/fr/fr
frame 2> +64 = 128 subpixel/fr/fr
frame 3> +64 = 192 subpixel/fr/fr
frame 4> -32 = 160 subpixel/fr/fr
frame 5> -32 = 128 subpixel/fr/fr
frame 6> -32 = 96 subpixel/fr/fr

position:
64+128+192+160+128+96= 768 subpixel = 3 pixels. C'est les retenu au dela de 256 qui alimente le MSB qui donne directement la position X en pixel.
Pas besoin de gérer des compteurs. Tu melange tout les types de velocité et d'acceleration frame par frame quelque soit le nombre de coef different et la complexité des melanges (acceleration/deceleration/sol/air...) et au final ca se limite a une addition et tu perd rien, le relicat de subpixel sert pour le deplacement suivant (comme si vraiment tu déplaçais ton sprite dans une resolution bien superieur).

je suppose aussi que tu traites la physique en 8.8 ??

Qu'est ce que tu entend par physique? les box de collision? j'en suis pas encore la
Pour moi la velocité des deplacements c'est deja de la physique, et la notion de subpixel elle vient justement du fait de gérer ca sur 16bit (le LSB pour les subpixels et le MSB pour les pixels)

[Invité]

Merci pour l'explication c'est un peu ce que j'avais compris, mais c'était pas clair dans mon esprit. 

Pour moi la velocité des deplacements c'est deja de la physique, et la notion de subpixel elle vient justement du fait de gérer ca sur 16bit (le LSB pour les subpixels et le MSB pour les pixels)

Non ok, on parlait de la même chose alors