Re: Mr ToutLeMonde et la programmation NES...

[Invité]

franchement je trouve cette notation de label purement dégueulasse, ça rend le code vraiment illisible et difficile à suivre .

[brokestudio]

Dans la pratique j'utilise rarement les labels anonymes "imbriqués".
Et je met ":" sur une ligne seule et pas avant une instruction (comme j'ai fait au dessus) pour aérer le code et pour que ça soit plus lisible.
Après, chacun ses habitudes et ses préférences.

[Invité]

Après, chacun ses habitudes et ses préférences.

c'est sur, cependant ça devient indigeste  si tu postes par exemple ton code comme exemple pour ceux qui lisent derrière, c'est dommage .
Pareil pour le code en vrac non commenté .

C'est surtout ce genre de saut *+4 qui est indigeste .

[vincent2105]

De mon coté, pour mon projectile, je suis passé sur une vitesse 16 bits, y'a pas photo, c'est bien plus fluide. Pour ce qui est d'avoir une vitesse linéaire quelque soit la direction, c'est vrai que c'est une autre paire de manche, mais au moins maintenant, j'ai plus d'à-coup latéraux, avant on voyait nettement que le projectile se déportait de facon saccadée. Mieux, j'arrive à taper dans tous les angles apparemment :)

[vincent2105]

Je vais tâcher de faire au mieux pour cette histoire de vitesse linéaire, mais y'a déjà un nouveau truc que je voudrais tenter ce sont les trajectoires circulaires et compagnie. Je vais y réfléchir, ça à l'air sympa.
Et voila une p'tite vidéo, je m'en lasse pas :p avant je ne couvrais que 90°, maintenant 360°.

[Invité]

C'est pas mal et très précis, mais la vitesse varie encore .

[vincent2105]

Je pense que je peux lisser les vitesses, mais depuis que je suis passé avec une vitesse sur 16bits, ça me complique un peu la tache, c'est moins lisible/pratique. J'avais l'intention de voir quel etait l'écart entre les tirs les plus lents et les plus rapides. Du coup, je pourrais determiner un palier à atteindre toutes les 10 frames par exemple et  bloquer le déplacement des tirs trop rapides sur une frame quand cela serait nécessaire ou "rajouter" un déplacement à un tir trop lent.

[brokestudio]

L'idéal c'est vraiment d'avoir une table avec tes vitesses pré-calculées.
Tu index avec ton angle et tu initialises la vitesse avec la valeur trouvée.
Enfin si tu as utilisé la solution avec les angles bien entendu :)

[vincent2105]

Oui, je vois :) 
Pour l'instant je reste sur ma méthode. J'ai ajusté une boucle et, avec une vitesse élevée (4 à 7 px par frame) le résultat me convient -même si c'est proportionnel à ce que j'avais avant- et de toute facon, au mieux j'aurais quand même eu des écarts de vitesse de l'ordre de 25%, et ça me couterait des cycles en plus. 
En parlant de cycles, j'ai 89 instructions pour déclencher un tir soit environ 290 cycles (en prenant une moyenne de 3.3 cycles par instruction). 
C'est plus du double de ta solution, et ma vitesse n'est pas linéaire, mais j'économise les tables et leur éventuel bankswitch, et j'ai une précision impeccable, ca peut me donner des idées de gameplay.
Et puis : "c'est moi qui l'ai fait !",  c'est surement pour ça que je suis pas très objectif 

[Invité]

En parlant de cycles, j'ai 89 instructions pour déclencher un tir soit environ 290 cycles (en prenant une moyenne de 3.3 cycles par instruction). 

Comme le dit brakestudio, c'est l'avantage des tables, surtout sur 65xxx où il est performant à indexer des tableaux .
Ca prend de la place, mais le gain en vaut la chandelle en général,après comme tu le dis toi même, c'est ta routine, donc sois en fier 

[upsilandre]

Je continu ma transition vers Mesen, j'ai adapté pas mal de mes script Lua et je continu a en faire de nouveau.
La j'ai fais un script dédié au canal DMC qui sert sur NES pour les sample DPCM in-game. Le script me permet de visualiser (a la fois sur l'ecran de jeu et dans la fenetre de log) divers informations sur l'usage du canal DMC mais surtout j'ai ajouté un mode "record" qui s'active quand on clique sur le bouton droit de la souris et qui pendant qu'on joue enregistre individuellement chaque sample (tant qu'il est different des précedent) qui passe par le canal DMC dans des fichiers .wav rangé dans un dossier de Mesen. A la fin on a un catalogue complet des samples.

Je me suis fais aussi un script pour Super Contra qui customise le HUD en ajoutant les informations importantes qui manquait. Je me suis fais chier a recopier le sprite des médailles qui represente les vies pour que ca s'integre parfaitement

[vincent2105]

Perso, je suis pas assez calé pour m'amuser à aller chercher des trucs de la sorte, mais récupérer tous les samples comme tu le fais, c'est fortiche  

Et en parlant de Mesen, justement, j'ai voulu tester ma rom à l'instant avec ce dernier et fceux et... j'espère que fceux dit vrai   (mmc3)  Je testerai ça sur NES demain je pense...

[vincent2105]

J'ai pas pu attendre, ça allait m'empêcher de dormir 

Spoiler:

[brokestudio]

Hypothèse : ça peut venir du fait que ta NES fonctionne en PAL et que Mesen ouvre ta ROM par défaut en NTSC ? Que dit Mesen si tu forces en Pal ?

[vincent2105]

En PAL, c'est pareil :/

Peut-être que le soucis vient de la configuration du MMC3.

Perso pour la CHR ROM, je suis en 2k, 2k, 1k, 1k, 1k, 1k ; avec pour le PPU, les sprites à $0000 et le background à $1000.
C'est sans doute pas l'utilisation la plus courante, il me semble que les 4x1k sont plutôt pour les sprites usuellement.

[upsilandre]

vas y balance la ROM je regarderais demain :)

[vincent2105]

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

tu peux bankswitcher la chr rom (B,A)
c'est en chantier on est d'accord 

[upsilandre]

C'est surtout pour voir si c'est pas un probleme de header. Tu sais les header iNES ont montré leur limite depuis longtemps, il manque des infos qui du coup sont un peu libre d'interpretation selon les emulateurs.
Je crois que Mesen est assez strict sur les headers car il supporte aussi les nouveau header NES 2.0 et supporte aussi une base de donnée interne qui permet de reconnaitre la ROM selon son code de hashage et d'avoir donc des données completes de la PCB de la cartouche (et qui permet je crois de lancer les ROM vérifié sans header).
Je sais que sur Github j'ai vu des gars dire que tel ou tel rom ne fonctionnait pas sur Mesen mais sur Fceux et en fait c'etait parce que le header etait pas correct (et comme le header n'a pas d'influence sur le code de hashage qui permet d'identifier le jeu tu peux avoir une ROM vérifié mais avec un header altéré)

[vincent2105]

Ok. Par contre, je sais pas si ça peut aider, mais si je configure le PPU avec les sprites à 1000$ et le background à $0000, j'obtiens la même chose que ce soit sous fceux ou mesen.

[upsilandre]

J'ai pas encore eu le temps de regardé mais oui ca m'interresse de comprendre pour faire remonter l'info ou pas.

[vincent2105]

Bon, j'arrive à faire passer ma rom sur Mesen comme voulu.
En fait, j'avais sauté l'étape initialisation des banks CHR ROM via $8000/$8001 mais ça passait sur fceux et surtout sur NES. En procédant à l'initialisation de chacune des banks CHR ROM, ça passe.

[upsilandre]

Du coup c'est peut etre l'everdrive qui a été tolérant avec toi car c'est lui qui emule le mapper.

[vincent2105]

Ah oui probablement... j'y avais pas pensé ! Moi qui faisais confiance à 100% à mon everdrive... On n'est pas sorti de l'auberge :p

[upsilandre]

Possible que l'everdrive garde peut etre en mémoire la precedente configuration par defaut.
Ca n'aurait probablement pas marché avec un vrai mapper MMC3. quoique je crois qu'il y a pas toujours consensus sur quelle doit etre l'etat par defaut de tel ou tel mapper au power on

[vincent2105]

Y'a des jeux commercialisés à l'époque qui ne passent pas sur Mesen ?
Edit : a priori non 

Haute compatibilité: Plus de 220 mappers supportés (incluant tous les jeux officiels

[upsilandre]

Non tous les jeux sont supporté. 223 mappers sur 224 mapper iNES sont supporté (le seul c'est le 116 et utilisé uniquement pour des jeux pirates)
Les recherches de compatibilité actuellement c'est plutot sur les jeux unlicensed, les multicarts, les homebrew, demo, proto, truc chinois...

[brokestudio]

Petite parenthèse sur une fonctionnalité de Mesen qui est l'édition du code dans le debugger. C'est super pratique, mais c'est dommage qu'on ne puisse pas éditer les valeurs qui sont dans la partie droite de la fenêtre d'édition plutôt que de devoir écrire un code précis. Ca serait utile quand on veut modifier une valeur d'un tableau par exemple.

Après peut être que c'est possible et que je n'ai pas trouvé comment faire ?!

[upsilandre]

oui c'est vrai que ca manque
ou alors pouvoir ouvrir le memory tool avec un simple clic droit sur l'adresse dans le debugger comme Fceux, c'est pratique pour changer des octets directement en hexa
je ferais remonté. De toute facon y aura pas de nouvelle version avant fin novembre et la version 1.0 ca sera plutot pour l'année prochaine, il a prevu de changer encore beaucoup de chose. La il est en train de refaire toute la gestion des inputs.

[Sour]

Bon, j'arrive a faire passer ma rom sur Mesen comme voulu.
En fait, j'avais saute l'etape initialisation des banks CHR ROM via $8000/$8001 mais ca passait sur fceux et surtout sur NES. En procedant a l'initialisation de chacune des banks CHR ROM, ca passe.

En général, Mesen essaye de faire le moins de suppositions possibles à propos de l'état d'un mapper au boot. Dans le cas du MMC3, les registres sont tous initialisés a 0, donc en termes de banques de 1kb, ça donne: [0, 1, 0, 1, 0, 0, 0, 0]. J'imagine que FCEUX de son côté initialise probablement ça à [0, 1, 2, 3, 4, 5, 6, 7] (et même chose pour le Everdrive). J'essaye en général d'éviter de copier ce genre de comportement (qui n'a sûrement pas été validé sur un board MMC3) pour forcer le programme à faire l'initialisation correctement autant que possible (un certain nombre de vieilles démos ont d'ailleurs des problèmes dans Mesen puisqu'ils font des suppositions sur l'état du prg/chr banking au boot).
Aussi, il y a un setting pour forcer tous les types de RAM à être initialisés avec des valeurs aléatoires (plutôt que des 0s partout comme par défaut), ce qui permet de s'assurer que le code initialise la RAM correctement.

ou alors pouvoir ouvrir le memory tool avec un simple clic droit sur l'adresse dans le debugger comme Fceux, c'est pratique pour changer des octets directement en hexa

Ça ne devrait pas être trop difficile à rajouter - mais comme tu l'as mentionné, je suis en plein milieu de d'autres modifications (116 fichiers de modifiés et je suis loin d'avoir terminé...), donc ça risque de prendre un certain temps.

[vincent2105]

Bonjour Sour, merci pour les explications (et bienvenue sur gamopat ! ) 

[vincent2105]

Il va sans dire que je suis impressionné par le travail que tu as accompli, et que j'adopte assurément ton émulateur !
D'ailleurs, je retenterai quelque chose avec le zapper ultérieurement.