Voila, ce post tombé dans l´oublie, et étant donné que je trouve la théorie de quaz51 tres probable, j´en fait un post a part entiere :

quaz51 Posté le 15 septembre 2001 à 14:36:29
je vais vous donnez mon explication technique du probleme de la qualité d´image de ces premiers jeux
en faite wave race et luigi sont justement de tres mauvais exemple pour juger de la qualité de l´antialiasing de la NGC parce qu´ils sont en 30i/s,je m´explique(c´est un peu long)

la NGC gere un antialiasing en fsaa(full scene antialiasing) que nintendo appele subpixels-antialiasing qui est dailleurs une appelation plus juste
cela consiste a calculer plusieurs pixels(qu´on appele subpixels) pour chaque pixel afficher et de les melanger avant l´affichage ce qui créer de l´information supplementaire,augmente la definition de l´image et créer un effet d´antialiasing par le melange des couleurs des pixels
cette technique d´antialiasing est la seul vraiment efficace car en plus de créer un antialiasing elle augmente le niveau de detail de l´image ce qi n´est pas le cas de la dreamcast qui aplique un filtre qui créer un antialiasing mais diminu le niveau de detail

donc la NGC fait du fsaa en gerant 2 subpixels(le minimum) par pixel comme sur certain jeux ps2 sauf que l´optimisation hardware de la NGC permet de les melanger d´une certaine facon qui ameliore encore la qualité du fsaa
le probleme c´est la memoire video
la NGC a une memmoire video interne de 2,1Mo (+1Mo pour le cache texture qui ne nous concerne pas ici)
cette memoire permet de gerer un buffer-video et z-buffer pour une image de 640X480
quand un jeux tourne en 60i/s le jeux est geré en demi-frame
etant donné qu´une tele n´affiche pas 60 image entiere mais 60 demi-image,un coup les ligne paire,un coup les lignes impaires
le jeux est alors aussi gerer en interne dans une resolution de 640x240
un coup on va calculer les lignes paire,un coup les lignes impaire et le resultat affiché sera du 640x480 mais l´animation sera bien en 60i/s car on gere le mouvement entre chaque demi-frame

donc en 60i/s le jeux est geré en 640x240 ce qui laisse de la place en memoire pour faire le fsaa qui demande de gerer 2 subpixels par pixels et donc de multiplier le nb de pixels par deux ce qui reviens a faire du 640x480 en 60i/s puis melanger les pixels 2 par 2 et afficher la demi-frame de 640x240 qui resulte

le probleme c´est qu´un jeux en 30i/s est directement geré en interne en 640x480 (et pas en 640x240 comme en 60i/s),c´est a dire tout les pixels qui vont etre affiché sur l´ecran (la tele affiche seulement 30 image entiere par seconde)
et pour faire du fsaa il faudrait gerer encore deux fois plus de pixels,une sorte de 640x940
mais etant donné que la memoire ne permet pas de gerer plus que du 640x480 (en mode rendu 3d ) alors le fsaa en 30i/s est impossible

donc il est impossible que luigi ou waverace qui sont en 30i/s (comme annoncé officiellement) gere un fsaa par subpixels
donc soit il n´y a pas d´antialiasing dans ces deux jeux,soit ils apliquent un filtre approximatif (la ngc est faite pour du fsaa et pas specialement pour d´autre antialiasing) pour compenser mais qui ne peu rivaliser avec la qualité d´un fsaa

donc pour juger de la qualité de l´antialiaising sur NGC il faut attendre des jeux comme rogue leader qui tourne en 60i/s et dont l´utilisation du fsaa a ete confirlmé officiellement
et je pense que les jeux en 60i/s avec fsaa seront la norme de tout les jeux NGC bientot
malgré tout n´attendez pas de miracle,le fsaa avec 2 subpixels reste insufisant pour faire disparaitre l´aliasing,il faudrait au moins 8 subpixels par pixels voir meme 16
il faudra attendre la prochaine generation de consoles

(j´ajoute que le scintillement est lié en partie a l´aliasing (et au 60hz voir pire,au 50hz)car l´aliasing crée des zone de fort contraste ou sont beaucoup plus perceptible les scintillement,l´antialiasing reduit ces zone de fort contraste)

J´attend la suite ?? trop facile de dire ca tiens pas de bout. ALLER ALLER on argumente ici !!! on est pas fainéant !!

ce post est tres interressant
je vais l´envoyer a des copains qui s´y connaissent mieux que moi

AXLX vas y explique moi pourquoi ca ne tient pas debout, ca m´interresse...

HE HO !! La théorie n´est pas de moi, elle est de quaz51, c´est lui le pro du harware !!!

OUF !! Le voila, il va pouvoir te répondre !!!

steph sur pc les resolution et le rafraichissement de l´image est bien superieur que sur les consoles mais cela n´empeche pas de voir de l´aliasing sur les jeux pc si tu n´utilise pas de fsaa par exemple

oui l´apliquation du fsaa demande pas mal de puissance (environ 2fois plus de puissance graphique puisqu´il y a 2 fois plus de pixels a gerer) mais les consoles nouvel generation en sont capable surtout si l´on considere la faible resolution de la tele
bien sure le fsaa ne sera peut etre pas une generalité meme sur NGC mais je pense que l´on devrais le retrouver dans une grande majorité de jeux (en 60i/s) sur NGC
pour la ps2 c´est un peu plus compliqué

Quaz, tu penses que sur la NGC européenne, il y aura l´option 60 Hz comme sur Dreamcast ???

c´est fort possible et preferable
j´ai lu un truc interressent a ce sujet qui est passé inapercu lors d´une demonstration d´ubisoft a la presse de ses prochain jeux en version europeen apparement il y avait la demonstration cote a cote de tarzan sur ps2 et sur NGC
et la version ps2 tournait en 50hz alors que la version NGC etait en 60hz mais il est probable que se soit du au faite que ubisoft n´a peut etre pas montré la version europpeen sur NGC car le jeu est surement dans un premier temp devellopé en 60hz,il ferrons peut etre la version europpeen en 50hz plus tard car ce n´est pas d´actualité
enfin ce genre de petite info permet quand meme d´esperer

AXLX j´ai jamais dit qu´ils ont fait expres
c´est un choix,ils ont choisi de garder un maximum de puissance pour different effet et donc le jeu c´est retrouvé en 30i/s c´est officiel c´est pas moi qui l´invente
maintenant pour moi il est evident que si le jeux est en 30i/s la memoire video n´est plus suffisente pour faire du fsaa car a mon avis la NGC a ete pensé pour le 60i/s comme la ps2
maintenant bien sure qu´il ne maitrise pas le hardware a fond pour un premiere jeux,ladessus je pense que tout le monde est daccord et comme je dit il n´ont certainement pas mis les meilleurs programmeur sur ces petit jeux alors qu´il y a plein d´autre gros projet en attente et puis ils n´ont pas eu tant de temps que ca
moi je ne trouve rien d´ettonant qu´il n´est pas pue optimiser suffisement pour faire tourner le jeux en 60i/s mais ca va venir avec les prochaine production
et puis commence pas par etre agressif sans raison parce que ca me fatigue ce genre de comportement

C´est paradoxal quand même ^_^
Pinaise, j´ai l´impression de retrouver la saga des ralentissements de la Super Famicom ;p !!
Je ne mets pas en doute la technicité de Quaz (au contraire, je la sollicite), j´ai bien compris, je pense, ce qui a été expliqué, mais cela m´ammène a quelques interrogations.
J´aimerais donc aller un peu plus loin.

Donc, résumons: si je comprends bien, un téléviseur (NTSC en l´occurence) balaye approximativement 240 ligne tous les 1/60ème de seconde.
Un coup les lignes paires, l´autre coup les lignes impaires. Jusque là, je suis d´accord.

Je veux bien croire qu´un jeu en 60 im/s soit géré en interne en 640x240 (mémoire à l´aise) et qu´un jeu en 30 im/s soit géré en interne en 640x480 (mémoire à bloc).
La résolution finale serait la même bien qu´elle soit plus illusoire que réelle dans le cas d´un titre en 60 im/s.
Pour l´instant ça roule.

Cela dit, je ne sais pas si c´est encore le cas, mais de mon temps, le calcul d´une image se passait en deux temps (de ce que j´en avais lu dans les revues spécialisées et qui peut me sembler, aujourd´hui, relativement ridicule).
L´affichage de chaque ligne composant l´image dans un premier temps, le calcul propre au jeu et donc de l´image suivante dans un deuxième temps, ce que l´on appelait la zone "VBL" je crois (virtual blank line ou un truc de ce genre)
Si c´est toujours comme cela que cela fonctionne en règle générale, la question est de savoir si le fameux calcul du filtrage FSAA s´effectue ou non en VBL.

1-Si c´est le cas (on s´éloigne de l´explication de Quaz), quelle est la valeur de VBL (nombre de ligne virtuelles) sur game cube, car cette valeur déterminera précisement ce que peut et ne peut pas faire la console en terme de filtrage d´image (et accessoirement ;p de performances de jeu, ce qui n´est pas le problème aujourd´hui).

2-Si le filtrage FSAA ne se calcule pas en VBL, mais directement à l´affichage (on retombe sur l´explication de Quaz), comment se fait-il qu´après diffusion des 480 lignes calculées d´un jeu en 30 im/s, la console dorme durant le 1/30 de seconde suivant (le temps pour la télé d´entrelacer la deuxième moitié d´image) au lieu de calculer ces fameux sub pixels?
Ou alors, c´est que le temps necessaire pour calculer ces 480 ligne est de 1/30ème de seconde. Dans ce cas là, pour quoi ne retombons nous pas sur le cas du 60 im/s (240 lignes calculées par 1/60ème de seconde)

Enfin bon, cela ne m´empeche pas de dormir ce soir, puisque je ne suis pas programmeur ^_^ mais comprendre des choses ne fait pas de mal des fois ;pp
Et si je pouvais me coucher un peu moins con demain, ça serait pas du luxe ;)

A+

malheureusement j´ai pas bien compris ce que tu voulais dire mais je vais essayer de repondre probablement a coté
dabord le VBL concerne le balayage vertical ( ca veus dire vertical blank line il me semble)
le VBL c´est en quelque sorte une unité de temps qui definie le temps d´un balayage verticale de l´ecran
un jeu qui tourne en 1VBl c´est un jeu en 60i/s (en mode 60hz bien sure)

les jeux utilise un double buffering c´est a dire qu´il y a un buffer pour l´image qui est en cours d´affichage sur l´ecran et un buffer pour l´image suivante qui est en cours de calcule et de tracage
donc le moteur 3d calcule les poly et fait le rendu dans le second buffer quand c´est terminé il attend la fin du VBL pour swaper les deux buffer et pour que l´image qui venait d´etre calculé soit maintenant celle affiché sur l´ecran et ainsi le moteur3d ce remet a calculer et tracer l´image suivante dans l´autre buffer

si le jeux est en 2VBL (donc en 30i/s) le moteur 3d aura tout simplement 1/30 eme de seconde(donc 2fois plus qu´en 60i/s) pour generer tranquilement l´image dans le second buffer pendant que l´autre buffer de 640x480 contient l´image en cour d´affichage(le dac va prendre dans se buffer dabord les lignes paire puis les ligne impaire)

pour le 60i/s c´est la meme chose sauf que le moteur a deux fois moins de temps pour generer l´image et qu´il est possible de ne generer qu´une demi´image en 640x240 ce qui l´aisse de la place pour gerer les pixels suplmentaire necessaire au fsaa
une fois l´image calculé et tracé dans le buffer le fsaa va etre executé et va melanger les pixels pour qu´il ne reste plus qu´une image en 640x240 et c´est celle ci qui va etre swapé dans le buffer qui sert a l´affichage

je sais pas si ca repond a ta question

il est possible que je confonde "VBL" avec un autre terme. Cela dit, c´est le principe des lignes virtuelles qui comptait (2VBL=30im/s=2 fois plus de lignes virtuelles=deux fois plus de temps pour calculer l´image).
Enfin passons sur les lignes virtuelles pour ne se concentrer que sur ton explication et la mienne (je vais essayer d´être plus concis et donc plus clair).

Plaçons nous dans le cas d´un jeu en 60 im/s donc.
1/60ème de seconde pour calculer 240 lignes paires les placer dans le buffer et y appliquer le fsaa.
au 1/60ème de seconde suivant, calcul des 240 lignes impaires, chargement en buffer et application du fsaa.

Dans le cas d´un jeu en 30 im/s maintenant.
1/30ème de seconde pour calculer 480 et les placer dans le buffer. Pas possible d´appliquer de fsaa suite à une mémoire "pleine de lignes".

Pourquoi donc ne pas segmenter artificiellement une image 480 lignes en 2 images virtuelles de 240 lignes calculée en 1/60 de seconde chacune?
Je ne suis pas programmeur, je le répète, mais c´est la première question qui me viendrait à l´esprit...cela peut évidement engendrer d´autres problèmes visuels...je n´en sais rien.

Cela dit, je ne remets pas en cause les choix des concepteurs (je n´en suis pas là ^_^), c´est juste pour comprendre un peu plus...(c´est un peu fait pour ça les forum, non? ;p)

Enfin bon, si je ne suis pas clair Quaz, laisse tomber ;p
en plus, c´est un peu tard pour réfléchir ^_^

A+

Moi les copains je comprends pas grand chose à ce que vous racontez et puis j´ai pas le temps de tout lire!Je dis juste vivement qu´on voit tout ça en mouvement!!
Oilà ;)

-------
Notre futur sera le passé des gens de demain!

oui c y est je comprend ce que tu veus dire
et c´est un raisonement tout a fait logique
mais le probleme c´est que avant d´afficher un poly il faut dabord faire tout les calcule necessaire a sa transformation,calcule de rotation,translation et perspective pour convertir les coordonné 3d de l´objet en coordonné 2d projeté sur l´ecran en fonction de la position de la camera
sans parler du calcule de l´eclairage dynamique

a l´epoque de la ps1 celle ci creait une displayliste qui contenait le resultat de tout ces calcule et cette displayliste qui contenait les coordonné 2d sur l´ecran des poly etait utilisé pour l´affichage de l´image suivante
dans ce cas tout etait gardé en memoire et comme tu dit on aurait pu fragmenté l´affichage de l´image 640x480 en deux meme pour du 30i/s,seul le chip graphique aurait eu a tracer 60 fois l´image mais les calcule seulement 30fois

aujourd´hui sur ps2 la transformation des poly et des vecteur d´eclairage se font a la volé et sont stocké que tres temporairement pour etre aussitot envoyé directement au chip graphique et etre tracé dans le buffer correspondant sans passer par la memoire principale
les information ne sont pas gardé et donc pour reaficher ce polygone pour les ligne impaire il faudrait refaire tout le calcules et donc au finale la quantité de calcule serait proche de ce qui serait necesaire pour faire du 60i/s puisque toute les transformation de poly et d´eclairage qui represente l´essentiel des calcule serait fait 60 fois par seconde
il serait preferable de gerer directement tout le jeux en 60i/s

la NGC et la xbox ayant l´unité de calcule de transformation et d´eclairage integré au chip graphique il est encore plus probable que cela se passe ainsi et que les calcules necessaire a chaque poly se fassent juste avant leur rendu,dans l´unité de calcule dedié a l´interieur du chip graphique et donc cela demanderais aussi de calculer chaque poly 60fois/s si on coupe l´image en deux,donc autant faire du vrai 60i/s

de plus gerer une playliste avec la quantité de polygone utilisé sur les cnole nouvel generation créerait un flux de donné qui boufferait beaucoup e bande passente de la memoire alors qu´il est necessaire aujourd´hui d´en economiser
un maximum(la memoire c´est le probleme numeros un des consoles nouvel generation) donc pour moi il est evident que la ngc et la xbox fassent comme la ps2 et ne gere pas de playlist en memoire et fasse simultanement les calcule et le rendu du poly par economie de bande passente et d´acces memoiree et aussi parce que la puissance de calcule et la puissance graphique sont integré au meme chip pour ce qui concerne la NGC et la xbox

pour la ps2,l´EE a un bus directement connecté au graphics synthetiser et piloté par une unité specialisé qui balance les poly directement de l´EE vers le GS ,c´est meme plus particulierement le VU1 (la plus puissante des deux unites vectoriel)qui a un acces privilegié vers le GS pour balancer les poly
c´est pas tres claire comme expliquation mais ca prend tellement de temps d´expliquer par ecris que je fait un peu dans la precipitation
c´est tellement plus facile par la parole

Bon, je comprends un peu mieux effectivement.

Il y a encore des détails que je n´assimile pas tout à fait, je vais y réfléchir pendant le boulot demain ^_^
Et je reviendrai t´embeter :p

Merci et A+

up pour le topic des ages farouches

c´est quand même marrant : ils se sont battus aussi longtemps alors que leur théorie de d&épart est fausse : on ne décide pas qu´un jeu soit en 30 ou en 60 images par seconde. Le framerate varie selon les situations : il est évident qu´il va diminuer dans une scène imposante ( lancez donc 10 grenades de suite à goldeneye et vous verrez ) pour augmenter ensuite. Le franerate peut être de 30, 60, 44, 12 images par seconde suivant la situation ou de 27, 33, 16, ...

Sinon, bonne initiative d´avoir remonté ce topic

encore un gars qui vient du monde du PC et qui ne sait pas que sur console le framerate est fixé et syncronisé sur le balayage verticale (excepté cas exeptionel qui engendre une saccade)
sur Pc on utilise un triple buffe qui permet de n pas avoir asyncroniser avc le balayage verticale et de ne pas se soucier de la configue
sur console le hardware etant fixe on peu plus facilement fixer le framerate ce qui est bien plus agreable mais demande de gacher un peu de puissance car il faut une certaine marge pour garder le meme framerate mem quand cetaine scene sont plus complexe
pour cette raison sur console un double-buffering suffit ce qui economise aussi de la memoire video

sur console tu n´a pas de jeux en 43i/s ou 32i/s (peut etre un jour sur Xbox ou ca memoire video permet d´utiliser un triple buffering mais une console avec sont hardware fixe permet d´avoir un framerate fixe bien plusagreable donc ce serait domage de s´en priver)

sur console on trouve:
y a les jeux en 2vbl (l´image suivante est construite pendant la durée de 2 balayage verticale soit 25i/s en 50hz et 30i/s en 60hz)
et les jeux en 1vbl qu´on dit "dans la frame" (1 balayage verticale soit 50 ou 60i/s)
sur ps1 et n64 on doit aussi trouver des jeux en 3vbl (17/20 i/s) peut etre meme 4 mais ca m´etonnerait

d´ailleur au sujet de la NGC je persiste
il se confirme aparement qu´on ne peu pas faire de fsaa en fullframe a case du manque de framebuffer (2Mo seulement qui corresponde a ce qui est tout juste necessaire pour un framebuffer et un Z-buffer en 640x480)
pour activer le mode fsaax2 il faut utilisé le rendu en half-frame (mode entrelacé utilisé pour les jeux en 60i/s comme sur ps2) ce qui empeche le fsaa pour des jeux en 30i/s (full frame)

il y aurait aussi un mode fsaax3 qui lui pour entrer dans les 2Mo necessit de baisser le frambuffer et le zbuffer a 16bit (pallete de couleur reduite et zbuffer moins precis)