Re: Mr ToutLeMonde et la programmation NES...

[tfdi]

Oui, à mon avis c'est ça.

Si avec 1 seul vblank, t'as un quart de l'ecran qui flashe, ca veut simplement dire que ta routine d'affichage principale prend plus qu'une synchro verticale.

Il faut:

1 - Essayer d'optimiser ta routine d'affichage si c'est pas déjà fait. En assembleur, y a beaucoup de possibilités ...
2 - Si elle est déjà optimisé au max, diminuer le nombre d'objets, ou faire une nouvelle routine qui ne ré-affiche pas la totalité de l'écran, mais seulement ce qui a "bougé", cette partie dépend du style du jeu.
3 - Essayer sinon peut être de balancer un vblank tous les 2 rafraichissements. Tu ne devrais plus avoir de "flash". Ca aussi, ca dépend du style du jeu. Si c'est un jeu d'aventure, aucun problème, si c'est un shot'em up, ca risque de moins le faire, mais ca peut malgré tout être réalisable, à voir. Il suffit de faire un simple compteur, de lancer ton vblank toutes les 2 synchros verticales et de voir le résultat.

[ichigobankai]

tu peux faire genre un fade out,
éteindre l'écran
charger tes tiles,
rallumer l'écran
et faire un fade in avec une nouvelle palette

je ne sais pas comment ca marche sur nes, mais sur sms je peux charger les background pendant l'affichage actif (et les tiles aussi mais faut diluer le chargement sinon y'a des corruptions dues aux écritures trop rapides)

donc je peux faire
fade out
load background
fade in

(avec waitblank pour les étapes de fondu)

[vincent2105]

Merci à vous deux :)

Je pense que la routine n'est guère optimisable car avec un vblank de seulement 2273 cycles (sur NES), je ne vois pas comment il peut-être possible de charger 1024 octets (taille d'une nametable 960 octets et attributs de couleurs 64 octets ). 

@tfdi :  réduire le nombre d'octets à charger en gardant un bandeau fixe avec points de vies / score etc, sera surement la solution que je choisirai si la gêne est trop importante (mais ca va un peu nuire à l'aspect immersion que j'imagine). Quant à ta 3eme proposition, je n'ai pas encore bien compris comment le mettre en place, mais je vais y reflechir

@ichigo : sur SMS, le vblank dure combien de cycles ? Tu charges combien d'octets par vblank environ ? Si je comprends bien ton "fadeout/load bck/fadein" avec waitvblank pour les fades, c'est en fait ce que je fait : waitvblank/loadbackground/waitvblank. Mais, justement, j'ai un sursaut vertical de quelques pixels avec ces waitvblank, qui disparait si je les supprime mais est remplacé par un flash sur le quart haut de l'écran :/ Après c'est peut-être propre à la NES ou au mapper que j'utilise (mmc3)...

[ichigobankai]

pendant 1 vbl (à 60hz), ~800 octets
pour le nombre de cycles, faudrait que vingazole te dises ca.

Après tu peux diluer ton chargement de tiles sur X frames de vblank

pour le fadein/out c'est aussi pour changer les couleurs par celle du backdrop (couleur globale de fond), mais je ne connais pas le dev sur nes.

[vingazole]

15960 cycles de z80 pendant le VBlank @60 Hz sur SMS (on s'approche plutôt des 900 octets) 

[ichigobankai]

J'ai dit à ça ± "à la louche" mais heureusement que tu es là pour préciser ca bien mieux que moi ^^

[tfdi]

@vincent2105:Une simple valeur d'une variable que tu modifies à chaque appel de ta routine, quand elle est à zéro tu fais un vblank, quand t'es à 1 tu n'en fais pas, ou l'inverse, aucune importance ...

Pour faire simple, un truc style (asm68k)

Code:

sync:
bchg #0,mavar
btst #0,mavar
beq continu
*vblank*
continu:
...


Et là t'auras un vblank toutes les 2 frames, au lieu d'en avoir un toutes les frames. Les opérations sur les bits sont plus rapides, d'où le bchg et le btst.

[vincent2105]

Et là t'auras un vblank toutes les 2 frames, au lieu d'en avoir un toutes les frames. Les opérations sur les bits sont plus rapides, d'où le bchg et le btst.

tu veux dire  : un appel de la routine "vblankwait" non ?
Parce que le vblank, il a lieu à chaque fois que le signal NMI a été déclenché donc à chaque frame si j'ai bien compris.

@Ichigobankai et Vingazole : Merci pour les précisions, j'ai l'impression que c'est kifkif avec la nes  
Pour "Après tu peux diluer ton chargement de tiles sur X frames de vblank " Faut vraiment que j'assimile mieux les notions de frames et autres, pour l'instant, j'ai l'impression que cette proposition engendrerait malgré tout une césure visible de l'affichage du background.

Excusez moi, je suis loin d'avoir assimilé les notions de frame/vblank, mais je me penche depuis quelques temps sur le wiki qui est très fourni a ce sujet : http://wiki.nesdev.com/w/index.php/The_frame_and_NMIs

 Petite précision, j'appelle ma routine  "loadbackground" immédiatement après le signal NMI (avant même le DMA des sprites qui ne comporte pour l'instant qu'un malheureux metasprite de 9 tiles), donc en tout début de vblank, je profite ainsi au maximum du vblank.
Ce qui me fait penser que tant que je chargerai autant d'octets (de background), le problème demeurera.

[Invité]

15960 cycles de z80 pendant le VBlank @60 Hz sur SMS (on s'approche plutôt des 900 octets) 

Tu es sur des 15960 cycles/vblank, ça me parait bcp 

@vincent2105:C'est clair que si ta table est trop lourde, il faut soit la diluer sur plusieurs frames,ou trouver un moyen de tout faire rentrer dans le vblank .


Dsl c'est en anglais:
http://forums.nesdev.com/viewtopic.php?f=2&t=14479

[ichigobankai]

J'ai calculé et vingazole a dit juste,
attention on affiche "que" 192 pixels de haut...

SMS PAL 50hz :
313 (scanlines) - 192 (active display) = 121 * 228 cycles/line = 27588 cycles/vblank

SMS NTSC 60hz :
262 (scanlines) - 192 (active display) = 70 * 228 cycles/line = 15960 cycles/vblank

Et désolé du HS !

[vincent2105]

Dsl c'est en anglais:
http://forums.nesdev.com/viewtopic.php?f=2&t=14479

 
Salut TOUKO Je pense avoir saisi leur propos, mais une petite précision : dans mon cas, j'ai pas inclus le bankswitch de CHR-ROM, mais juste le bankswitch de PRG-ROM afin d'atteindre la nametable désirée au sein de 32 banques différentes qui contiendront chacune 7 nametables différentes. Dans tous les cas, bankswitcher ne doit me couter qu'une dizaine de cycles par bank.

Mais t'as bien fait d'en parler parce que ça m'amène à une nouvelle question :
j'ai le sentiment que je peux bankswitcher (aussi bien des banks PRG que CHR) hors vblank sans que ce soit un problème, qu'en pensez vous ?
 ( je pourrai ainsi gagner des cycles de vblanks, au max potentiellement, j'ai 6 banks CHR et 2 PRG je pourrai gagner 8*10 cycles)

@ichigo, t'es pas du tout HS, au contraire c'est intéressant et t'as bien fait de préciser,  car j'affiche 240px de haut, je vais surement révoir mes intentions 

[tfdi]

Je parlais d'un vblankwait, bien entendu.

Je suppose que la différence que tu as entre les deux, c'est que le vblankwait doit être bloquant, style boucle qui attend le signal de synchro verticale, et qui reste sur sa boucle tant qu'il n'a pas reçu ce signal. Le vblank doit être juste pour savoir si t'as reçu un signal ou pas, sans être "bloquant".

Mais dans tous les cas, ca concerne le signal de synchro verticale.

Un programmeur asm z80 connaissant la nes devrait pouvoir clarifier la situation, je ne connais ni la nes, ni le z80.

[vincent2105]

Oui bien sûr, je parlais du vblankwait :)

Ok, c'est ce que je me disais
Mais dans ce cas,  il me semble que ca ne resous pas le problème non plus, supposons :
1ere transition : ecran A vers ecran B, la routine "vblanwait" n'est pas appelée => le quart haut de l'écran va flasher
2eme transition : ecran B vers ecran C, appel de la routine "vblankwait", pas de flash sur le quart haut de l'écran, mais sursaut vertical de l'image de quelques pixels.

Dans les 2 cas, c'est pas nickel :/

[Invité]

attention on affiche "que" 192 pixels de haut...

ah ok, ça change tout alors ..

@vincent2105:Si ça peut t'aider, même si c'est pas 100% dans le sujet,et cependant comme tu fais pas de scrolling, un changement d'écran complet peut prendre plusieurs frames, ce serra imperceptible Surtout si tu utilise un double buffer .

car j'affiche 240px de haut, je vais surement révoir mes intentions  

Tu peux (peut être) raccourcir l'affichage à 224 lignes, ça restera plein écran et tu gagneras en transfert .
Avec 240 pixels,sur la majorité des écrans (à tube) tu es hors limites .

[vincent2105]

@vincent2105:Si ça peut t'aider, même si c'est pas 100% dans le sujet,et cependant comme tu fais pas de scrolling, un changement d'écran complet peut prendre plusieurs frames, ce serra imperceptible Surtout si tu utilise un double buffer .

Par double buffer, je ne vois pas trop ce que tu entends. Tu veux dire que je devrais diviser ma table en deux puis charger la première moitié dans une frame, puis la seconde dans une autre frame ? J'essaierai ça mais j'avais un doute que cette transition ne soit pas perceptible.

Tu peux (peut être) raccourcir l'affichage à 224 lignes, ça restera plein écran et tu gagneras en transfert .
Avec 240 pixels,sur la majorité des écrans (à tube) tu es hors limites .

Raccourcir l'affichage à 224 px, je viens de regarder sur le wiki, mais je n'ai rien trouvé. C'est marrant que tu parles de ça, sur ma vieille téloche, les 240 pixels passent, d'ailleurs avec un tout petit décalage du a je ne sais quoi, je pouvais même entrevoir la seconde nametable tout en bas de l'écran...

[tfdi]

Ben non, ce serait plutôt ça :

1er Appel:
- vblankwait
- 1ere moitié Ecran A vers B (je dis moitié mais tu peux faire plus, ca te permet d'envoyer autre chose au 2ieme appel)

2eme appel
- 2ieme moitié Ecran A vers B

3ieme appel
- vblankwait
- 1ere moitié Ecran B vers C

4ieme appel
- 2ieme moitié Ecran B vers C

Etc ... il y a la rémanence de l'image comme le dit Touko.

[Invité]

Par double buffer, je ne vois pas trop ce que tu entends. Tu veux dire que je devrais diviser ma table en deux puis charger la première moitié dans une frame, puis la seconde dans une autre frame ? J'essaierai ça  mais j'avais un doute que cette transition ne soit pas perceptible. 

Non tu réserves un écran de 512x240 par exemple, étant donnée que seul 256 pixels de large sont visibles, ça te fait 2 écrans donc .
1 visible, et l'autre qui te sert d'écran de travail .
Tu oscilles entre les 2(avec un scroll de 256 pixels),quand ton écran de travail est mis à jour,il devient ton écran principal, et l'autre devient l'écran de travail,et ainsi de suite.
Ca t'évite d'avoir un écran principal où l'on voit la maj de ta table qui se fait en live.

Et ça te permet de mettre à jour ta table avec le nombre de frame que tu veux sans que ça se voit, puisque l'écran de travail ne sera affiché que quand le transfert sera fini,et puis diviser le trasnfert en 4 frames (ou plus) sera quasiment imperceptible pour le joueur,avec en prime d'avoir du vblank dispo pour autre chose.
tu imagines que 60 frames c'est 1 seconde, soit que dalle en terme d'attente, alors 4 ou 10 frames c'est imperceptible.

Raccourcir l'affichage à 224 px, je viens de regarder sur le wiki, mais je n'ai rien trouvé. C'est marrant que tu parles de ça, sur ma vieille téloche, les 240 pixels passent, d'ailleurs avec un tout petit décalage du a je ne sais quoi, je pouvais même entrevoir la seconde nametable tout en bas de l'écran...

Peut être que ton écran est mal réglé, l'affichage commence plus haut, du coup tu commences à voir l'overscan .
Pour raccourcir l'affichage, tu fais un display_off sur le PPU à la ligne 223, ça force le vblank .

[upsilandre]

Oui c'est simple, dans ta VRAM t'as l'equivalent de 2 ecrans donc t'as juste a charger dans la VRAM qui n'est pas utilisé (avec autant de Vblank que nécéssaire) pendant que l'affichage utilise l'autre partie de la VRAM et switcher avec un Hscroll quand t'as finit.

[vincent2105]

Ah ok, je pense avoir compris, effectivement, ca m'a l'air vachement profitable de travailler avec l'autre écran.. Faut jongler un peu plus, mais au final, la transition est nette. 

Merci à tous pour votre aide  Je vais essayer de mettre ça en place...

[Invité]

Ah ok, je pense avoir compris, effectivement, ca m'a l'air vachement profitable de travailler avec l'autre écran.. Faut jongler un peu plus, mais au final, la transition est nette. 

Merci à tous pour votre aide  Je vais essayer de mettre ça en place...

Ce n'est qu'une solution,mais étant donné que tu ne vas pas implémenter de scrolling, je pense que cette solution est bonne,et surtout propre(le joueur ne voit pas la maj de la table en direct sur la TV) .

[vincent2105]

C'est bon !   

On perçoit  un très très léger flash de tout l'écran lorsque la transition se fait entre 2 écrans dont le background est identique, mais c'est très correct. Entre 2 écrans différents, on ne perçoit rien du tout... 
Ca me convient :)

Et finalement, j'ai même pas eu besoin de toucher au registre de scroll, il suffit de switcher le premier bit du premier registre du PPU ($2000) pour basculer sur l'écran voulu.

Merci encore :)

[Invité]

Et finalement, j'ai même pas eu besoin de toucher au registre de scroll, il suffit de switcher le premier bit du premier registre du PPU ($2000) pour basculer sur l'écran voulu.

Ah bah c'est encore mieux ça comme solution 

[vincent2105]

Oui, dans ce cas précis, j'ai trouvé ça très pratique.  

Bon, je me permets de vous solliciter à nouveau :   

Je souhaiterais qu'il soit possible de réaliser une sauvegarde en cours de partie. 
Je sais qu'il est possible de le faire avec le MMC3 ; on a une extension de  8ko de RAM ($6000-$7FFF), mais je ne sais pas si c'est là que ça se passe...
J'ai parcouru le wiki en quête d'informations, mais je n'ai rien trouvé qui me donne le déclic.  
Quelqu'un sait il comment procéder ? 
merci

[Invité]

D'après ce que j'ai trouvé ,il semble que la WRAM et la Backup ram soit les même .

[vincent2105]

Ok, merci Touko

Dans le wiki j'ai trouvé ces infos :

PRG RAM protect ($A001-$BFFF, odd)

7 bit 0
---- ----
RWXX xxxx
||||
||++------ Nothing on the MMC3, see MMC6
|+-------- Write protection (0: allow writes; 1: deny writes)
+--------- PRG RAM chip enable (0: disable; 1: enable)

Disabling PRG RAM through bit 7 causes reads from the PRG RAM region to return open bus.
Though these bits are functional on the MMC3, their main purpose is to write-protect save RAM during power-off. Many emulators choose not to implement them as part of iNES Mapper 4 to avoid an incompatibility with the MMC6.
See iNES Mapper 004 and MMC6 below.

Question 1 :
Si je fais :

Code:

LDA #%10000000
STA $A001 

Pensez vous que je configure correctement le MMC3 ? (pour sauvegarder la RAM au power off)

Question 2 :
Concernant le bit 6, dans quels cas ne doit on pas autoriser les écritures ? Ca peut interférer avec autre chose, ou c'est tout simplement pour ne pas sauvegarder ?


Enfin, il faudra aussi que je trouve la modification a apporter au header .ines,

Bref, je ne fais pas de tests hasardeux, parce que c'est encore vraiment flou pour moi.

[upsilandre]

Effectivement les sauvegardes se fait en RAM.
Les cartouches peuvent embarquer un boost de RAM (en général 8Ko) et ces 8Ko de RAM peuvent aussi bien servir d'extension de la RAM de la NES ou pour sauvegarder (ou les 2 en meme temps genre 2Ko pour les sauvegarde et 6Ko d'extension RAM), la seul difference c'est que dans un cas y a une pile et pas dans l'autre.
Donc quand y a une pile dans la cartouche c'est juste comme ci t'avais une RAM mais qu'on éteignait jamais la console, a toi ensuite d'en faire ce que tu veux (comme une RAM)
Par contre si tu veux y stocker des sauvegardes dedans y a je pense des protocoles a respecter (pas imposé, juste par principe). Chaque sauvegarde doit etre dupliqué plusieurs fois et avec des code de verification (type checksum) pour controler que les données n'ont pas ete corrompu (ca c'est surtout dans le cas ou tu veux en faire une veritable cartouche).

Faut aussi que tu penses probablement a adapter ton header iNES. Faut declarer que t'as une pile dans la cartouche (et de la RAM), c'est ca qui a priori va obliger l'emulateur a faire une sauvegarde systematique de la RAM de la cartouche dans un fichier.

Pour ce qui est du bloquage en ecriture de la RAM avec le bit 6 c'est une securité si tu considère que certaine phases sont sensible (genre un reset peut etre) dans ce cas impossible d'ecrire en RAM (ca transofrme la RAM en ROM en quelque sorte) et donc pas de risque de corruption mais a partir du moment ou tu utilise cette RAM suplementaire faut le mettre a 0. C'est sans doute pas un truc que t'as besoin d'utiliser.

[vincent2105]

Merci upsilandre, la j'y vois beaucoup plus clair

Par contre si tu veux y stocker des sauvegardes dedans y a je pense des protocoles a respecter (pas imposé, juste par principe). Chaque sauvegarde doit etre dupliqué plusieurs fois et avec des code de verification (type checksum) pour controler que les données n'ont pas ete corrompu (ca c'est surtout dans le cas ou tu veux en faire une veritable cartouche).

Merci pour la précision, je pense que dans tous les cas je me pencherai la dessus tot ou tard. C'est très intéressant :)

Faut aussi que tu penses probablement a adapter ton header iNES. Faut declarer que t'as une pile dans la cartouche (et de la RAM), c'est ca qui a priori va obliger l'emulateur a faire une sauvegarde systematique de la RAM de la cartouche dans un fichier.

Oui, j'y pensais justement, mais je n'ai pas encore trouvé... Je me suis deja fait avoir une fois ou deux avec des .ines incorrects :p Je vais chercher ça...

PS : j'ai vu y'a quelques jours que tes gifs avaient disparu dans les pages précédentes

[upsilandre]

C'est bon !   

On perçoit  un très très léger flash de tout l'écran lorsque la transition se fait entre 2 écrans dont le background est identique, mais c'est très correct. Entre 2 écrans différents, on ne perçoit rien du tout... 
Ca me convient :)

Et finalement, j'ai même pas eu besoin de toucher au registre de scroll, il suffit de switcher le premier bit du premier registre du PPU ($2000) pour basculer sur l'écran voulu.

Merci encore :)

C'est ca.
Et c'est bien un Hscroll que tu fais. Ce bit est simplement le 9eme bit du Hscroll qui ne peut pas entrer dans le registre 8bit dédié donc ils sont obligé de le caser ailleurs (c'est assez classique ce genre de dispersion de bit la ou y a de la place).
Si tu jouais avec le 7eme bit (bit 6) du Hscroll tu aurais une alternance avec un decalage de 64 pixels, en permutant le 9eme du fait un decalage de 256 pixels et donc tu changes carrement d'ecran mais c'est le meme principe.

Et si t'etais en configuration vertical (mirroring horizontal) 256x480 permuter le 9eme bit du Vscroll (le second bit du registre $2000) te décalerait de 256 pixels vers le bas soit plus d'un ecran, ca ne fonctionnerait pas pour ce que t'as besoin donc dans ce cas la c'est bien le registre Vscroll qu'il aurait fallut modifier (et pas qu'un seul bit).

Par contre y a pas de raison que t'ai des flash ou je ne sais quelle glitch. Si t'avance frame par frame en emulation tu dois bien voir si y a une frame glitché. Normalement doit pas y en avoir.
Faut bien comprendre que l'adresse registre $2006 et $2005 (ainsi que les bit 0,1 $2000) pointe en réalité vers un meme registre interne (la seul difference c'est que les bit de data seront pas ranger dans le meme ordre, y a une forme de conversion quand tu utilise $2005 la ou $2006 va juste ranger dans l'ordre) registre qui est en fait le pointeur VRAM que le PPU utilise aussi pendant l'affichage donc bien faire attention de pas utiliser $2006 en dehors du Vblank et inversement utiliser $2005 (et $2000 bit 0,1) apres que t'as finis d'utiliser $2006 pour faire tes truc en VRAM.

[vincent2105]

Merci pour les précisions

Par contre y a pas de raison que t'ai des flash ou je ne sais quelle glitch. Si t'avance frame par frame en emulation tu dois bien voir si y a une frame glitché. Normalement doit pas y en avoir.
Faut bien comprendre que l'adresse registre $2006 et $2005 (ainsi que les bit 0,1 $2000) pointe en réalité vers un meme registre interne (la seul difference c'est que les bit de data seront pas ranger dans le meme ordre, y a une forme de conversion quand tu utilise $2005 la ou $2006 va juste ranger dans l'ordre) registre qui est en fait le pointeur VRAM que le PPU utilise aussi pendant l'affichage donc bien faire attention de pas utiliser $2006 en dehors du Vblank et inversement utiliser $2005 (et $2000 bit 0,1) apres que t'as finis d'utiliser $2006 pour faire tes truc en VRAM.

Je vais voir à ça.
J'vais p'tet abuser mais pour le "pas à pas", pourrais tu me dire comment procéder stp ? (fceuxd sp 1.07)

[upsilandre]

C'est important de pouvoir faire du frame par frame. Moi cette fonction est toujours mappé directement sur mon pad.
Dans Fceux va dans Map Hotkeys et cherche la commande "Frame advance", met la ou tu veux sur ton clavier je sais pas ou c'est par defaut (faut aussi utiliser la pause pour repartir)

[vincent2105]

J'ai une frame avec l'écran "off" (entierement bleu marine, la couleur principale de ma palette)  :/

J'vais relire ton paragraphe et mon code pour voir ce qui cloche...