Re: [ NES ] Alex Kidd in Miracle World

[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 

[upsilandre]

Oui parce que les collisions j'ai pas encore réfléchi, je vois pas trop l'interet de gérer les collisions de box au subpixel mais peut etre que ca m'apparaîtra au moment venu mais je doute.

La prochaine fois je m'occupe soit des collisions avec le décor soit du clipping de sprite (alex peut intégralement sortie du bord superieur de l'ecran, c'est chiant).
Je pense plutot les collisions avec le décor histoire de changer un peu mais je vais avoir moins de temps les prochaines semaines donc je sais pas quand ca sera.

[Invité]

En tout cas je vais suivre ça de près,les codeurs 65xx ici, ça cours pas les rues 

Je pense plutot les collisions avec le décor histoire de changer un peu mais je vais avoir moins de temps les prochaines semaines donc je sais pas quand ca sera.

C'est assez chiant à faire,mais faire une bonne routine ça peut toujours servir pour d'autres projets .

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.

J'en récupérerai un pour tester, ce serra mieux qu'une simple vidéo je pense .

[vingazole]

C'était rigolo de vous voir parler de la même chose avec des noms différents ("subpixels" et virgule fixe 8.8).

[Invité]

C'était rigolo de vous voir parler de la même chose avec des noms différents ("subpixels" et virgule fixe 8.8).

Non mais pour moi il est là le problème, même quand tu cherches des réponses, t'as plusieurs dénominations pour dire la même chose .
Pour ma part j'ai vu les 2, mais bien plus en virgule fixe,mais le fait est que ça m'a mis de la confusion pour bien comprendre  .

[upsilandre]

Oui c'est ca, c'est utiliser un nombre a virgule fixe pour les coordonnées
Du coup t'as une précision au subpixel.

[upsilandre]

Sinon pour revenir au deplacement voila la solution des sauts de Alex:
- l'impulsion de saut dure entre 1 et 21 frames max (selon la durée de pression)
- y a pas de phase d'accélération, la vélocité est tout de suite a 2 pixels/frame (qui est aussi la vélocité max des deplacement horizontaux)
- au bout de 21 frames max le jump s'arrete et c'est l'acceleration de la gravité qui prend le relais (64 subpixels/frame/frame) et qui va te ralentir puis ensuite inverser ta velocité pour te faire retomber avec une vitesse max de chute de 4 pixels/frame.
- sauf qu'a ces 2 pixels/frames de velocité vertical initial s'ajoute aussi un quart de ta velocité horizontal (soit max 0.5 pixels/frames supplémentaire) et cela pour chacune des 21 frames du saut (pendant laquel ta velocité horizontal peu changer et influencer la hauteur du saut). C'est ce surplus qui va te permettre de gagner quelques pixels de hauteur et de franchir une metatile de plus qu'a l'arret (mais avec un seul pixel de marge donc toujours difficile a faire comme saut).
- Les deplacements horizontaux en l'aire sont difficile comme si t'avais 4x plus d'inertie (l'accélération et deceleration sont 4 fois plus faible)

Ce qu'il faut donc retenir c'est que pour faire le saut de hauteur maximum il faut d'abord avancer pendant 8 frames (pour atteindre la velocité horizontal maximum) avant de sauter (et continuer d'avancer en l'aire)

Et sur le deplacement horizontal au sol y a une frame de lag sur l'acceleration quand tu passes de l'etat de repos a celui de marche (mais pas par exemple si tu lache la direction quelques frames avec donc une phase de deceleration et qu'ensuite tu reprend ta marche ou part dans le sens inverse, la y a pas de frame de lag). C'est l'un des derniers truc qu'il a fallu que je repère dans le jeu original pour pouvoir etre pixel perfect.

[Invité]

La démo s'embellie !!
Bravo, c'est toujours émouvant de voir ces petits pixels s'animer au grés du code !
De plus, tes explications techniques sont claires et font de ce post une mine d'or technique pour les courageux qui cotoient l'assembleur.

Bon courage pour la suite !

[upsilandre]

merci
Je suis toujours en phase d'apprentissage. Je le fais pour ca, pour apprendre des truc en faisant.

J'ai jeté un oeil en mode debug.
Si je compte pas la routine qui transforme ma liste de metasprite en table de sprite pour le PPU et qui est de loin la routine la plus lourde (mais qui sera sans doute amener a evoluer si je doit y ajouter du clipping), tous le reste pour l'instant me prend 4 scanlines d'execution.
Les choses serieuses commenceront avec les grosses boucles de test tel les collisions de sprite.

[Invité]

Tu as déjà fait un gros boulot mine de rien .

[vingazole]

Les choses serieuses commenceront avec les grosses boucles de test tel les collisions de sprite.

Ce topic risque de t'intéresser : https://www.gamopat-forum.com/t66305-meilleurs-algo-d-un-test-par-bouding-box 

[upsilandre]

a oui ca peut aider. Des fois je me dis que je devrais effectivement regarder sur les forums mais c'est vrai que j'aime bien chercher moi meme avant, c'est ca qui m'amuse plus que l'idée de produire un jeu. Mais a la fin faut quand meme jeter un oeil sur ce qu'il se fait sinon tu rates des choses.
Le bounding a priori c'est assez simple, ce qui est amusant effectivement c'est l'optimisation je pense.

Pour les collisions avec le décor je sais pas trop quelle est la pratique la plus courante sur 8bit ni sur Alex mais j'imaginais juste tester directement l'ID des tiles dans la tilemap en VRAM (et en classant les tiles dans le tileset de facon a avoir toute celle qui sont des obstacle avec une ID inferieur a 128 et toutes celle qui ne sont pas des obstacles superieur a 128 pour avoir un test tres simple avec juste un bpl ou bmi et hop). Faut juste bien préparer le truc en amont car sur NES je serais obligé de le faire pendant le Vblank qui est tres court. (jamais compris pourquoi ils ont fait un vblank si court sur NES qui justement n'a acces a la VRAM que pendant le vBlank)

Sinon je pourrais avoir une table de collision en RAM avec un bit par metatile c'est pas trop gros mais ca me parait plus chiant a gérer et dans le cas d'Alex kidd je vois pas ce que ca m'apporterait de plus (plutot des contraintes).

[Invité]

Pour les collisions avec le décor je sais pas trop quelle est la pratique la plus courante sur 8bit ni sur Alex mais j'imaginais juste tester directement l'ID des tiles dans la tilemap en VRAM
(et en classant les tiles dans le tileset de facon a avoir toute celle qui sont des obstacle avec une ID inferieur a 128 et toutes celle qui ne sont pas des obstacles superieur a 128 pour avoir un test tres simple avec juste un bpl ou bmi et hop)

C'est ce que je fais sur PCE,sinon bcp utilisent un buffer en RAM pour ça .

Sinon je pourrais avoir une table de collision en RAM avec un bit par metatile

1 bit ça va te limiter à 2 options seulement !!, 2/3 bits serraient pas mal .

[upsilandre]

,sinon bcp utilisent un buffer en RAM pour ça .

Ca devient utile je pense si tu veux associer d'autres informations a tes tiles qui ne soit pas lié a leur apparence (ou si des tiles de meme apparence ont des fonctions differentes, par exemple ouvrir un passage secret en détruisant une tile qui normalement est un obstacle) donc j'imagine effectivement que pas mal de jeu ont besoin d'une table de collision mais dans Alex kidd a priori ca me servirait a rien.

[Invité]

Ca devient utile je pense si tu veux associer d'autres informations a tes tiles qui ne soit pas lié a leur apparence 

Oui, car dans le cas d'alex tu as aussi des tiles destructibles et d'autres non par exemple .
Donc il faudra soit un arrangement en VRAM par type,soit l'associer avec un buffer .

[upsilandre]

Oui, car dans le cas d'alex tu as aussi des tiles destructibles et d'autres non par exemple .

oui mais ce ne sont pas les memes donc l'ID des tiles est une information suffisante a priori.

[Invité]

oui mais ce ne sont pas les memes donc l'ID des tiles est une information suffisante a priori.

Faut juste être sur que des mêmes tiles aient la même propriété alors .
Si c'est le cas d'alex c'est du tout bon pour l'organisation par type en VRAM .

[upsilandre]

Y a pas de probleme de ce point de vue la.
Le gros probleme c'est que je suis pas sur SMS et du coup faire du test de collision avec la tilemap ca va m'ajouter une frame de lag!
Ca serait un jeu perso ca me generait pas (on a bien des TV aujourd'hui qui parfois t'ajoute 5 ou 6 frames de lag) mais la je vais pas briser la précision que j'ai instauré. Donc en fait c'est ca l'autre probleme de pas utiliser de buffer.

Alors je pourais avoir en RAM un mini-bufffer miroir de la tilemap qui represente les tile aux environ de alex et que je mettrais a jour partiellement selon les déplacement mais a partir du moment ou faut passer par un buffer intermediaire en RAM plutot que taper directement dans la VRAM autant que ce soit un buffer de metatile (y a pas besoin d'une precision a la tile) et qu'il soit complet pour servir aussi pour les ennemis. En plus les metatiles te permettent de te dissocier de l'apparence (2 metatiles de meme apparence peuvent avoir une ID differente) donc ouvre plus de possibilité meme si j'en ai pas besoin pour l'instant. Et puis je peux peut etre directement faire la premiere phase de décompression du background dedans (que je pense faire sous un format metatile + rle).  Ca doit pouvoir etre utile d'avoir une metatilemap en RAM.

Et puis ta raison il me faudra plus de 1bit parce que le buffer va pas servir juste pour les test de collision d'obstacle, faut aussi que je puisse identifier si j'attrape un sac de pognon ou tester les punch quand je casse un bloc, en testant directement la VRAM ca posait pas de probleme mais avec un buffer ram 1bit ca suffira pas donc autant utiliser directement l'ID des metatiles sur un octet ca simplifie les test.
De toute facon je sais pas quoi faire de toute ma RAM, je peux gacher une page pour ca si ca permet d'etre efficace et d'ouvrir plus de possibilité, si j'ai besoin de place en RAM je pourrais toujours optimisé cette aspect.
C'est dommage car j'aimais bien l'idée de tester directement la VRAM, c'etait simple et ca me permettait de pouvoir le faire des tests rapidement avec alex alors que la je vais etre obligé de d'abord m'occuper de definir un format de background.

Mais tu vois c'est un bon exemple que c'est en "faisant" que tu réalise mieux les contraintes, ici de pas avoir acces a la VRAM c'est vraiment chiant. C'est exactement pour ca que je fais cette exercice de style.

[Invité]

De toute facon je sais pas quoi faire de toute ma RAM

Si tu mets seulement un écran complet (en metatile) tes besoins en RAM seront leger, si en plus tu codes ça sur 4 bits (suffisant je pense, ça donne 16 états possibles), ça divise encore /2 .
Faudra juste mettre à jour le buffer en fonction du scrolling .

C'est dommage car j'aimais bien l'idée de tester directement la VRAM, c'etait simple et ca me permettait de pouvoir le faire des tests rapidement avec alex alors que la je vais etre obligé de d'abord m'occuper de definir un format de background.

J'ai testé ça sur mon flappy SGX, même en mode bourrin,je teste toutes les tiles du sprites de flappy (32x16 pixels,soit 8 tiles à tester) c'est très rapide, le plus consommateur en CPU c'est la conversion des coordonnées X/Y en pixels de ton sprites en coordonnées de tiles .

Mais tu vois c'est un bon exemple que c'est en "faisant" que tu réalise mieux les contraintes, ici de pas avoir acces a la VRAM c'est vraiment chiant. C'est exactement pour ca que je fais cette exercice de style.

C'est clair   
Et puis arriver à trouver une solution efficace quand à la base c'est pas facile, c'est le pied 

[upsilandre]

Si tu mets seulement un écran complet (en metatile) tes besoins en RAM seront leger, si en plus tu codes ça sur 4 bits (suffisant je pense, ça donne 16 états possibles), ça divise encore /2 .

Meme en 4bit ca vaut pas le coup je pense, autant utiliser directement l'ID des metatiles. Avec un octet ca prend toujours moins d'une page de RAM de toute facon donc c'est nickel tu boucles ca sur une page complete (pour un ecran 256x256) et ca cycle tout seul pour la mise a jour du scrolling.

Un format compressé en nibble 4bit en plus de rajouter un peu de charge CPU lors des test ca veut dire aussi stocker une table supplémentaire en ROM au lieu d'utiliser directement celle des metatiles ou alors la construire a la volé mais je veux pas chargé inutilement le CPU. Je suis a peu pret sure qu'utiliser directement le format metatile ca a plein d'avantage.
La priorité c'est l’économie de CPU puis ensuite l'economie de ROM. La RAM la seule préoccupation c'est d'en avoir assez pas d'en faire l'economie   .

Et puis finalement je n'utiliserais pas de RLE , j'ai calculé le level 1 de Alex kidd c'est 12 screens SMS soit 2.25Ko de metatilemap au total, ca vaut pas le coup (meme si je faisais d'autre level ce qui n'est pas prévu) et en plus je veux garder ouvert la possibilité de pouvoir faire du backtracking qui est la seconde chose qui m’embetait dans Alex kidd, ca cassait un peu le voyage (et pour ca vaut mieux eviter le RLE).
Donc a la limite j'aurais presque pu faire les tests de collision directement dans la metatilemap en ROM et seulement mémoriser en RAM l'etat de certain bloc destructibles mais ca serait valable si seulement y avait peu d'element destructible dans le décor, y en a trop ici (les bloc de pierre, les bloc bonus et aussi les sacs de pognon)
Non un buffer RAM qui stocke la metatilemap actuellement a l'ecran et qui boucle sur une page de RAM me parait le bon choix.

[Invité]

Non un buffer RAM qui stocke la metatilemap actuellement a l'ecran et qui boucle sur une page de RAM me parait le bon choix.

Oui si tu arrive à faire en sorte que ça tienne comme ça, effectivement c'est le meilleur choix, tu as un ring buffer dispo gratuitement .

[upsilandre]

Je réfléchissais au backtracking et ca m'a insipré  

Si je devais l'ajouter je pensais a le faire de manière basique en permettant de revenir en arriere mais en faisant alors disparaitre les ennemis et autres bonus, bloc destructibles car sinon faut mémoriser l'etat de tous les elements du level entier.
L'interet d'empecher le backtracking dans des jeux comme Alex ou Mario c'est justement d'economiser de la RAM et d'ouvrir plus de possibilité de compression du background.

Maintenant imaginons ma metatilmap en ROM dont les 32 premieres ID servent pour les blocs inaltérables (les 16 premiers pour les obstacles et les 16 autres pour les elements cosmetique) et ensuite les 224 ID restant je les utilise non pas pour pointer directement un skin de metatile mais pour pointer un objet unique dans une table en RAM, juste un octet par objet qui contiendrait le pointeur vers son skin de metatile + son etat.
J'ai compté sur le level 1 y a juste 131 bloc altérables qui serait donc chacun un objet unique (pour les blocs bonus je peux meme y stocker ce que contient le bloc, ca économise aussi ca) donc ca rentre.

Du coup au lieu d'utiliser une page de RAM pour faire les collisions je fais les collisions directement en ROM et j'utilise cette page de RAM (c'est meme seulement une demi page ici) plutot pour mémoriser l'etat des bloc alterable.
Du coup non seulement j'utilise moins de RAM mais en plus j'ai en RAM l'etat du level au complet et je peux faire un vrai backtraking!!
En plus ca me permet d'exploiter a fond ma metatilemap (et de rendre le RLE encore moins utile car il compresserait encore moins bien ce genre de metatile)

Ca fait beaucoup d'avantages.
J'aime bien en fait l'idée de transformer un inconvénient (pas d'acces a la VRAM donc obligation d'utiliser un buffer en RAM) en avantage (je fais mes test de collision dans la ROM du coup j'ai besoin d'avoir en RAM l'etat des bloc alterable et du coup je peux faire un vrai backtracking que ne propose pas la VO avec 4x plus de RAM) ca me plait beaucoup.

[Invité]

Ouf ça fait bcp de choses à digérer lol ..
Bon j'attends de voir ça, ça s'annonce prometteur .

[upsilandre]

Faudra pas etre pressé...
Et puis du coup la prochaine etape sera deja de mettre mon background au format metatile, donc une metatilmap et un metatilset a transformer a la volé en tilemap (au format un peu chiant de la NES ou les couleurs des tiles sont dans une map a part par bloc de 32x32). Pour l'instant mon background de test c'est juste une tilemap que je copie direct en VRAM donc faut deja passer cette etape.

Vous avez compris que je veux rester tres fidèle a l'orignal mais ajouter le backtracking ca rend le défie technique vraiment intéressant (en plus de repondre a une frustration personnel), ca me plait comme idée.

[upsilandre]

En plus sur NES le backtracking n'ajoute pas de stress supplémentaire sur la mise a jour de la tilemap car sur NES la tilemap en VRAM fait 2 screens, 256x480 (ou 512x240) au lieu de seulement 256x224 sur SMS donc meme avec une resolution verticale sensiblement superieur a la SMS y a beaucoup de marge pour bufferiser dans les 2 sens (ce qui n'est pas superflu sur NES car il est préférable de bosser sur des bloc 32x32 pour la mise a jour de la tilemap alors que sur SMS t'as vraiment une granularité 8x8 plus pratique)

[Stef]

Très interessant à lire comme d'hab :)
Faut quand même être un sacré furieux pour faire du reverse engineering de la physique d'un jeu en l'analysant frame par frame ! Limite je pense que tu aurais eu plus vite fait à le faire en parcourant le code desassemblé dans un émulateur :p  D'ailleurs en parlant de la physique, j'ai l'impression qu'Alex a un début d'accélération un poil trop rapide juste après s'être retourné... mais bon c'est peut être juste moi.

Sinon concernant le bit de collision de sprite, je pense qu'effectivement c'est une fonctionnalité quasi gratuite car le PPU doit forcément avoir l'information au moment de rasterizer les sprites (enfin ça dépend de la méthode de rendu mais ça parait très probable quand même)... pour dire ce bit de collision existe aussi sur megadrive (il teste la collision entre sprites) mais il est totalement inutile effectivement ^^ De mémoire seuls 3 jeux l'utilisent dont 2 pour des raisons obscures et le seul jeu qui l'utilise réellement pour calculer la collision entre 2 sprites est probablement le pire jeu Megadrive (Barbie super model).

Sinon tu parlais d'utiliser la VRAM pour lire directement la tilemap et gérer les collisions, perso je pense que ce n'est une super solution car ce n'est pas du tout flexible: tu vas uniquement pourvoir te baser sur l'id du tile pour identifier son type et surtout tu restes sur le format tilemap hardware qui n'est pas forcément optimal comparé au level design du jeu (meta-tilemap). Sur pas mal de systèmes tu lis rarement la VRAM car son accés n'est pas des plus faciles (accés par port) et au final tu te retrouves toujours avec une copie en RAM du tilemap ou metatilemap :)

[upsilandre]

Faut quand même être un sacré furieux pour faire du reverse engineering de la physique d'un jeu en l'analysant frame par frame ! Limite je pense que tu aurais eu plus vite fait à le faire en parcourant le code desassemblé dans un émulateur :p

J'y avais pensé avant de commencer mais sur NES encore j'aurais peut etre pu (meme si ca reste compliqué, meme mon propre code si je le voyais dans un debugger ca me prendrait un sacré temps avant de déchiffrer la partie physique des deplacements) mais sur Master System j'ai aucune connaissance du Z80 ni des outils.
Ce qui ma sauvé c'est que j'ai eu dès le depart les bonnes intuitions et du coup j'ai vu assez rapidement que ca collait. Si la gestion des deplacements avait ete plus tordu je me serais cassé les dents mais la finalement la base etait assez logique et intuitive, ce qui etait long c'etait le reglage des petits details, faire la meme chose sur le code désassembler m'aurait prit plus de temps voir beaucoup plus.

D'ailleurs en parlant de la physique, j'ai l'impression qu'Alex a un début d'accélération un poil trop rapide juste après s'être retourné... mais bon c'est peut être juste moi.

J'ai encore verifié mais non c'est bien pixel perfect. D'ailleurs c'est assez émouvant a chaque fois que j'execute une série d'input divers (quelques dizaines) frame par frame sur la version SMS et que je fais de meme sur ma version et que le sprite d'alex termine sur le meme pixel c'est beaucoup de joie .

Sinon tu parlais d'utiliser la VRAM pour lire directement la tilemap et gérer les collisions, perso je pense que ce n'est une super solution car ce n'est pas du tout flexible: tu vas uniquement pourvoir te baser sur l'id du tile pour identifier son type et surtout tu restes sur le format tilemap hardware qui n'est pas forcément optimal comparé au level design du jeu (meta-tilemap). Sur pas mal de systèmes tu lis rarement la VRAM car son accés n'est pas des plus faciles (accés par port) et au final tu te retrouves toujours avec une copie en RAM du tilemap ou metatilemap :)

Ca doit quand meme etre bien pratique sur des systemes comme la Coleco ou t'as seulement 1Ko de RAM et un acces continu a la VRAM, faut vraiment que ce soit justifié pour faire autrement sur ce genre de machine je pense.
De toute facon la j'ai prevu de le faire directement en ROM.

[Stef]

J'ai encore verifié mais non c'est bien pixel perfect. D'ailleurs c'est assez émouvant a chaque fois que j'execute une série d'input divers (quelques dizaines) frame par frame sur la version SMS et que je fais de meme sur ma version et que le sprite d'alex termine sur le meme pixel c'est beaucoup de joie    .

Dans ce cas vraiment bravo ! Faire ça pixel perfect à l'oeil c'est vraiment balaise !

Ca doit quand meme etre bien pratique sur des systemes comme la Coleco ou t'as seulement 1Ko de RAM et un acces continu a la VRAM, faut vraiment que ce soit justifié pour faire autrement sur ce genre de machine je pense.
De toute facon la j'ai prevu de le faire directement en ROM.

Effectivement si tu as un accés contigu à la VRAM et si peu de RAM centrale, tu n'as pas beaucoup de choix :-/
Là tu fais un mix ROM / RAM si j'ai bien compris ?

[upsilandre]

Oui c'est ca, ROM + RAM (quand je m'y mettrais, probablement pas dans les semaines prochaines)

[upsilandre]

Je regardais un peu a la loupe super mario pour comparer et on voit que c'est quand meme la source d'inspiration.
On retrouve les memes regles de velocité, acceleration et deceleration, la velocité horizontal qui s'ajoute a la velocité vertical pour les saut, le fait de pouvoir utiliser l'inertie en etant accroupi pour faire une glissade sous un bloc. Alex kidd reprend finalement les regles deja défini.

Ce qui change par rapport a mario c'est que alex a une inertie 4 fois plus faible au sol qu'en l'aire donc il est plutot tres réactif au sol alors que mario a la meme inertie tres forte que ce soit au sol et en l'aire (l'inertie au sol de mario est incroyablement elevé, ca change pas mal le gameplay). Mais du coup sur Alex kidd la forte difference d'inertie entre le sol et l'aire est alors assez marquante.

Alex a aussi une vitesse max superieur de 33% (2 pixels/frame vs 1.5 pixels/frame) atteinte en seulement 8 frames au lieu de dizaines sur mario. il est plus speed.

L'impacte de la velocité horizontal sur la hauteur du saut est aussi bien plus elevé avec Alex dont le saut passent de 51 pixels de haut a 66 pixels de haut (+29%) selon la velocité horizontal ce qui revient a franchir un palier de metatile supplémentaire ( on passe du pallier 48 au pallier 64)
Alors que dans mario le gain te sert juste a augmenter un peu la marge de securité, ca passe de 66 pixels a 72 pixels (+9%) donc on reste bloqué au pallier 64 mais avec plus de marge ce qui n'est donc pas la meme approche.

[pckid]

J adore l avancement de ce projet