Un espoir pour Checkered Flag - Page 6

DEATH (./149) :
il manque donc toute la partie calcul 3D

Ce qui est très gourmand. Il serait aussi possible de designer un jeu autour de la 3D précalculer. Mais, la, c'est une autre forme de discussion.

dilinger (./151) :

DEATH (./149) :
il manque donc toute la partie calcul 3D

Ce qui est très gourmand. Il serait aussi possible de designer un jeu autour de la 3D précalculer. Mais, la, c'est une autre forme de discussion.

Peut être un jeu comme Starblade serait envisageable. Sur les plateformes où il a été porté (à part la PS2 et "il parait" le mega CD) ce n'est même plus de la 3D précalculée, mais carrément de la vidéo.

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)

Il y a une instruction de division sur la Jaguar (elle prend 16 cycles, mais elle est exécutée en parallèle du reste).

Et il n'y a pas de DMA du tout. On peut utiliser le blitter pour faire de transfert de mémoire, mais comme il n'a qu'un seul jeu de registres, on ne peut pas lui faire faire autre chose en même temps (comme faire la rasterization par exemple).

16 cycles c'est pas si mal, mais ouais c'est pas suffisant je pense. Là ce gars le fait en 4 cycles je pense. Combien pour la multiplication ?

C'est pas un problème puisqu'on transférerait le code et les données à ce moment, pas de rasterization. Sinon le blitter a des désavantages ? C'est quoi le débit ? Ou les particularités de timing ? (genre beaucoup plus rapide pendant la VBLANK, ou impossible à un certain moment, etc.)

La multiplication se fait en 1 cycle (en réalité 3 cycles, mais comme c'est pipeliné, avec du code bien écrit on peut arriver à en exécuter une à chaque cycle). D'ailleurs, il y a aussi une instruction qui fait encore mieux : multiplication de deux nombres et addition du résultat dans un accumulateur de 40 bits, le tout toujours en 1 cycle. C'est fait pour aider aux calculs des produits matriciels.

Sinon, dans Jerry il y a une petite ROM qui contient quelques formes d'onde, dont une sinusoïde. Je n'ai jamais regardé si c'est suffisamment précis pour calculer des rotations, mais ça peut potentiellement permettre d'économiser de la RAM locale si c'est le cas.

Pour le blitter, je me souviens plus des timings, mais SCPCD doit savoir ça par cœur :


En tout cas, c'est normalement le moyen le plus rapide de transférer des données (sauf pour tous petits blocs, à cause du temps nécessaire pour configurer les registres).
Il n'y a pas de restriction sur quand tu peux l'utiliser ; le seul inconvénient c'est qu'il est prioritaire sur le 68k pour l'accès au bus, donc ce dernier est mis en pause quand le blitter est occupé (le reste du système a des priorités supérieures, donc n'est pas affecté).

C'est pas grave pour le 68k, c'est bien même. D'ailleurs ça me revient plus en tête, comment tu le mettais en pause ce machin ? Y a une RAM accessible au 68k qui soit déconnectée du bus, dans laquelle tu peux le faire pédaler dans le vide ?

Très bien sinon pour l'instruction. J'imagine que la difficulté c'est vraiment de s'en servir du coup… avec ces pipelines, ordres d'instructions et tout…

Pourquoi tu utiliserais les sinusoïdes ? Pour les produits matriciels quand tu transformes (équivalent de glRotate, etc.) ? De toute façon utiliser Jerry pour ça n'est pas réaliste non ? (c'est dans la boucle principale du jeu ça, donc déconnecté de la phase de transformation et de la phase de rasterization, et vu les limites du bus je pense pas que faire tourner le script principal du jeu dans Jerry soit malin). Enfin en y réfléchissant c'est pas forcément impossible, juste pas du tout comme ça que ça a été conçu. Si Jerry peut calculer la scène et donner à bouffer des modèles assez vite à Tom alors ils peuvent bosser en parallèle un peu comme un GPU 3D de l'époque.

Même si certains en parle beaucoup (mais le font ils ?) et que c'est le cas dans Doom (jusqu'à quel point ?), utiliser le DSP pour autre chose que le son ne me semble pas vraiment une bonne idée. Avec les nombreux bugs et manque d'optimisation de l'accès au bus du DSP, ça ressemble plutôt à une vrai galère.

Sinon il n'y a aucune RAM où on peut faire "mouliner" le 68000 dans le vide. Il n'y a qu'un seul bus dans la Jaguar et le 68000 est dessus tout le temps. Mais de toute façon il a la priorité la plus basse. Sinon il y a l'instruction STOP

42bs a encore amélioré la démo STNICCC, maintenant elle tourne entièrement à la VBL

Brunni (./157) :
D'ailleurs ça me revient plus en tête, comment tu le mettais en pause ce machin ?

En soft, stop #$xxxx. En hardware, y'a une broche pour ça.

Brunni (./157) :
Y a une RAM accessible au 68k qui soit déconnectée du bus, dans laquelle tu peux le faire mouliner dans le vide ?

Non, y'a pas de RAM locale pour le 68k. Mais pour le "moulinage" c'est pas grave, parce qu'il a de toute façon la priorité la plus faible pour l'accès au bus (et on peut toujours le stopper manuellement si on veut, comme expliqué plus haut).

Brunni (./157) :
Très bien sinon pour l'instruction. J'imagine que la difficulté c'est vraiment de s'en servir du coup… avec ces pipelines, ordres d'instructions et tout…

Le pipeline est court. Si tu n'utilises que les registres et la RAM locale, la plupart du temps, il suffit d'éviter d'avoir une instruction qui lit un registre juste après une qui écrit dans le même registre. Du coup si tu as deux trucs indépendants à exécuter (A et B), tu fais une instruction de A, puis une instruction de B, puis une instruction de A, etc. Et l'instruction pour le calcul des produits matriciels a un fonctionnement spécial, qui fait que tu peux en enchaîner plusieurs directement à la suite.

Brunni (./157) :
Pourquoi tu utiliserais les sinusoïdes ? Pour les produits matriciels quand tu transformes (équivalent de glRotate, etc.) ? De toute façon utiliser Jerry pour ça n'est pas réaliste non ?

Ah ben je sais pas, la 3D c'est pas du tout mon truc
Et moi j'utilise le DSP pour le son de toute façon, donc pas touche

Brunni (./155) :
Sinon le blitter a des désavantages ?

- en phrase mode, ca peut être tordu de faire certaines traitements car il y a des restrictions d'alignements et autres.
- en pixel mode, c'est plus facile, mais c'est plus lent (mais en général quand même plus rapide qu'une solution pure soft)
- on doit attendre qu'il ai fini avant de pousser une nouvelle configuration

C'est quoi le débit ?

Il y a un topic sur jagware.org mais j'ai la flemme de rechercher le lien

Ou les particularités de timing ? (genre beaucoup plus rapide pendant la VBLANK, ou impossible à un certain moment, etc.)

Le blitter est mis en pause quand un CPU de plus haute priorité utilise les accès sur la DRAM (donc tous les CPU autre que le 68k [hormis si le 68k doit traiter une interruption où là il prend la priorité sur le blitter])
Donc oui c'est beaucoup plus rapide quand il travail dans les zones où rien n'est affiché vu que sinon il est en pause.
On peut le faire fonctionner n'importe quand, mais faut se rendre compte que ce qui est en dessous niveau priorité sera mis en pause.