Re: Mr ToutLeMonde et la programmation NES...

[Invité]

Il est vrai que la plupart des émulateurs sont assez précis pour les machines 8/16 bits , après la précision se dégrade assez rapidement

[upsilandre]

Avant de continuer je réfléchie comment récupérer au mieux des ressources CPU dans la routine du rouleau.
Au depart mon idée c'etait de garder ce format Kernel pour le rouleau, c'est a dire passer par cette routine qui prend entièrement le controle du CPU pendant l'affichage facon Atari VCS. En optimisant j'avais réussit a libérer 54 cycles CPU (47% de la scanline) ca me paraissait intéressant et l'idée c'etait donc de trouver un moyen d'exploiter ces cycles perdu en entrelacant donc dans le Kernel un traitement du moteur. J'avais pensé a y placer la construction de la SAT, c'est ce qui me parait le plus pertinent, d'abord la construction de la SAT c'est plutot une etape final donc ca colle plutot bien a la situation (puisque le Kernel prend le controle jusqu'au prochain nmi) et puis en traitant un attribut de la SAT par scanline (ca veut dire par exemple calculer X ou Y d'un sprite selon les coordonnées du metasprite, definir l'ID de tile selon l'etat ou la perspective, la palette selon l'etat) on arrive justement a un nombre de traitement qui correspond assez bien au nombre de boucle du Kernel (c'est a dire au nombre de scanline). En fait quand j'enlève les 12 sprites statiques qui composent la planete en fond je me retrouve avec exactement 208 attributs pour la SAT pour un Kernel qui fait justement 208 boucles. La coincidence etait intéressante. Mais ca reste quand meme compliqué de découper ce traitement (ou un autre) en une toute petite boucle vite interrompue. Ces 47% de ressources CPU disponible ne peuvent clairement pas etre exploité de facon optimal, y aura beaucoup de gachie, et je me dis que si j'arrivais a remplacer le Kernel par une simple routine d'interruption appelé a chaque scanline et a dégager ne serait ce que 10 ou 15% de ressource CPU ca serait probablement au moins aussi efficace que ces 47% car ca serait des ressources exploitable de facon libre et optimal cette fois.

Seulement le cout de l'interruption (irq, rti, sauver, restaurer, relancer l'irq du mapper, distinguer la premier irq des autres...) m'avait plutot convaincu qu'il etait peu probable de dégager meme un peu de ressource CPU. Mais en se creusant la tete , en grignotant un cycle par ci, un cycle par la (chaque cycles économisé c'est 208 cycle de gagner soit presque 2 scanlines) en trouvant des ruses... j'arrive a libérer 30 cycles malgré ce format en routine irq, soit 26% des ressources vraiment libre,  ce qui pour le coup devient bien plus intéressant que les 47% du Kernel. Ca libère 54 scanlines (soit autant que toutes les ressources deja disponible, c'est a dire le Vblank + le ciel). De quoi faire plus que juste préparer la SAT (meme si préparer la SAT ca reste toujours une tache assez lourde quand meme)

Mais une fois que j'ai fais ce boulot d'optimisation qui m'a convaincu que la solution de la routine irq etait meilleur que de passer par un kernel, je savais que le plus difficile restait a faire car il restait la question central du timing qui ne se posait plus avec le Kernel. Et la malheureusement le timing de l'irq du MMC3 rend vraiment caduc cette solution, meme si on peut bidouiller 2 choix de timing different, aucun des 2 ne permet d'avoir un timing qui correspond au besoin du rouleau. Ils sont meme placé dans la pire fenêtre possible pour mes besoin. Du coup c'etait rageant d'arriver a ce constat apres avoir constater que c'etait pourtant la meilleur solution.

Mais dans un éclaire de lucidité je me suis dit pourquoi me restreindre au mapper MMC3 de Nintendo? meme si c'est le plus rependu de tous je sais que les mappers VRC de Konami par exemple sont tres proche avec un support fin du CHR bank switching et j'avais deja constaté qu'ils étaient meme meilleur sur ce point (tout en étant sortie bien avant le MMC3 de Nintendo) et je savais aussi que l'irq du MMC3 etait vraiment spécifique au MMC3 et que donc ca serait forcement différent avec le VRC et peut etre du coup plus adapté a mes besoins avec un peu de chance? Et bingo, de ce que j'ai pu lire pour l'instant sur l'irq du VRC ca a l'air mieux que le MMC3 encore une fois et ca a l'aire de correspondre a mes besoins (on peut compter les scanlines tout en controlant le timing de l'interruption).
Reste a tester ca plus concrètement (avec peut etre d'autres mauvaise surprise) donc deja refaire toute la routine du rouleau et aussi faire la transition du MMC3 vers le VCR4. A suivre au prochain épisode (pas tout de suite car moi je bosse le week end).

[upsilandre]

Genial, le succès est total!
J'ai fais la transition du MMC3 au VRC4 et transformé mon Kernel en routine irq et l'irq du VRC4 est juste top. Non seulement je peux synchroniser l'interruption presque a ma guise ce qui règle tout les problèmes mais en plus les commandes sont mieux pensé du coup pour relancer l'irq a chaque interruption y a juste une commande a envoyer alors que sur le MMC3 il en fallait 2 (c'est un peu débile, il faut d'abord éteindre le signal irq puis réactiver le flag) du coup ca fait 4 cycles en plus d'économiser x 208 = 832 cycles juste en économisant une commande.
Moi qui au départ doutait fortement de pouvoir libérer ne serait ce que 10% de ressources CPU par scanline au final j'en ai libérer 30%. Au total le VRC m'a permit de récupérer 7100 cycles CPU (et des cycles 6502 pas des cycles Z80). C'est énorme. En plus de simplifier mon code. L'effet rouleau me coute donc 56% des ressources CPU total (au lieu de 80% avant), c'est beaucoup mais ca devient viable.

Je savais que le VRC etait bien foutu pour le CHR-ROM bank switching (La meme granularité que le MMC5 de Nintendo mais dès 1987) mais son irq enfonce le clou. Je valide 100% le mapper de Konami.

[Stef]

Ah bah en hardware Nintendo ca a toujours été des manches :p
Bon je blagouille (juste un peu) mais effectivement c'est une chance d'avoir ce VRC4 car même 30% de temps CPU avec IRQ ça vaut plus que 60% de temps dans un kernel comme tu le dis. En optimisant bien le code y'a quasi moyen de faire un vrai jeu
C'est quand même étonnant que Nintendo ne se soit pas plus inspiré du VRC4 pour faire son MMC3, peut être qu'ils ne voulaient pas devoir quoique ce soit à Konami..

[Invité]

Du coup tu vas rajouter quoi, upsilandre ?

[upsilandre]

Ah bah en hardware Nintendo ca a toujours été des manches :p
Bon je blagouille (juste un peu) mais effectivement c'est une chance d'avoir ce VRC4 car même 30% de temps CPU avec IRQ ça vaut plus que 60% de temps dans un kernel comme tu le dis. En optimisant bien le code y'a quasi moyen de faire un vrai jeu
C'est quand même étonnant que Nintendo ne se soit pas plus inspiré du VRC4 pour faire son MMC3, peut être qu'ils ne voulaient pas devoir quoique ce soit à Konami..

D'une certaine facon l'irq du VCR4 est plus basique que celle du MMC3. C'est juste un compteur de cycle CPU (la ou dans le MMC3 ils essaient d'identifier une pattern sur le bus d'adressage du PPU qui correspond au fetch des tuiles pour réellement compter les scanline effective) mais qu'ils ont couplé a un diviseur qui correspond a la duré d'une scanline (ce qui rend le diviseur un peu plus compliqué sur NES puisque c'est pas un nombre entier par scanline) mais au final ca donne quelques chose de plus fonctionnel qu'un vrai compteur de scanline.
Alors oui faut synchroniser l'initialisation de l'irq pour savoir quand on commence a compter, et bien sure ca implique de compter aussi les scanline du Vblank puisque y a pas de prise en considération de l'affichage a proprement parler. mais en vrai c'est super simple, pour la synchro suffit de placer l'initialisation de l'irq juste apres le nmi du Vblank, et ensuite au lieu d'initialiser par exemple avec 31 comme scanline je met 52 pour sauter le Vblank (en vrai faut mettre 204 car c'est pas un compteur qui décrémente mais qui incrémente). Mais au moins je peux décaler l'initialisation pour synchroniser l'irq ou je veux dans la scanline.

Alors évidement on retrouve l'incertitude lié a la nature des interruptions qui peuvent tomber au milieu d'une instruction et donc devoir attendre. Cette incertitude est ici doublé par rapport au MMC3 car s'ajoute celle de l’initialisation lié a l’interruption nmi, donc c'est le seul défaut qu'on pourrait pointer par rapport a l'irq du MMC3, ca va te donner un incertitude qui peut monter jusqu'a 20 ou 30 pixels (sur les 381 d'une scanline) mais pouvoir choisir le moment de l'irq meme si c'est dans une fenêtre un peu large , ca reste vraiment intéressant. La par exemple pour ma routine de rouleau j'ai une fenêtre de 50 pixels de larges pour le timing donc plus large de toute facon que l'incertitude de l'irq du VRC4 (ca se goupille plutot bien). Mais c'est vrai que dans d'autre cas ou l'on aurait besoin d'un timing ponctuel mais plus précis le MMC3 peut s'avérer plus pertinent.

[upsilandre]

Du coup tu vas rajouter quoi, upsilandre ?

un peu de shooting. Mais pas grand chose. Niveau gameplay ca sera tres rudimentaire, plutot du niveau galaxian, et probablement juste un seul type d'ennemi, mais ca va etre plutot pour expérimenter des idées d’intégration des sprites et de leurs mouvements dans la "fausse" perspective (pour le coup je veux pas faire comme Axelay ou les sprites ne sont pas intégré dans la perspective, ils sont géré comme dans un shmup 2D classique, mais peut etre qu'il y a rien de bon a obtenir en faisant autrement)

[Stef]

D'une certaine facon l'irq du VCR4 est plus basique que celle du MMC3. C'est juste un compteur de cycle CPU (la ou dans le MMC3 ils essaient d'identifier une pattern sur le bus d'adressage du PPU qui correspond au fetch des tuiles pour réellement compter les scanline effective) mais qu'ils ont couplé a un diviseur qui correspond a la duré d'une scanline (ce qui rend le diviseur un peu plus compliqué sur NES puisque c'est pas un nombre entier par scanline) mais au final ca donne quelques chose de plus fonctionnel qu'un vrai compteur de scanline.

Nintendo ayant les specs complètes de la NES (et donc les cycles du PPU) ils ont surement essayé d'en profiter et de faire une vraie h-int. Mais visiblement le timing de la h-int n'était pas favorable à ce que tu voulais en faire si j'ai bien compris (trop tot ou trop tardive), mais je demande si du coup tu n'aurais pas pu décaler d'un scanline ton process (en gros gérer la mise à jour du scanline N+1 à la h-int N) pour perdre moins de cycle ?

En tout cas la solution du VRC4 a l'air très bien, s'il n'y a pas de dérive d'un scanline à un autre et que tu peux choisir finement le déclenchement de la h-int alors c'est assez idéal je trouve.

D'ailleurs ça me fait penser que sur MD la gestion de la H-Int est assez galère. Tu as un registre pour dire que ton interruption se fait tout les N scanlines, ça c'est bien, mais le truc super chiant c'est que le compteur interne se recharge uniquement au scanline 0 et ensuite à chaque interruption H, du coup si tu veux une interruption sur la ligne 48 puis 160 puis 200 par ex, ben c'est un peu galère car il faut anticiper. Du coup au final tu es obligé de faire ainsi :

- V-Int: réglage de la H-int à 48 (pour avoir l'interruption au scanline 48)
- scanline 48: réglage de la prochaine H-Int à (160-96)=64 car la prochaine H-int est déjà réglée sur le scanline 96 (et oui le compteur a déjà été rechargé).
- scanline 96: réglage de la prochaine H-Int à 32 (qui sera donc prise en compte à la ligne 160)
- scanline 160: réglage de la prochaine H-Int à 8 (qui sera prise en compte à la ligne 192)
- scanline 192: on peut remettre à 48 pour anticiper la première interruption (mais faisable aussi en V-Int) et aussi pour éviter d'avoir trop d'interruptions inutiles sur la fin de la frame
- scanline 200: rien à faire ici (de toute façon ça serait pris en compte qu'à la prochaine interruption)

Et quand on a un schéma un peu plus complexe ça peut vite devenir beaucoup plus compliqué.
C'est trop dommage car déjà on se triture un peu la tête mais en plus on doit faire quelques interruptions inutiles (ici 5 interruptions H à la place des 3 nécessaires à la base), tout ça était évitable si la compteur était ré-écrit en même temps qu'on écrit dans le registre.

[Tryphon]

Ah ça c'est intéressant (j'ai besoin de faire un changement de palette sur le tableau 5-2 de Shinobi).

[upsilandre]

mais je demande si du coup tu n'aurais pas pu décaler d'un scanline ton process (en gros gérer la mise à jour du scanline N+1 à la h-int N) pour perdre moins de cycle ?

J'ai essayé mais y a aucun timing qui va. Meme si j'applique le résultat précomputé N-1 dès le début de l’interruption N c'est deja trop tard de quelques cycles donc pas d'autre choix que de laisser passer toute la scanline. L'irq est au pire moment.

En tout cas la solution du VRC4 a l'air très bien, s'il n'y a pas de dérive d'un scanline à un autre et que tu peux choisir finement le déclenchement de la h-int alors c'est assez idéal je trouve.

nan y a pas de derive, le diviseur compte 114,114 puis 113 (pour faire 113.66). Y a pas plus de dérive qu'avec le MMC3 mais moins de précision du fait que l'interruption est dépendante elle meme d'une autre interruption initial (nmi). Y a aussi un systeme de flag assez bien foutu.

D'ailleurs ça me fait penser que sur MD la gestion de la H-Int est assez galère. Tu as un registre pour dire que ton interruption se fait tout les N scanlines, ça c'est bien, mais le truc super chiant c'est que le compteur interne se recharge uniquement au scanline 0 et ensuite à chaque interruption H, du coup si tu veux une interruption sur la ligne 48 puis 160 puis 200 par ex, ben c'est un peu galère car il faut anticiper. Du coup au final tu es obligé de faire ainsi :

- V-Int: réglage de la H-int à 48 (pour avoir l'interruption au scanline 48)
- scanline 48: réglage de la prochaine H-Int à (160-96)=64 car la prochaine H-int est déjà réglée sur le scanline 96 (et oui le compteur a déjà été rechargé).
- scanline 96: réglage de la prochaine H-Int à 32 (qui sera donc prise en compte à la ligne 160)
- scanline 160: réglage de la prochaine H-Int à 8 (qui sera prise en compte à la ligne 192)
- scanline 192: on peut remettre à 48 pour anticiper la première interruption (mais faisable aussi en V-Int) et aussi pour éviter d'avoir trop d'interruptions inutiles sur la fin de la frame
- scanline 200: rien à faire ici (de toute façon ça serait pris en compte qu'à la prochaine interruption)

Ca me parait plutot etre un fonctionnement normal. Une fois que t'as configurer le H-int sur 48 et lancer le comptage qu'est ce qui empêche de remodifier tout de suite le registre reload du h-int pour le configurer sur 112 (48 + 112 = 160) et qu'il soit donc bien configurer quand viendra la prochaine H-int? et ensuite a la h-int 48 tu charge 40 dans le registre reload (pour avoir  160 + 40 = 200).
Parce que la moi c'est ce que je fais. J'ai une premier h-int a la scanline 31 puis ensuite a 32,33,34,35,36.... Donc je charge d'abord le registre reload avec 31 (je simplifie), puis je set l'irq et son compteur et tout de suite apres je modifie a nouveau le registre reload avec 1 et donc a la scanline 31 il va se reload avec 1 et donc faire une interruption a chaque ligne.

edit: oui nan c'est vrai que dans ton cas c'est un vrai compteur de scanline indexé sur l'affichage, tu peux pas faire ca. C'est pour ca que le VRC4 avec son simple compteur de cycle CPU qu'on peut initialiser quand on veut et coupler a un diviseur de la taille d'une scanline c'est un bon combo. Tu peux du coup préparer le timing de la prochaine IRQ mais aussi de la suivante parce que tu lance le comptage au moment de l'initialisation.

[Stef]

J'ai essayé mais y a aucun timing qui va. Meme si j'applique le résultat précomputé N-1 dès le début de l’interruption N c'est deja trop tard de quelques cycles donc pas d'autre choix que de laisser passer toute la scanline. L'irq est au pire moment.

Ah ok dommage, elle doit être vraiment mal placée, pas de chance :-/

Ca me parait plutot etre un fonctionnement normal. Une fois que t'as configurer le H-int sur 48 et lancer le comptage qu'est ce qui empêche de remodifier tout de suite le registre reload du h-int pour le configurer sur 112 (48 + 112 = 160) et qu'il soit donc bien configurer quand viendra la prochaine H-int? et ensuite a la h-int 48 tu charge 40 dans le registre reload (pour avoir  160 + 40 = 200).
Parce que la moi c'est ce que je fais. J'ai une premier h-int a la scanline 31 puis ensuite a 32,33,34,35,36.... Donc je charge d'abord le registre reload avec 31 (je simplifie), puis je set l'irq et son compteur et tout de suite apres je modifie a nouveau le registre reload avec 1 et donc a la scanline 31 il va se reload avec 1 et donc faire une interruption a chaque ligne.

Non justement tu n'as pas moyen de toucher au compteur en lui-même qui est reloadé *uniquement* au début de la frame et ensuite à chaque interruption H. Le seul truc que tu peux modifier c'est le registre qui indique la valeur de reload en quelque sorte. Comme j'expliquais, si le compteur interne de scanline était rechargé au moment même où tu écris ce registre ça sera parfait, mais là ce n'est pas le cas :-/

[upsilandre]

Oui je vois ca :) (voir plus haut).
La solution du VRC4 me parait d'autant plus séduisante et simple.

[upsilandre]

Voila j'ai terminé la démo Axelay  
https://www.gamopat-forum.com/t92458p660-nes-en-vrac

https://drive.google.com/open?id=1O8QpTlegVoxHFxteGTNu9C88_wV44G9H
Ca été un peu long car j'ai fais ca un peu plus en dilettante que d'habitude mais du coup en diluant le projet j'en avais un peu marre sur la fin heureusement je suis contant du résultat.

[upsilandre]

Je vous met quand meme un gif


Bien sur on peut bouger, shooter, c'est plus rigolo de tester la ROM et ca rend mieux

[Tryphon]

C'te classe

Au passage, c'est quoi la table de hscroll ?

[upsilandre]

tu veux dire la table pour le Vscroll et l'effet rouleau?
C'est une table tangente sur je ne sais plus quelle amplitude. J'ai cherché de facon empirique mais ca reproduit tres bien le rouleau de Axelay.

[Tryphon]

Oui, c'est ce que je voulais dire.

Une tangente ? Bizarre.

Est ce que l'étirement vertical est le même que pour une perspective (sauf que dans une perspective il y aurait aussi un étirement horizontal) ?

[upsilandre]

Je pense pas, le scrolling Axelay n'essaie pas de reproduire une vrai perspective (meme en soustrayant le scaling horizontal) et moi j'ai juste essayé de reproduire précisément le scrolling Axelay et empiriquement quand j'ai essayé avec une table tangente ca a parfaitement matché donc voila .

[Invité]

Finalement pour un truc où tu n'avais plus de CPU, y'a pas mal de choses à l'écran .
C'est très beau, et le swap de tiles en plus est ultra classe 

[upsilandre]

En fait comme ma vague d'ennemis est simpliste et prédictible, et que j'ai un Y order des ennemis (qui est quasi automatique vu la simplicité de la vague justement) pour pouvoir les afficher selon la distance du coup je pourrais réduire drastiquement le nombre de collision connaissant l'ordre vertical des ennemis. J'ai pas besoin en vrai de faire les 150 test de collision, je pourais libérer plein de ressource CPU, mais du coup le moteur de collision serait moins généraliste et juste calibré pour la démo, et je serais pas quoi faire de ces ressources CPU vu que je veux pas faire un jeu (et ca serait de toute facon moins possible si faut se limiter a des vagues aussi prédictible). Et puis je suis contant d'avoir placé 150 collisions donc je vais les laisser je pense.

[upsilandre]

Bon finalement j'ai pas pu m'empecher d'optimiser vite fais le nombre de test de collision dans ma démo et je suis passé de 150 tests a 20 tests (pour le meme résultat) du coup j'ai libéré encore des milliers de cycle CPU.
La demo en elle meme en charge maximum prend 29% du CPU. La routine pour l'effet rouleau prend 56.4%. Me reste du coup 14.6%. Je pourrais par exemple ajouter une musique mais bon faut que j'arrete. J'ai acheté Sekiro y a une semaine et j'ai toujours pas joué.

[Fabf]

Moi je dis qu'il y a moyen de gagner la première place du concours BEEP tellement c’est monstrueux.
Faut être un grand malade pour seulement imaginer ça sur une NES.
Alors le faire j'en parle même pas 

[upsilandre]

Je trouve ca curieux justement que personne ne l'ai fait avant.
A l'époque on pouvait mais ca fait tres longtemps maintenant que le PPU est bien documenté.

[Stef]

Il y a eu des démos NES qui faisaient du shearing vertical mais reproduire le scroll type "axelay" effectivement c'est une première, et pour une première on peut dire que tu n'as pas fait les choses à moitié

[upsilandre]

J'ai passé un peu trop de temps sur "l'habillage" a mon gout mais on va dire que ca a payé