C'est pour ça qu'on a ces démos impressionnantes ouais mais qui au final ne signifient pas grand chose car on n'aurait jamais pu faire un jeu avec ça (rien qu'on n'aurait vraiment pu faire avec des FMVs courtes à l'époque, surtout que ces démos bénéficient souvent de l'espace en ROM qu'on n'avait pas à l'époque).


La geometry/transform c'est une grosse partie du truc, mais ça peut être fait de façon efficace sur un RISC pour des scènes simples. Regardez ça, avec un ARM à 16 MHz :



Pour les transformations c'est pas tellement la mémoire qui limite, j'ai pas regardé mais avoir 32 ko de RAM interne, partagée entre le code et les données, doit aider beaucoup pour y mettre les textures en effet. En plus sur GBA on a 256 ko sur le bus 16 bits, 3 cycles par accès (5 en 32 bits), ce qui ne devrait pas être si pénalisant pour une texture.

Notez aussi comment les murs sont déugeus quand on s'en approche, c'est parce que les tables de division sont précalculées (le CPU n'avait pas de telle opération, par contre il a une multiplication très efficace) et que le nombre de polys est très limité justement à cause du coût des transformations. Là aussi je pense que ça boufferait de la mémoire précieuse sur Tom (rien que 512 octets serait immense, sur GBA c'est parfaitement rentable d'aller même jusqu'à 2 ko je dirais). Peut être en divisant en 2 phases (transformation où on met les tables de division et autres précalculs en mémoire, puis une phase de dessin où met les textures et autres CLUT), si le coût de transférer un bloc de 4k de la RAM principale à celle de Tom en milieu de frame n'est pas trop pénalisant. Comme je comprends de la Jag l'idée d'utiliser Jerry pour les transformations et Tom pour le rendu c'est une fausse bonne idee. D'ailleurs y a un DMA efficace sur la Jag ? Pour transférer ces 4 ko par exemple sans emmerder le reste ? (OP/DAC vidéo/son)