Un espoir pour Checkered Flag - Page 2

Je me répète mais pourquoi personne n'a jeté un œil au code source de I-War ?

C'est open source?

Pour résumer, le blitter est... bizarre. Il supporte des trucs comme le Gouraud, les textures, et même le Z-buffering (contrairement à la PS1 par exemple). Mais comme le dit SCPCD, il est incapable de tracer un bête triangle tout seul. Il faut lui mâcher le travail en découpant le triangle en segments. Et on ne peut même pas lui filer une liste de segments et le laisser bosser en arrière-plan : il faut charger les registres avec les paramètres d'un segment, attendre qu'il ait fini de tracer les pixels, recommencer avec le segment suivant, etc.

Pour l'anecdote, ils avaient prévu quelque chose de beaucoup plus efficace pour la Jaguar II (la doc technique est dispo), mais Atari a coulé avant...

Godzil (./30) :
Je sais bien, mais si le bitter est pas trop degueu il y a peut etre moyen d'utiliser en cherchant bien. Ne pas demander a mon cerveau en ce moment. il a d'autre truc a combattre.

J'avais proposé une idée sur cette base il y a longtemps (que je n'ai pas testée, je ne fais pas de 3D). En gros, en configurant astucieusement le blitter, il y a un type de triangles qu'on peut lui faire tracer en une seule fois : ceux qui ont un côté vertical et un côté horizontal.

L'idée est d'obtenir le triangle (en noir) en traçant un parallélogramme (en cyan) clippé par un rectangle (en rose) :


Et n'importe quel triangle peut être subdivisé en plusieurs triangles de ce type :

C'est surtout intéressant pour les gros triangles, et ceux qui ne sont pas trop effilés. Sur un triangle de quelques pixels ou un qui est très allongé (donc qui va devoir être coupé en plein de morceaux), ça va sûrement être plus long de subdiviser et de configurer le blitter que de tracer les pixels à la main.
L'autre souci, c'est que ça ne marche qu'en flat, je ne vois pas comment on peut faire de Gouraud ou de texturé de cette façon.
Bref je ne sais pas si on peut faire quelque chose de cette idée en pratique.

Godzil (./32) :
C'est open source?

Pas au sens Stallman du terme
Mais les sources sont dispos, et il y a approximativement zéro chance que quiconque te cherche des noises pour ça.

il y a quand même plusieurs pb avec ta techniques :
- il y a des bugs de clipping sur le blitter (sinon ca ne serait pas marrant)
- il y a un surcout de calcul pour découper les triangles de manière intelligentes
- ca va être très compliqué à remplir correctement sans avoir de trous ou de bavure je pense :/

Zerosquare (./33) :
Pour résumer, le blitter est... bizarre. Il supporte des trucs comme le Gouraud, les textures, et même le Z-buffering (contrairement à la PS1 par exemple). Mais comme le dit SCPCD, il est incapable de tracer un bête triangle tout seul. Il faut lui mâcher le travail en découpant le triangle en segments. Et on ne peut même pas lui filer une liste de segments et le laisser bosser en arrière-plan : il faut charger les registres avec les paramètres d'un segment, attendre qu'il ait fini de tracer les pixels, recommencer avec le segment suivant, etc.

Pour l'anecdote, ils avaient prévu quelque chose de beaucoup plus efficace pour la Jaguar II (la doc technique est dispo), mais Atari a coulé avant...

[...]

Bref je ne sais pas si on peut faire quelque chose de cette idée en pratique.

Quelle sont les contraintes exactes des quads que le blitter peux sortir?
Juste que les cote adjacent soient paralleles? ou il y a besoin qu'un cote soit horizontal ou vertical?

Le flat/gouraud n'est pas un problème quand tu as besoin de couper la géométrie, tu doit faire ca quand tu clip ta geometrie dans le frustrum, ca demande juste un peu de calcul mais ce n'est pas si horrible a faire.

C'est assez surprenant comme choix d'etre partit sur ce type de geometrie comme base. Je ne sais pas a quoi ils pensaient.
Il y a des jeux qui utilisent ca?

Merci Zerosquare. Mais du coup c'est quel proço qui va remplir le blitter ligne par ligne ? Ça monopolise une chiée de temps non ?
Et du coup t'as une limite du nombre de triangles que tu peux faire par ligne, comme sur la DS ?
Au final il y a des jeux qui l'utilisent, le blitter ? Ou tout le monde fait en soft pour s'éviter la douleur ?

Godzil > des cotés adjacent parallèles, c'est un peut compliqué en euclidien.
Le blitter peut tracer n'importe quel parallélogramme (ie : 4 cotés dont chaque cotés opposés sont parallèles et de même longueurs). Ca c'est la théorie.
En pratique, il faut obligatoirement avoir le parallélogramme horizontale, sinon tu auras des trous à l'intérieur causé par la virgule fixe.


le blitter est prévu pour la 2D, donc normal qu'il ne sait faire que des parallélogrammes.
Le Zbuffer, etc a sans doute été ajouté après coup pour aider au rendu 3D software (i.e. ligne par ligne d'un triangle/quad) vu la mode grandissante de la 3D.
Mais comme dit Zerosquare, on voit clairement que ca a été bien plus aboutie sur la JagII (triangle + interpolation pour les textures).


Brunni > n'importe quel proc peut piloter le blitter. C'est au programmeur de choisir. Tu peux même le piloter avec le DSP si tu veux.
Il n'y a pas de limite de nombre de triangle vu que tout est software => t'auras juste plus de FPS ou pas.
Le blitter est très utilisé sur jag il remplace généralement très bien les copies et écritures dans les zones mémoires par rapport à un autre CPU.

SCPCD (./37) :
Godzil > des cotés adjacent parallèles, c'est un peut compliqué en euclidien.

Oui bon pas adjacent, opposé bien sur, mais tu as compris ce que je voulais dire

Donc parralelogrames arbitraire, mais incapable de faire correctement si c'est pas parfaitement horizontal? He ben, ca a été bien testé Atari...

SCPCD (./34) :
il y a quand même plusieurs pb avec ta techniques :
- il y a des bugs de clipping sur le blitter (sinon ca ne serait pas marrant)

Pfff, non mais si on pas compter sur le matériel, en plus...

à bien y regarder je crois que de toute façon Checkered Flag n'est pas en gouraud shading. Ce n'est probablement "que" de l'ombrage plat (flat shading) et en 256 couleurs peut être...

Le plus simple serait de regarder la liste de l'OP dans un émulateur en mode débug

Bon vérification faite c'est bien du 16bpp, j'imagine que c'est plus simple de faire l'ombrage avec le mode CRY

Putain les gars, c'est toujours extraordinaire de vous lire quand vous parlez technique : j'y comprend à la fois rien, et plein de trucs ! Avec les notions que j'ai, j’arrive à recoller les morceaux et en faire quelques chose (en terme de compréhension). Bien que ça ne dépassera jamais ma simple envie d'apprendre car je n'en ferai jamais rien de concret (il me faudrait 2 ou 3 vies supplémentaires pour ça haha), j'apprécie toujours autant vos échanges techniques que je lis toujours attentivement; merci pour ça !

Je vais pouvoir aller me coucher moins conne comme dirait l'autre

Tu peux demander des précisions s'il y a des choses que tu veux qu'on explique plus en détails

C'est marrant, plus j'en apprends sur la Jaguar plus je me dis que Checkered Flag est "pas si mal" en regardant les vidéos.
Le truc avec le blitter c'est que si tu dois le recharger chaque ligne, tu peux dessiner qu'un triangle par ligne non ? Ou tu dois charger une chaîne de triangles chaque ligne ? Ça rend sur un backbuffer, ou à la place il faut préparer les chaînes offline (une par ligne, double buffer) et laisser un des proços balancer ça ligne par ligne à chaque frame même si rien n'a changé pour avoir le rendu ? Dans ce cas il y a un nombre max de triangles non, vu que le blitter ne pourra pas être assez rapide pour tout rendre à chaque ligne ? (il y avait cette limitation sur DS d'ailleurs)

Contrairement à l'object processor, le blitter ne fait pas de temps réel : il fait le rendu dans un buffer en mémoire dont tu lui donnes l'adresse, indépendamment de ce qui est affiché à l'écran (quand on dit qu'il faut le "recharger à chaque ligne", ça veut dire à chaque ligne horizontale du triangle à dessiner). Donc ce n'est pas comme sur la DS : pas de limite sur le nombre de triangles puisque tu peux dessiner dans un backbuffer et l'afficher quand tu veux, c'est juste que le framerate baissera si tu pousses trop le bouchon.

À vrai dire, comme les "backbuffers" sont en fait des sprites ordinaires, tu pourrais avoir plusieurs plans 3D superposés indépendants et ne pas redessiner ceux qui n'ont pas changé. Et même avoir par exemple un plan en 8 bits et un autre en 16 bits, pour dessiner plus vite des objets qui utilisent moins de couleurs. Enfin ça c'est sur le papier, en pratique il faut voir si on gagne quelque chose (vu qu'avoir plusieurs plans va aussi utiliser davantage de bande passante mémoire pour l'affichage).

Pour rebondir sur l'OP. Il est capable de faire du scaling, je n'ai jamais essayé mais en théorie ca pourrait remplacer le besoin de mip-maps? Donc un gain siginficatif en mémoire?
Suis je dans le vrai ou complètement a la ramasse?

Non le scaling c'est que tu as sans mipmapping, le mipmapping permet d'avoir des textures optimisé suivant la taille a afficher

L'interpolation & scalling vont créer des artefacts qui ne sont pas forcement quelle chose que tu veux.

plus d'infos:

Zerosquare (./45) :
Contrairement à l'object processor, le blitter ne fait pas de temps réel : il fait le rendu dans un buffer en mémoire dont tu lui donnes l'adresse, indépendamment de ce qui est affiché à l'écran (quand on dit qu'il faut le "recharger à chaque ligne", ça veut dire à chaque ligne horizontale du triangle à dessiner). Donc ce n'est pas comme sur la DS : pas de limite sur le nombre de triangles puisque tu peux dessiner dans un backbuffer et l'afficher quand tu veux, c'est juste que le framerate baissera si tu pousses trop le bouchon.

À vrai dire, comme les "backbuffers" sont en fait des sprites ordinaires, tu pourrais avoir plusieurs plans 3D superposés indépendants et ne pas redessiner ceux qui n'ont pas changé. Et même avoir par exemple un plan en 8 bits et un autre en 16 bits, pour dessiner plus vite des objets qui utilisent moins de couleurs. Enfin ça c'est sur le papier, en pratique il faut voir si on gagne quelque chose (vu qu'avoir plusieurs plans va aussi utiliser davantage de bande passante mémoire pour l'affichage).

Ah oui ok

J'ai lu un topic et appris plusieurs choses. Notamment la PS1 a perdu beaucoup d'argent au début (ils les vendaient à perte). Ensuite les blueprint de Tom notamment ont été finalisés en fin 1990, et ce que les ingénieurs avaient eu comme vision c'était des jeux comme Hard Drivin ou STUN runner. Effectivement pas besoin de textures autrement que pour occasionnellement ajouter du texte sur la scène. Le CPU principal n'aurait pas besoin d'être très puissant finalement, c'est surtout le pipeline de dessin qui est important, alors qu'au final ça a été le contraire pour les jeux qui sont devenus populaires à cause des moteurs de collision, des mondes plus ouverts avec pas mal d'objets indépendants, des interactions plus complexes entre eux, … sans parler de la décompression et autres trucs pratiques que ça a rendu possible, ou la capacité de la PS1 de trier les triangles en software pour éviter le Z buffer, un truc trèèès risqué d'ailleurs (grosse quantité de bugs, nombre de triangles réduit si les routines ne sont pas optimales et donc warping énorme car pas de correction de perspective), mais qui a permis de sauver Sony de perdre encore plus de thune parce que 3.5 Mo de RAM à l'époque ça faisait mal, et le Z buffer en gaspillait beaucoup tant niveau bande passante que quantité… et au final c'est passé parce que Sony a été proactif et a partagé correctement les conseils notamment de chez Naughty Dog pour les autres jeux, ce que Sega a justement été incapable de faire sur ses machines.

Bref au final tous ces "et si" qu'on projette sur ces consoles (si Sega avait fait ça, si Atari avait fait ça) ben y en a un qui a fait tout ça correctement en gros, c'est Sony, et ça a donné l'histoire fascinante qu'on connaît, mais qui fait moins chaud au coeur car c'est évident qu'ils sont sortis vainqueurs

Oui, le hardware de la Jaguar a été conçu à l'époque où l'avenir de la 3D pour les consoles de salon n'était pas clair. La Saturn a souffert du même problème d'ailleurs, même si Sega a rajouté du hardware en catastrophe quand ils ont vu ce que Sony préparait.

Pour ce qui est de la mémoire et du CPU, il était prévu initialement un 68020 (j'ai un doute, mais je crois que c'est ça) et 4 Mo de RAM, et ils ont dû réduire à un 68000 et 2 Mo parce que ça coûtait trop cher.

Et il ne faut pas oublier le budget de développement aussi. La conception de la Jaguar n'a pas été faite par Atari, mais par Flare II, une toute petite boîte. Atari les a rachetés, mais déjà à l'époque ils étaient à court d'argent, rien de comparable à Sony qui pouvait investir massivement grâce aux revenus de ses autres divisions.

Zerosquare (./49) :
Oui, le hardware de la Jaguar a été conçu à l'époque où l'avenir de la 3D pour les consoles de salon n'était pas clair. La Saturn a souffert du même problème d'ailleurs, même si Sega a rajouté du hardware en catastrophe quand ils ont vu ce que Sony préparait.

Pour ce qui est de la mémoire et du CPU, il était prévu initialement un 68020 (j'ai un doute, mais je crois que c'est ça) et 4 Mo de RAM, et ils ont dû réduire à un 68000 et 2 Mo parce que ça coûtait trop cher.

Et il ne faut pas oublier le budget de développement aussi. La conception de la Jaguar n'a pas été faite par Atari, mais par Flare II, une toute petite boîte. Atari les a rachetés, mais déjà à l'époque ils étaient à court d'argent, rien de comparable à Sony qui pouvait investir massivement grâce aux revenus de ses autres divisions.

Oui et non car Atari a récupérér 60 millions de dollars en vendant l'usine de Taïwan... C'est pourquoi la Jaguar était fabriqué au UD par une filiale d'IBM (ça et aussi une vague de patriotisme prônant le made in USA aux début des 90's)...

Il ne faut pas oublier que même si au début des 90 's ATARI n'est plus celui du début des 80's ATARI n'a pas jamais demandé à se mettre sous la protection du chapitre 11. En 96 lorsque Tramail à créer JTS il a pu le faire parce ATARI avait de la trésorerie.

Le manque de moyen est un problème mais pas l'unique ni le plus important.

Brunni disait qu'en partageant l'expérience des développeurs SONY a pu aidé la PSone. Si ATARI avait fait la même chose si Eclypse Software avait ouvert son code on aurait pu avoir des jeux 3D beaucoup plus convaicant. Le vrai défaut c'est la vision du top management.

Exemple N°1 : Le 68000 prendre un proc que tout le monde connait pas n'est une mauvais idée en soi (AMiga, Atari ST, Megadrive, Neo GEO, X68000, ... ) mais pour l'époque il aurait peut-être mieux valu le 68020 (un vrai 32 bits ... enfin je crois,...) Aurait surement été plus pertinent car il aurtait été relié à un bus 32 bits et non 16bits comme le 68000. Mais on doit faire des économies alors on prend le moins cher mais aussi celui qui va ralentir la console...

Exemple N°2 : l'absence de chasse aux bugs hardware, je l'ai souvent entendu ou lu sur les forums si la jaguar n'avait pas ses bugs hardware elle aurait pu tenir la route... Maintenant est-ce que cela aurait été suffisant je ne sais pas...

Exemple N°3 : Absence d'ouverture d'esprit. Au début des années 90's les dévellopeurs interne chez ATARI semblaient croire vraiment qu'ils étaient les meilleurs du monde... Et pourtant si Eric Ginner avait fait une pause dans les développement de Crescent Galaxy pour acheter une Genesis avec Thunder force 3 et / Lightening Force -Thunder Force 4 en Europe et au Japon il aurait surement revu sa copie et on aurait surement eu un meilleur jeu.

Exemple N°4 : Trevor Mc Fur est peut-être le premier jeu console a utiliser de l'antialiasing... C'est bien ! ... Mas vu que la jeu est pourri on s'en fout !!! ... Et pourquoi le jeu est pourri ? Parce que le jeu a été mal conçu (de l'aveu même du Programmer Eric Ginner) il n'a pas réfléchi à l'avance sur le papier comment le jeu serait (car visiblement les jeux finaux sont toujours très différents des idées d'origines) mais l'absence d'une idée d'origine et donc l'absence de ligne directrice a fait que le jeu est ce qu'il est .

Exemple N°5 : Ne pas comprendre le marché... Le marché des consoles est drivé par les jeux pas les consoles... Les relations entre ATARI et les développeurs n'étaient pas mauvaise en soit mais le support n'était pas à la hauteur. Et la documentation... N'en parlons pas d'après l'aveu de Mike Deskit (je crois que c'est lui) La Jaguar était la console la moins bien documenté de l'époque (et cela doit inclure les consoles et ordi 8 & 16 bits)...

Je m'arrête là sinon Zerosquare va me flagéler pour relancer un nouveau topic 'pourquoi la Jaguar n'a pas marché), mais il y aurait bien plus à dire...

Mais au final le manque d'argent n'est pas l'argument le plus important. Je dirai même que c'est le plus facile a comprendre mais clairement le plus important.

Maintenant je me pose la question tout de même. Un jeu de course avec le moteur d'Iron Soldier ça donnerait quoi ?

On resterait loin d'un need for speed 3do...

Plus précisément le chipset (car au départ c'était un chipset) Jaguar était prévu pour tourner avec un 68030 (J'ai passé la doc ici il me semble il y a quelques temps). Avec un bus d'adresse de 32bit, une fréquence de 40MHz, 32Mo d'espace ROM, 64Mo d'espace DRAM et 16Mo d'espace SRAM. Bref, un gros kiki qui s'est fait émasculer quand Atari est passé par là avec son "power without the price". Mais en fait, without the power aussi.

sinon concernant Trevor Mc Floury (avec un big mac) c'était avant tout une démo, àlacon, en tout cas pour Atari. Rendez vous compte, des GROS sprites sur une Machine Atari, du jamais vu ! Peut importe que le jeu soit à ch.... avec peu d'intérêt, ca impressionnait les nipons Naintendo et Segrave dans les show, c'était le principale. "eux ils ont 64bit, nous 16... on ne peut pas rivaliser". LOL (LOL mais traduction quasi exact d'une phrase d'un représentant de Nintendo lors de je ne sait plus quel présentation, CES je crois)

MetalKnuckles (./52) :
On resterait loin d'un need for speed 3do...

la 3DO a une vraie puce 3D elle, donc forcement ça eclate la Jaguar.

DEATH (./53) :
Jaguar était prévu pour tourner avec un 68030 (J'ai passé la doc ici il me semble il y a quelques temps). Avec un bus d'adresse de 32bit, une fréquence de 40MHz, 32Mo d'espace ROM, 64Mo d'espace DRAM et 16Mo d'espace SRAM.

Ah ben ça aurait réconcilié pas mal de développeur avec ces specs

Arethius (./50) :
Oui et non car Atari a récupérér 60 millions de dollars en vendant l'usine de Taïwan... C'est pourquoi la Jaguar était fabriqué au UD par une filiale d'IBM (ça et aussi une vague de patriotisme prônant le made in USA aux début des 90's)...

Il ne faut pas oublier que même si au début des 90 's ATARI n'est plus celui du début des 80's ATARI n'a pas jamais demandé à se mettre sous la protection du chapitre 11. En 96 lorsque Tramail à créer JTS il a pu le faire parce ATARI avait de la trésorerie.

Je n'ai pas été voir dans les finances d'Atari à l'époque. Mais s'il y a bien un truc qui revient dans les témoignages, aussi bien de ceux qui travaillaient chez Atari que des développeurs tiers, c'est qu'ils devaient se battre pour récupérer des clopinettes. Alors peut-être que la boîte avait de l'argent, mais il n'allait pas là où il fallait...

Arethius (./50) :
Mais on doit faire des économies alors on prend le moins cher mais aussi celui qui va ralentir la console...

De l'aveu même du concepteur de la console, le 68000 était surtout là pour rassurer les développeurs au début, parce que c'était un CPU bien maîtrisé à l'époque. Il espérait qu'une fois familiarisés avec la machine, ils utiliseraient le GPU à la place, donc que ça n'ait plus d'importance... En pratique, ça ne s'est pas vraiment déroulé comme prévu.

Arethius (./50) :
Exemple N°2 : l'absence de chasse aux bugs hardware, je l'ai souvent entendu ou lu sur les forums si la jaguar n'avait pas ses bugs hardware elle aurait pu tenir la route... Maintenant est-ce que cela aurait été suffisant je ne sais pas...

Clairement pas. Oui il y a des bugs, mais ils ne sont pas insurmontables non plus (et les autres consoles en ont aussi). Pour moi ce n'est pas un facteur majeur.

Arethius (./50) :
Exemple N°3 : Absence d'ouverture d'esprit. Au début des années 90's les dévellopeurs interne chez ATARI semblaient croire vraiment qu'ils étaient les meilleurs du monde... Et pourtant si Eric Ginner avait fait une pause dans les développement de Crescent Galaxy pour acheter une Genesis avec Thunder force 3 et / Lightening Force -Thunder Force 4 en Europe et au Japon il aurait surement revu sa copie et on aurait surement eu un meilleur jeu.

Exemple N°4 : Trevor Mc Fur est peut-être le premier jeu console a utiliser de l'antialiasing... C'est bien ! ... Mas vu que la jeu est pourri on s'en fout !!! ... Et pourquoi le jeu est pourri ? Parce que le jeu a été mal conçu (de l'aveu même du Programmer Eric Ginner) il n'a pas réfléchi à l'avance sur le papier comment le jeu serait (car visiblement les jeux finaux sont toujours très différents des idées d'origines) mais l'absence d'une idée d'origine et donc l'absence de ligne directrice a fait que le jeu est ce qu'il est .

Exemple N°5 : Ne pas comprendre le marché... Le marché des consoles est drivé par les jeux pas les consoles...

Je l'ai déjà dit, mais "Atari" est un mot japonais qui veut dire "mauvais management" oui je sais que ça veut pas dire ça, mais c'est pas drôle

Arethius (./50) :
Les relations entre ATARI et les développeurs n'étaient pas mauvaise en soit

Euuuhhhh... tu as lu les témoignages des développeurs de l'époque ? La plupart n'ont pas vraiment de bons souvenirs de la façon dont ils étaient traités par Atari.

I-War gère les textures ...lui... et le code source est commenté d'ailleurs ... les développeurs étaient Karl West And Andy Seed.

Artemis (./54) :

DEATH (./53) :
Jaguar était prévu pour tourner avec un 68030 (J'ai passé la doc ici il me semble il y a quelques temps). Avec un bus d'adresse de 32bit, une fréquence de 40MHz, 32Mo d'espace ROM, 64Mo d'espace DRAM et 16Mo d'espace SRAM.

Ah ben ça aurait réconcilié pas mal de développeur avec ces specs

Je sais pas d'où viennent ces specs, mais c'est clairement pas réaliste pour les début 90. (sans exploser le prix de vente, vu que c'est au dessus des specs du Falcon et en partie du TT)

Et y a absolument rien qui correspond à ces specs dans les netlist.

fredifredo (./56) :
I-War gère les textures ...lui... et le code source est commenté d'ailleurs ... les développeurs étaient Karl West And Andy Seed.

J'ai pas souvenir de textures dans I-War.

Réutiliser du code c'est généralement compliqué car c'est en général adapté pour un jeu/type de jeu données.

Le code semble très bien partitionné et est souvent commenté... avec une pointe d'humour

* The polygon filler scales and offsets zcoordinates
* This is to prevent the blitter z registers from saturating

* Useable zvalues range from 0 to 114686

* Polygons should not be too 'deep'
* ie furthest zcoord - closest zcoord < 16384

* Also the filler is very optimised to the GPU's pipelining
* So things are not always in the order they seem to be

* You have been warned!

* The source and destination pointers ( A1 and A2 )
* have been reversed to allow reading the texture
* Unforunately this means we can't tile the textures
* but you can't have everything, eh?

Zerosquare (./55) :
Je l'ai déjà dit, mais "Atari" est un mot japonais qui veut dire "mauvais management" oui je sais que ça veut pas dire ça, mais c'est pas drôle

Techniquement ça veut dire "être en échec" (au jeu de go). C'est … très bien choisi non ?