Là le GPU ajoute 1 sprite à la liste tous les 135 cycles environ (@26.6MHz)
bon évidement il ne peut rien faire quand l'OP prend la priorité sur le bus pour dessiner les sprites.
La première partie (la partie avec les spirales) est optimisé au cycle près alors que la 2eme partie ne l'est pas autant vu que de toute façon j'aurais pas gagné suffisamment pour mettre une image plus grande.
Il faut savoir que dans la première partie, le GPU calcul 2688 coordonnées de sprites, mais ils ne sont pas tous visibles
(le max visible c'est environ 2090 mais ça arrive pas souvent). (Et pour les connaisseurs les sprites dans la première parties utilisent le mode RMW de la jag )
En PAL il y a plus de sprites par frame vu que la zone affichable est plus grande, par contre il y en a moins au total par seconde qu'en NTSC.
Il reste 4octets de libre dans le GPU
, il y a un peut plus de 2ko de pris pour des tables et donc un peut moins de 2ko de code.
Afin que ça tienne dans le GPU j'ai du faire du code automodifiant pour certaines parties
Le 68k s'occupe que de l'intro et les crédits (vu que j'avais plus de place dans le gpu !
) donc pendant qu'on en a pas besoin, il est stoppé et il est réveillé qu'a la fin (par interruptions).
Le DSP quand a lui, j'ai demandé à Zero de faire de la musique sans avoir besoin d'accès à la ram vu que sinon ça aurait réduit le temps libre d'accès au bus pour le GPU (et donc moins de sprites) et il a réussi à le faire \o/