Re: Megadrive et Super Nintendo : parlons technique !

[Stef]

Vu comment il le présentait je pensais qu'il parlait vraiment des bullets du player (et vu sa réponse c'était visiblement ce qu'il avait prévu). Effectivement accélérer les bullets c'est une astuce pour limiter leur nombre à l'écran... perso moi je n'aime pas trop les shump avec des boulettes trop rapides, ça fait trop "rigide". C'est d'ailleurs un défaut qu'on retrouve d'dans beaucoup de shump SNES (comme SA ou R²) :p

[wiiwii007]

je crois qu'il te manque des guillemets pour le mot " défaut " non ?

Non parce que pour moi c'est pas un défaut 

[Invité]

C'est surtout une astuce pour cacher une faiblesse.

[Invité]

Clairement javais defini 30 bullets pour le joueur, mais dans les fait j'étais plus à 15 où 16. Je l'ai diminué à 12 en accélérant les tirs, car avec les deux modules qui tirent, ça pompe pas mal. C'est optimisable, d'ailleurs j'ai pu gagner en performance en codant plus proprement la function.

[Stef]

Pour répondre à Hpman il me semble (je ne retrouve plus le topic) où on discutait de ce qui était possible de faire en C comparé à l'assembleur.

Encore une fois je pense qu'en 100% C (sur Megadrive toujours) tu as déjà beaucoup de choses de faisable, et même des jeux lourds et impressionnants. Ce qui prime c'est l'algorithmie / l'implémentation intelligente des parties lourdes (genre les collisions). Une fois que les algos sont optimisés alors on peut éventuellement pousser plus loin en mettant un peu d'assembleur sur les parties critiques... mais depuis la version 6 de GCC franchement les performances de base sont déjà bonnes et je pense qu'un passage en assembleur n'apportera qu'un gain de x1.5 en moyenne (x2 ou x3 dans le meilleur des cas), pas plus.
Alors qu'un algorithme adapté peut faire un gain x10 ou plus encore...

Pour appuyer mes dires, voici une vidéo d'un jeu programmé 100% en C sur Megadrive. A noter qu'il utilise l'API low level pour les sprites et pas le sprite engine qui n'a aucun intérêt ici (aucun ou peu de meta sprites) :



Après le jeu est plutot typé speed et dans un sens me fait penser à Super Aleste (il utilise la même astuce avec le background destructible) mais en bien plus chargé et moins rigide quand même :p Et tout ça juste avec du C
Et vu qu'on est proche de la limite en terme de nombre de sprite, on aurait pas pu ajouter grand chose avec de l'assembleur (peut être plus d'effets pourquoi pas ^^).

[TotOOntHeMooN]

Le 68000 a de toute façon été pensé pour être programmé aussi bien en assembleur qu'en C.
Sur Amiga on avait beaucoup de jeux programmés en C. Ce language n'étant pas une limitation à la créativité.
Je dirais plutôt que sonvant, les personnes qui programment en assembleur sont plus ambitieux et l'on fait la confusion entre le language et le résultat obtenu.

[Invité]

Cela me rassure de savoir qu'on peut désormais coder en C sans trop se soucier des performances par rapport à de l'ASM. La scène homebrew à encore de beaux jours sur Mega Drive !

Une prochaine version de GCC pourrait améliorer encore les performances ?!

[upsilandre]

Pour fêter les 30 ans je vous propose une uchronie avec ma version idéal de la Megadrive

-- Deja ma Megadrive idéal elle sort pas fin 88 mais fin 89. Ca permet a la fois de garder 1 an d'avance sur Nintendo pour s'installer avant le leader tout en réduisant la pression technologique et donc l’écart et puis ca permet aussi de mieux préparer le lineup (Ca permettrait par exemple de débarquer directement avec du Ghouls'n Ghosts et du Revenge of Shinobi et en version amélioré, de quoi botter des culs au lancement). Et ca laisse un peu plus de place a la Master System (qui n'a eu que 3 ans, c'est un peu triste). Forcement c'est des choix plus simple apres coup quand on connait le futur et notamment le retard de la SNES.

-- J'enlève dans le VDP les truc les moins utiles comme par exemple la retrocompatibilité Master System ou le Highlight/Shadow pour avoir un truc encore plus optimal

-- Ensuite je profite de cette année supplémentaire pour doubler le nombre de chip de VRAM comme cela avait été envisagé dans la conception de la MD pour avoir 128Ko de VRAM (il reste encore des traces dans le VDP du mode 128Ko exploité notamment dans la démo Overdrive 2). On se retrouve alors avec l'atout très intéressant d'avoir 2x plus de VRAM qu'une SNES ce qui sera de plus en plus bénéfique au fur et a mesure de l'augmentation de la capacité des ROM (et meme sur les petites ROM ca permet de s'affranchir de la gestion dynamique de la VRAM pour liberer encore plus de ressource CPU ou de se payer le luxe de pré calculer des rotations de sprite par exemple et de tout stoker en VRAM)

-- Mais doubler la VRAM ca offre surtout la possibilité d’écrire enfin en VRAM en 16bit et donc de débrider complètement le DMA en écriture VRAM et donc doubler le débit sans cout supplémentaire (pas besoin d'augmenter les fréquences bus ou VRAM ni d'augmenter la taille du bus) d'autant que le bus coté CPU est deja 16bit sur MD (contrairement a la SNES) ce qui permet alors enfin d'en profiter pleinement.
Du coup on se retrouve avec des capacité d'écriture en VRAM 2.5x (voir 3x) supérieur a une SNES ce qui offre beaucoup de possibilité de gestion dynamique de la VRAM (Ca revient quasiment a avoir un espace VRAM virtuel aussi large que la cartouche un peu comme l'arcade) ce qui deviendra a terme le nerd de la guerre (surtout quand les cartouche commenceront a être vraiment plus grosse). Et pouvoir écrire directement en 16bit c'est peut etre la possibilité de faire l’économie du Fifo ou de le simplifier (ca je sais pas trop) et donc d’alléger encore le VDP.
4 chip de VRAM ca ouvre aussi la porte a d'autre choix d'architecture VRAM comme utiliser des chip de DRAM classique (a condition de passer le bus externe VDP externe en full 16bit pour les données et adressages mais c'est deja le cas sur PCE et sur SNES c'est encore pire vu qu'il y a 2 bus d'adresse 16bit a cause du mode 7 donc rien de fou) voir d'utiliser les même chip de RAM que le CPU pour plus d’économie de masse (et encore plus débit car plus besoin de refresh)
Ce doublement de la VRAM offre aussi d'autres atouts déterminant que j’évoquerais plus tard.

-- Je boost évidement les palettes qui sont le point faible de la MD et je passe idéalement a 8 palettes sprites + 8 palettes background comme sur SNES (ca reste 2 fois moins que sur PCE). alors c'est vrai que 8 palettes pour le background c'est un peu problématique car dans l'ID des tiles y a que 2 bits pour les palettes mais y aurait divers solution possible. Par exemple en limitant chaque layer de background a son propre set de 4 palettes, ou alors récupérer un bit sur l'index de tuile (ce qui reduit a 32Ko le tileset background) et ajouté un registre par background pour choisir ou l'on place son tilset (chaque background aurait donc son propre tileset, et dont l'emplacement pourrait varier en cours d'affichage si nécessaire). Y a plein de solution simple pour rendre vraiment viable ces 8 + 8 palettes, c'est pas vraiment un probleme. Si je tiens a avoir 16 palettes c'est pour des raisons que vous verrez plus loin.

-- Je passe aussi a un codage RGB 15bit au lieu de 9bit. Ca c'est pas grand chose non plus. Meme en 15bit ca donne une CRAM plus petite que sur PCE et je compte pas que la PCE embarque aussi une table de conversion RGB > YUV de 512 entrées 15bit (ce qui veut dire aussi que du coté sortie vidéo YUV/Composite de la PCE doit y avoir a priori un DAC 15bit). C'est d'ailleurs ce choix sur la PCE d'avoir un chip graphique qui propose a la fois une sortie native RGB et native YUV aussi pure l'une que l'autre (grace a la table) qui a sans doute empêcher de coder les couleurs nativement en RGB 12bit ou 15bit (car il aurait fallut alors une table de conversion YUV a 32768 entrée au lieu de 512 donc 64 fois plus grosse) sans ce choix la PCE aurait sans doute eu une palette 12bit ou 15bit (meme la Gamegear ou la GX4000 est 12bit, ca coute rien). En plus le DAC Megadrive est deja 12bit (a cause du highlight/shadow) et pas 9bit. Et puis 15bit ou 9bit en terme d'acces CRAM ca reste de toute facon des acces 16bit, autant mieux en profiter.
Donc  rien d’extravagant dans tout ca. Reste juste a savoir si on met la CRAM dans le VDP ou déporter dans l'autre chip qui s'occupe de former le signal vidéo final de la MD un peu comme l'a fait la PCE. Je pense que avec un an de plus et donc un accès a des process de production plus avancé et aussi les petits allègement du VDP dont on a parlé (rétrocompatibilité, Highlight/shadow, Fifo...) y a sans doute moyen de faire entrer cette CRAM dans le VDP. D'une manière ou d'une autre c'est sans doute très faisable.

-- Pour les background j'ajoute simplement un mode 8bpp sur un seul layer (au lieu de 2 layers en 4bpp). Ca consomme moins de bande passante que le mode vidéo actuel de la Megadrive et comme on a déjà 16 palettes et donc 256 couleurs y a rien a ajouté non plus de ce coté la. La valeur 8bpp du pixel pointe directement la couleur parmis ces 256 couleurs deja disponible en CRAM (ou si vous préférez les 4 bit MSB du pixel pointe l'une des 16 palettes et les 4 bit LSB servent d'index dans la palette) donc encore une fois le cout est a peu pret nulle a partir du moment ou on a déjà implémenté cette histoire de palettes mais par contre ca change beaucoup de chose car ca rend la Megadrive futur proof.
Ce mode 8bpp combiné au DMA débridé et au 128Ko (pour avoir du double buffering) ca permet de faire passer un flux vidéo 256 couleurs 30fps par le port cartouche et donc ouvre des possibilités sensiblement supérieur a ce qu'on a connu sur SNES avec le super FX et compagnie. Par exemple sur SNES si le raycasting de Doom est limité a une fenêtre de 216x144 a 15fps c'est pas juste une question de puissance de la cartouche, quelque soit la puissance dans la cartouche il etait pas possible de faire passer plus a cause des limites de la SNES.
Avec cette Megadrive y aurait eu moyen de faire passer par la cartouche un flux 256 couleurs 30fps full screen ou quasiment (Il aurait fallu se limiter plutôt a un format 192 lignes plutôt que 224, donc plutot format d'image Master System). Et puis les sprites de la megadrive peuvent servir aussi de second layer par dessus ce flux 8bpp venant de la cartouche (les ressources sprite de la Megadrive permettent justement de remplir un écran complet sans problème et donc de pouvoir être utilisé comme un layer background).
Ca veut dire aussi que ca aurait rendu le MegaCD plus intéressant grace a cette palette et ce flux possible qui débride le MegaCD et lui aurait peut être permis de vivre sa vie en parallèle sans bider. Et puis ca aurait sans doute éviter aussi le fiasco du 32X puisqu'avec cette Megadrive plus vraiment besoin de la 32X et sa sortie vidéo. Cette Megadrive propose deja la palette de la 32X et avec le flux qu'il est possible de passer dans la cartouche ca ouvre a suffisamment de possibilité custom dans les cartouches pour se passer du 32X.



Conclusion:
Avec cette Megadrive ma foi assez raisonnable et vraisemblable je pense, on se retrouve avec une machine qui perd son principal défaut (la palette) pour s'aligner sur la SNES tout en gardant ses atouts (CPU, résolution graphique) et en ajoutant d'autres atouts graphiques stratégiques (2x plus de VRAM que la SNES, 2-3x plus de débit DMA que la SNES) et une ouverture vers le futur (flux vidéo 256 couleurs 30fps par le port cartouche) qui permet de pousser plus loin que la SNES le principe de cartouche custom qui lui est chère.
Alors la SNES garderait aussi certain atout comme la possibilité d'un 3eme plan 2bpp ou les effets de transparence/lumière ou le mode 7 mais ca serait du coup bien plus équilibré et discutable, y a plus de supériorité a proprement parlé. Certain jeu développé pour la MD serait alors difficilement transposable sur SNES et cette fois pas seulement a cause de la résolution ou du CPU mais de la quantité de VRAM ou du débit DMA. Et plus le temps passerait, plus les cartouches serait grosse (pour profiter de la VRAM et du DMA) et customisable, et plus la MD aurait l'avantage donc elle aurait été vraiment futur proof pour tenir sans problème toute seule jusqu’à la Saturn voir plus. Mais pour ca il aurait fallu voir le futur.

[Tryphon]

Je crois qu'il faut que tu t'allies à Xorion pour retourner en 1988 !

[upsilandre]

La dream team

[TotOOntHeMooN]

C'est un résumé plutôt réaliste de ce qu'aurait pu être la Megadrive, même en 1988 pour certains points sans modifier grand chose. Surtout que comme tu le souligne, des fonctionnalités ont été bridés après coup.

- Les 128K de VRAM avec DMA 16bit forcément
- Les palettes, avoir 2bit par plan plutôt que global c'est une évidence. Est-ce un soucis de mirroring de la CRAM interne ???
- La CRAM externe est déjà possible (utilisé sur System-C2 en 15bit) si besoin
- Si possible, j'aurai préféré du 16bit ARGB et donc couleurs sur 12bit et 16 niveaux d'alpha
- Coté son, t'en parle pas, mais une version incluant l'ADPCM du YM2608 et DAC 16bit

En fait, des choses qui pour la plupart ont dû sauter pour des problèmes de rétrocompatibilité avec la SMS et surtout vu le résultat ils ont simplement dû se dire que c'était suffisant !?

Clairement, fin 1989 ça aurait été top quand on connait la chronologie après coup. 

[upsilandre]

Oui la ce que j'ai mis c'est le minimum je pense de ce qu'on pourrait attendre pour une sortie fin 89 mais c'est deja suffisant pour changer pas mal de chose et donner une position confortable a la MD.

[TotOOntHeMooN]

Oui la ce que j'ai mis c'est le minimum je pense de ce qu'on pourrait attendre pour une sortie fin 89 mais c'est deja suffisant pour changer pas mal de chose et donner une position confortable a la MD.

C'est là où je ne comprends pas la MD2... Ne serait-ce avec 12bit RGB ----rrrrggggbbbb c'était rétrocompatible. Idem pour les 128K de VRAM. Surtout qu'ils avaient le Mega-Cd dans les cartons... Comme je n'ai pas compris la SMS2 (ou j'espérais mise mise à jour façon Game Gear).

[upsilandre]

voir d'utiliser les même chip de RAM que le CPU pour plus d’économie de masse (et encore plus débit car plus besoin de refresh)

Je vois pas comment tu peux faire ça avec un accès / cycles @6.67 mhz vu que déjà il faut une ROM @150ns pour ça .
Le 68k utilise une mémoire @500ns .

Avec 4 chip de VRAM au lieu de 2 le VDP en lecture (la ou le debit est le plus élevé) a besoin de RAM a seulement 3.35 mhz (4 chip c'est 4x8 = 32bit que tu vas donc plutot utiliser en 2 x 16bit, tu alternes alors entre les 2 set de chip de VRAM et tu a alors du 6.71 mhz avec des RAM 3.35 mhz) et c'est la fréquence a laquelle on peut déjà solliciter la RAM CPU avec le DMA.

[upsilandre]

Oui la ce que j'ai mis c'est le minimum je pense de ce qu'on pourrait attendre pour une sortie fin 89 mais c'est deja suffisant pour changer pas mal de chose et donner une position confortable a la MD.

C'est là où je ne comprends pas la MD2... Ne serait-ce avec 12bit RGB ----rrrrggggbbbb c'était rétrocompatible. Idem pour les 128K de VRAM. Surtout qu'ils avaient le Mega-Cd dans les cartons... Comme je n'ai pas compris la SMS2 (ou j'espérais mise mise à jour façon Game Gear).

C'est pas très viable, ca scinde le marché software, si tu fais un jeu MD2 qui utilise 128Ko de VRAM il tournera pas sur MD1, c'est super confusant pour le consommateur, ou alors faut faire des jeux plus compliqué a développer qui s'adapte a chaque machine. Je pense que c'est pas un très bon message envoyé aux les devs et éditeurs mais c'est pas non plus insurmontable
La SMS2 a bien un mode vidéo 224p plutot bienvenu et au final ca n'a pas vraiment été exploité non plus.

[Invité]

voir d'utiliser les même chip de RAM que le CPU pour plus d’économie de masse (et encore plus débit car plus besoin de refresh)

Je vois pas comment tu peux faire ça avec un accès / cycles @6.67 mhz vu que déjà il faut une ROM @150ns pour ça .
Le 68k utilise une mémoire @500ns .

Avec 4 chip de VRAM au lieu de 2 le VDP en lecture (la ou le debit est le plus élevé) a besoin de RAM a seulement 3.35 mhz (4 chip c'est 4x8 = 32bit que tu vas donc plutot utiliser en 2 x 16bit, tu alternes alors entre les 2 set de chip de VRAM et tu a alors du 6.71 mhz avec des RAM 3.35 mhz) et c'est la fréquence a laquelle on peut déjà solliciter la RAM CPU avec le DMA.

j'ai supprimé car je me suis rendu compte que la RAM de la Md, n'est pas celle du 68k classique, mais aussi à 150ns pour le DMA  

[upsilandre]

En tout cas en passant a 4 chip ca baisse potentiellement la fréquence a 3.35mhz et ca ouvre meme je pense a l'usage de DRAM classique pour le VDP (puisque le VDP gère deja le refresh, pas besoin d'avoir un refresh intégré comme la RAM CPU)
De toute faocn quelque soit la solution ce qu'il faut retenir c'est qu'il y a forcement moyen d’écrire en 16bit a la moitié de la fréquence de lecture actuel d'une facon ou d'une autre et c'est le plus important.

[TotOOntHeMooN]

C'est pas très viable, ca scinde le marché software, si tu fais un jeu MD2 qui utilise 128Ko de VRAM il tournera pas sur MD1, c'est super confusant pour le consommateur

Ils pouvaient utiliser ces capacités à travers les jeux "Mega+CD" et ne proposer l'extension que pour la MD2 ou un combo MD/CD.
A un moment on peut avoir l'ambition de renouveler le parc de machines aussi. Plutôt que les gens prennent chez les concurents.

Puis bon, il en fallait pas tant que ça pour se positionner en face de la NeoGeo pour moins cher... Ils se sont fait bouffer leur propre marché.
Assumer une MegaDrive 2 typée "Arcade", plutôt qu'un Mega CD, j'aurais acheté.

La SMS2 a bien un mode vidéo 224p plutot bienvenu et au final ca n'a pas vraiment été exploité non plus.

Ainsi que le zoom sur tous les sprites... Des features qui n'apportaient pas grand chose pour risquer de les intégrer à un jeu.

[Invité]

Si tu baisses à 3.35 tu doubles plus les perfs du coup tu restes au même niveau que les transferts 8 bits @6.67,par contre oui tu peux utiliser de la VRAM/RAM/ROM plus lentes du coup .

[upsilandre]

Si tu baisses à 3.35 tu doubles plus les perfs du coup tu restes au même niveau que les transferts 8 bits @6.67,par contre oui tu peux utiliser de la VRAM/RAM/ROM plus lentes du coup .

nan justement actuellement c'est 8bit a 3.35 en ecriture (sur un bus 13.4mhz) c'est pour ca qu'on dit que le DMA est vraiment bridé. Avec 16 bit a 3.35mhz en écriture tu doubles le debit DMA (d'autant que la avec 4 chip la mémoire tournera qu'a 1.7mhz effectif, c'est surtout la lecture qui a besoin de 3.35). T'as plus de goulot d'etranglement entre la ROM/RAM et la VRAM.

[Tryphon]

Déjà, rien qu'une palette 12 bits et 4 palettes BG + 4 palettes sprites, j'aurais un orgasme

[Invité]

Oui, j'avais compris que le passage en 16 bits à la même fréquence double les perfs,mais ton 3.35 est juste théorique .
J'arrive pas à te suivre là  

[upsilandre]

Je ne sais pas a quelle moment tu t'es perdu donc j'aurais du mal a repondre   .
Le probleme pour la RAM de toute facon c'est pas de réussir a doubler le debit DMA (meme en doublant ca reste 2 fois plus lent que le debit en lecture du VDP lui meme qui est le véritable stress VRAM et ca je cherche pas a le booster).

[Invité]

Je ne sais pas a quelle moment tu t'es perdu donc j'aurais du mal a repondre   .
Le probleme pour la RAM de toute facon c'est pas de réussir a doubler le debit DMA (meme en doublant ca reste 2 fois plus lent que le debit en lecture du VDP lui meme qui est le véritable stress VRAM et ca je cherche pas a le booster).

Sur le 3.35 en fait .
Pour moi 6.67 en 8 bit = 3.35 en 16 bits, donc débits identiques, mais fréquence 2x moindre => mémoire plus lente possible .

[upsilandre]

Je ne sais pas a quelle moment tu t'es perdu donc j'aurais du mal a repondre   .
Le probleme pour la RAM de toute facon c'est pas de réussir a doubler le debit DMA (meme en doublant ca reste 2 fois plus lent que le debit en lecture du VDP lui meme qui est le véritable stress VRAM et ca je cherche pas a le booster).

Sur le 3.35 en fait .
Pour moi 6.67 en 8 bit = 3.35 en 16 bits, donc débits identiques, mais fréquence 2x moindre => mémoire plus lente possible .

Encore une fois je comprend pas exactement ce que tu veux pointer donc je vais tenter de deviner
Actuellement le DMA vers la VRAM c'est 8 bit a 3.35mhz. Donc avec 16bit a 3.35mhz tu doubles le DMA.
La difficulté est pas la. La difficulté ca serait de réussir a alimenter le VDP en lecture pendant l'affichage avec une RAM a 3.35mhz et en doublant les chip tu peux alterner entre les 2 set de chip et simuler un set a 6.71mhz avec des chip a 3.35mhz (et arrete avec ton 6.67 c'est 6.71!!! )

[Invité]

Actuellement le DMA vers la VRAM c'est 8 bit a 3.35mhz. Donc avec 16bit a 3.35mhz tu doubles le DMA. 

C'est bien ce que j'avais compris ..
Et c'est justement ça pour moi qui n'est pas correct,car tu pars du principe que le DMA envoie en VRAM à 3.35 .

[upsilandre]

Actuellement le DMA vers la VRAM c'est 8 bit a 3.35mhz. Donc avec 16bit a 3.35mhz tu doubles le DMA. 

C'est bien ce que j'avais compris ..
Et c'est justement ça pour moi qui n'est pas correct .

Et donc la j'imagine qu'il faut encore que je devine ce que tu ne trouve pas correct, ca peut etre rigolo mais je vais pas avoir le temps ^^

[upsilandre]

Et c'est justement ça pour moi qui n'est pas correct,car tu pars du principe que le DMA envoie en VRAM à 3.35 .

Le debit actuel du DMA VRAM c'est bien 8bit a 3.35mhz

[Invité]

et arrete avec ton 6.67 c'est 6.71!!! 

Ouai on est pas au poil de cul près là 
 

Et donc la j'imagine qu'il faut encore que je devine ce que tu ne trouve pas correct

Parce que la VRAM est pour moi bien accédée par le DMA à 6.71, mais en 8 bits => comme si elle l'était en 3.35 en 16 bits, puisque la ROM/RAM est accédée à 6.71 lors des copies vers la CRAM/VSRAM mais en 16bits .
A 3.35 tu n'aurais pas besoin de ROM/RAM @150ns et je pense pas que tu sois à 6.71 d'un côté et 3.35 de l'autre .

[upsilandre]

Et donc la j'imagine qu'il faut encore que je devine ce que tu ne trouve pas correct

Parce que la VRAM est pour moi bien accédée par le DMA à 6.71, mais en 8 bits => comme si elle l'était en 3.35 en 16 bits, puisque la ROM/RAM est accédée à 6.71 lors des copies vers la CRAM/VSRAM mais en 16bits .

oui donc le probleme c'est que tu te trompe sur tous les chiffres
le DMA VRAM c'est 8bit a 3.35mhz (c'est pour ca qu'on parle d'un vrai bridage, d'un goulot d'etranglement)
le DMA CRAM c'est 16bit a 3.35mhz. Y a jamais eu de DMA a 6.71 mhz t'es un grand malade (le DMA SNES c'est 2.68mhz 8bit)

[Invité]

Et comment tu expliques la RAM @150ns en 3.35 alors ??

le DMA SNES c'est 2.67mhz 8bit... a voila j'ai trouvé d'ou vient le 3.67  )

Euh non, la snes c'est 2.68 en 16bits puisqu'on est à 5.3ko de transferts pendant le VBLANK.