FF Crystal Chronicles Wii : 1ère image !

[keoone]

Akhoran,

moi c'est keoone et pas keeone

plus sérieusement, peut être que le subpixel rendering ne marche que sur les LCD et que le sub pixel anti aliasing de la GC n'est visible que sur les écrans LCD alors qu'il est constamment actif ... je n'en sais rien, mais le fait est que l'anti aliasing lui est possible sur n'importe quels écrans .

Après il faut mettre en perspective plusieurs choses :

le fait qu'elle gère l'anti aliasing ne signifie pas qu'elle peut l'appliquer sur une quantité infini d'objets sous peine de faire chuter le framerate, çà ce voit bien sur RE4 dans les bois ou il y a beaucoup d'objets modélisés, y'a nettement plus d'aliasing que dans les pièces du chateau par exemple ...

Par ailleurs, c'est les développeurs qui décident s'il en mettent ou pas, d'ailleurs l'un des problèmes dont souffrait le GC, c'est que beaucoup de développeurs ont profité que la GC utilisait l'openGL comme la PS2 pour faire des portages à l'arraches ( à contrario la Xbox qui fonctionne sur DirectX voyait ses m^me jeux bien plus optimisés)

[Akhoran]

Mince, pardon pour ton pseudo keoone, j'étais persuadé que c'était keeone Ôo (je le prononce kihone d'ailleurs dans ma tête, je vais devoir désapprendre cette prononciation pour la réapprendre).

Sinon ben je suis toujours pas sûr que le subpixel antialiasing soit souhaitable sur n'importe quel écran.

Je veux dire, comme tu l'as rappelé, il y a différentes façons de faire de l'anti aliasing, avec parfois des techniques très différentes qui font intervenir des types de calculs qui n'ont rien à voir. Donc si la composante subpixel (propre aux LCD) est très présente dans le subpixel antialiasing, ou indiscociable et que ça n'est pas adapté aux CRT, ben on ne l'utilisera pas.

En fait la source de tout mes questionnements c'est cette fameuse option dans SmahBros, qui semble suggérer que antialiasing et subpixel sont liés sur Gamecube, et qu'on ne peut pas avoir soit l'un, soit l'autre, soit les deux. Pourquoi faire de l'antialiasing une option ? Si vraiment ça marche sur tout les écrans, alors ce serait activé de base, vu que c'est à l'évidence un gain visuel. Et si la gamecube gère trois niveaux d'antialiasing (pas d'antialiasing / antialiasing / subpixel antialiasing), alors l'option de smashbros porterait sur si oui ou non on peut exploiter la composante subpixel (en gros : avez vous un lcd ?). Or on dirait que quand on décoche l'option, on tombe dans un mode sans aucun antialiasing. C'est débile, on devrait tomber sur un mode avec antialiasing 'simple', sans subpixel (truc qui marche sur tout les écrans).

Vous voyez où je veux en venir ?

Ps : je répète que je n'ai pas le jeu et que j'ignore tout de cette option, du coup je peux pas tester.

[keoone]

je n'ai pas ce jeux non plus ... donc je ne peux pas te répondre ...

mais une chose est sure c'est aux développeurs de s'appliquer à tirer partie des ressources de chaque consoles, ce qui n'a pas été fait sur GC (les jeux qui utilisent 70% de ses ressources doivent se compter sur les doigts d'une main .... )

[JC Tergal]

Préembule : je me fou assez royalement de l'aliasing ^^, vu que de fait je le vois très peu sur mes jeux GameCube. Par compte ça m'intéresse de déméler le vrai du faux sur ce que sait faire la Gamecube, et surtout de savoir si c'est effectivement exploité ou non dans les jeux. Là où on se rejoins, JC Tergal, c'est que tu constates comme moi qu'il y a peu de jeux qui disposent d'anti aliasing sur GameCube.

Tu parles encore du GC comme si c’était la seule console concernée par les problèmes d’aliasing… Comme je l’ai déjà dit les PS2 et XBOX présentent aussi de l’aliasing et ont très peu de jeux réellement anti-aliasés aussi. La plupart des jeux de ces 3 consoles jouent surtout sur les effets graphiques que j’ai cité plus haut pour limiter ce phénomène d'aliasing... car la plupart de ces effets sont plus économes en ressources machine, et donc cela peut s'avérer être un bon compromis pour l'ensemble graphismes/fluidité du jeu.
Maintenant, il est bien sûr difficile de comparer l’aliasing présent dans différents jeux de différentes consoles car les critères de quantités de détails affichés à l’écran, d’éléments en mouvements, etc… à une influence sur ce phénomène car emploient déjà plus ou moins de ressources hardware ; et plus il y a de détails et d’éléments affichés, plus il y a de choses à anti-aliasées aussi… Mais j’ai quand même fait un comparatif basique sur une TV LCD HD (ce qui n’est pas forcément le top pour cacher le phénomène pour des consoles non HD). Les 3 jeux comparés sont God of War 2, Halo 2 et Metroid Prime 2 (donc je compare MP2 à ce qui, en gros, ce fait de mieux chez la concurrence). Voici mon constat :

-Et ben il y a à peu près autant d’aliasing dans ces 3 jeux… Donc MP2 n’est pas pire que les 2 autres jeux alors que MP2, à la base, joue moins la carte de la qualité graphique qu’un GoW 2 ou un H2… Sans parler de la netteté des images (selon les effets, etc…) qui varie d’un jeu à l’autre et qui met plus ou moins en avant le phénomène d’aliasing (et MP2 et H2 sont les plus net donc ceux où le phénomène pourra être plus visible). Et enfin, dans ce comparatif, je précise que le GC est la console la moins exploitée des 3 pour faire tourner MP2…
-Ensuite, pour ces 3 jeux, je dois bien avouer que même sur un écran LCD HD, il faut vraiment arrêter de bouger le jeu et fixé son regard sur les bordures pour remarquer qu’elles sont aliasées. C’est pour cela que j’avais dit que pour ma part, je n’avais jamais fait gaffe aux effets d’aliasing de ces 3 consoles (sauf quelques exceptions sur la PS2), car quand je joue, je ne m’amuse pas à fixer mon regard sur les bordures, mais en plus, le jeu est en mouvement… donc cet aliasing passe "inaperçu".

Et sinon, pour ce qui est de la gestion de l’anti-aliasing "pur" (qui n’est pas le même sur XBOX et GC), le GC ne s’en sortira pas plus mal que la XBOX car contrairement à la légende là aussi, le GC n’est pas moins puissant qu’une XBOX... Et quitte à créer une nouvelle polémique :
Le GC est peut-être même un cran au-dessus… même si cela ne s’est jamais remarqué… (Là j’ imagine certains : « Quoi ??? Mais c'est n'importe quoi !!! C'est impossible !!! Tu racontes de la merde Tergal… sale pro-N de mes fesses ! On va te ni**** ta face de Mario... »). C'est pour cette raison que j’avais écrit dans un autre post que le GC était la console qui avait le moins révélé de son potentiel lors de la précédente génération... elle en avait même encore pas mal sous le pied…

Si je dis tout cela, ce n’est pas pour faire mon pro-N de bas étage mais plutôt pour défendre le fait que les consoles Nintendo, depuis la N64, ont toujours étaient dénigrées et sous-estimées (face à des concurrentes souvent surestimées), alors que ces consoles Nintendo étaient les mieux conçues à chaque fois. Attention, je ne parle pas de la Wii par contre car elle ne peut être directement comparée aux PS3 et 360 en raison du critère HD (qui demande énormément de puissance). Mais en mettant de côté ce critère HD, la Wii est une console très puissante qui, même sans HD, à le potentiel de créer des environnements de jeux très immersif... Supérieur à un Halo 2 dont l'environnement est déjà très immersif grâce à des décors style "réaliste" (qui ne sont pourtant qu'en SD).

Keeone, le type de sortie ne suffit pas à déterminer le type d'écran que tu auras à l'autre bout. Déjà je crois qu'il existe des CRT avec entrée numérique, mais en plus tu peux très bien avoir un LCD RGB ou BGR, et pour l'un ou l'autre la technique ne sera pas la même.

Si… la technique sera la même pour le RGB ou BGR.
Maintenant pour infos (que j’ai déjà données aussi) concernant le Sub-Pixel Rendering (SPR):
Les écrans LCD BGR sont très minoritaires (pour ne pas dire inexistant aujourd’hui), mais de toute façon, le SPR gère très bien cela… Et le SPR est également exploitable sur les écrans mis en position verticale.

Où je veux en venir aussi, c'est que c'est faux de croire que dans les jeux GameCube les contours des objets sont lissés, et que ce ne serait magiquement plus le cas sur Wii. Ce n'était déjà (généralement, on va dire) pas le cas sur GameCube.

Tout comme c’est faux de le croire pour la PS2 ou la XBOX…

…mais finalement ça ne nous dis pas ce qu'est le sub pixel antialiasing(le truc de la gamecube). Si vous avez de bons liens dessus je suis preneur d'ailleurs.

Je l’avais déjà vulgarisé dans un de mes posts plus haut, mais je vais essayé d’être plus clair ici:
Déjà je précise que non, la composante "sous-pixel" n’est pas propre au LCD car un pixel d’écran CRT est aussi composé de 3 luminophores (Rouge Vert et Bleu). Maintenant, pour ce qui est du sub-pixel Anti-aliasing :
C’est un anti-aliasing combiné à cette notion de "sous-pixels" d’un pixel entier (d’écran CRT ou LCD donc).
C’est à dire, en gros, que l’anti-aliasing va pouvoir directement donner différentes valeurs à chacun des "sous-pixels" d’un pixels entier plutôt qu’à tout le pixel entier (comme ça ce fait classiquement).
Cette technique à fait ses preuves pour les écrans CRT à la base.

Pour ce qui est des bons liens à ce sujet, ben je ne sais pas ? Désolé…

En fait la source de tout mes questionnements c'est cette fameuse option dans SmahBros, ...

...Vous voyez où je veux en venir ?

Ps : je répète que je n'ai pas le jeu et que j'ignore tout de cette option, du coup je peux pas tester.

Oui, je vois où tu veux en venir avec cette histoire d’option dans SmashBros et je pense que mon "maxi concentré" d'explications sur le sub-pixel Anti-aliasing du GC (notamment que c'est pour CRT à la base) peut répondre à une partie de ton interrogation.
Maintenant je ne peux pas t'en dire plus sur cette fameuse option de ce jeu en particulier car je ne l'ai pas non plus (Noooon, ne nous lapidez pas !!!).

[Akhoran]

Tu parles encore du GC comme si c’était la seule console concernée par les problèmes d’aliasing…

Euh... ben non. Je parle de la Gamecube et de la Wii parce qu'on est sur PN :p, et qu'en l'occurence c'est bien les capacités intrinséques de ces deux consoles qui m'intéressent.

Si… la technique sera la même pour le RGB ou BGR.

La technique est la même mais pas le bout de code à éxécuter pour la mettre en oeuvre. Si tu dis à ton programme d'afficher du R 0 G 0 B 255, ça fera pas du tout la même chose sur un RGB que sur un BGR (et si ça fera un bâton bleu à droite sur un RGB, ça fera un bâton bleu à gauche sur BGR). Le liens que j'avais filé sur le SPR le montre bien. Y a une option à indiquer quelque part pour que le programme sache comment sont physiquement placés les pixels pour pouvoir balancer les bonnes valeurs RGB et créer les pentes adéquat.

un pixel d’écran CRT est aussi composé de 3 luminophores

Oui mais je ne crois pas qu'ils soient toujours gentillement alignés verticalement, les uns à côté des autres (contrairement aux LCD). S'ils sont en espèce de prisme 'rond' ça fera de la merd'.

C’est à dire, en gros, que l’anti-aliasing va pouvoir directement donner différentes valeurs à chacun des "sous-pixels" d’un pixels entier plutôt qu’à tout le pixel entier (comme ça ce fait classiquement).

Ca je m'en doutais, mais j'avoue que ça ne m'éclaire pas :p. Quelque soit la couleur qu'on veuille obtenir, on balance des valeurs RGB bien précises qui vont chacune s'appliquer à un sous pixel (donc des valeurs différentes à chaque sous pixel). Le truc qui m'interesserais c'est de savoir quelle est la façon intelligente de procéder de cet anti aliasing pour à la fois exploiter la subdivision physique des sous pixels pour tripler ou presque la résolution horizontale, tout en ne dénaturant pas les couleurs intrinséques de l'image.

[JC Tergal]

Tu parles encore du GC comme si c’était la seule console concernée par les problèmes d’aliasing…

Euh... ben non. Je parle de la Gamecube et de la Wii parce qu'on est sur PN :p, et qu'en l'occurence c'est bien les capacités intrinséques de ces deux consoles qui m'intéressent.

Oui on est sur PN, et oui à la base tu parles des capacités GC (et un peu Wii), mais il n'empêche que tu évoques les tout petits soucis d'aliasing en faisant comme si cela était uniquement récurrent aux consoles Nintendo, alors que ce problème est le même pour toutes les consoles sans exception (y compris les PS3 et 360 même si cela est plus discret sur écran HD grâce à la taille réduite des pixels pour une diagonale d’écran équivalente). Donc je ne comprends pas que l'on puisse ainsi focaliser ce petit problème sur ces 2 consoles Nintendo en particulier.
De plus tu parles aussi de ces petits problèmes d’aliasing comme si c’était une catatrosphe alors que ce n’est pas du tout choquant, même flagrant… Il faut vraiment, comme je l’ai déjà dit, arrêter le jeu et se focaliser sur les bordures (donc dans ce cas tu ne joues plus en fait)…

Si… la technique sera la même pour le RGB ou BGR.

La technique est la même mais pas le bout de code à éxécuter pour la mettre en oeuvre. Si tu dis à ton programme d'afficher du R 0 G 0 B 255, ça fera pas du tout la même chose sur un RGB que sur un BGR (et si ça fera un bâton bleu à droite sur un RGB, ça fera un bâton bleu à gauche sur BGR). Le liens que j'avais filé sur le SPR le montre bien. Y a une option à indiquer quelque part pour que le programme sache comment sont physiquement placés les pixels pour pouvoir balancer les bonnes valeurs RGB et créer les pentes adéquat.

Ben pourquoi tu expliques cela ? Oui il y a une option (normalement automatique) qui sert juste à indiquer si pour l’écran le Rouge et le Bleu sont inversés (j'en ai parlé 2 fois déjà), et c’est tout... A part cette précision à donner, la technique employée est exactement la même, et toi-même tu le dis en début de phrase donc, dans ce cas, pourquoi discuter à ce sujet ??? Pourquoi encore essayer de trouver une issue.
Tu as commencé par dire que la technique était différente selon que le LCD est RGB ou BRG, et maintenant, tu affirmes l'inverse et tu bifurques sur autre chose.

un pixel d’écran CRT est aussi composé de 3 luminophores

Oui mais je ne crois pas qu'ils soient toujours gentillement alignés verticalement, les uns à côté des autres (contrairement aux LCD). S'ils sont en espèce de prisme 'rond' ça fera de la merd'.

Ben les 3 luminophores d'un CRT sont toujours gentillement disposés en une sorte de triangle équilatéral et ainsi, on obtient des lignes qui vont parfaitement s’imbriquer… et donc, au final, on obtient des lignes composées des 3 trois luminophores alignées (et chaque luminophore d’une couleur est activé par un faisceau d'électrons qui lui est propre afin de ne pas se mélangés).
Maintenant, est-ce que tu as bien lu ce que j'ai écrit quand j'ai parlé de cela ? Car à ce moment j'expliquais très brièvement ce qu'était le sub-pixel Anti-aliasing (SPA) et que cette technique à la base fonctionne sur les écrans CRT... donc non, ça ne fait pas de la merde pour ce type d'écran. Mais je reprécise que le SPA fonctionne aussi pour les écrans LCD.
Enfin, et surtout, tu as avoué plus haut ne pas savoir ce qu'est le SPA, donc comment peux-tu affirmer que ça va faire de la merde avec des écrans CRT ???

C’est à dire, en gros, que l’anti-aliasing va pouvoir directement donner différentes valeurs à chacun des "sous-pixels" d’un pixels entier plutôt qu’à tout le pixel entier (comme ça ce fait classiquement).

Ca je m'en doutais, mais j'avoue que ça ne m'éclaire pas :p. Quelque soit la couleur qu'on veuille obtenir, on balance des valeurs RGB bien précises qui vont chacune s'appliquer à un sous pixel (donc des valeurs différentes à chaque sous pixel). Le truc qui m'interesserais c'est de savoir quelle est la façon intelligente de procéder de cet anti aliasing pour à la fois exploiter la subdivision physique des sous pixels pour tripler ou presque la résolution horizontale, tout en ne dénaturant pas les couleurs intrinséques de l'image.

Ah tu t’en doutais et je ne t'éclaire pas... et bien excuse-moi alors d’avoir prit le temps de répondre à ta phrase :
« mais finalement ça ne nous dis pas ce qu'est le sub pixel antialiasing (le truc de la gamecube). ». Chose que j’avais déjà très brièvement expliqué d’ailleurs.
Sinon :
Pourquoi cela dénaturerait les couleurs intrinsèques de l'image ??? Le SPA est fait pour jouer sur les effets d'aliasing (donc les bordures principalement), et une bordure n'est qu'une infime partie des choses représentées dans une image donc tout le reste de l'image n’est pas concerné et garde son aspect d'origine. Seules les bordures d'objets affichés subissent un effet de flou (qui généralement passe inaperçu) ce qui est normal puisque le but premier est de jouer sur les dégradés des couleurs des pixels en bordure (et plus précisément sur les valeurs de sous-pixels pour le SPA).
Maintenant, quoi te dire d’autre pour expliquer cela ?
Que le SPA, pour une image donnée, connaît (ou détecte) la composition sous-pixellaire des pixels en bordure et qu’il peut faire varier par calcul cette composition sous-pixellaire selon les pixels environnants (eux mêmes composés de sous-pixels) afin de donner différentes valeurs aux sous-pixels des pixels en bordure, ce qui changera le pixel… ?
A moins que je ne fasse un long laïus de 3 pages… mais j’avoue que cet perspective ne m’enchante pas vraiment (pas le temps et pas la motivation, surtout si c’est pour tourner en rond) ; et je pense que mes posts sont déjà assez long comme ça… pour répéter les 2 tiers des choses en plus.

[Akhoran]

Je ne parle pas du tout de l'aliasing comme si c'était une catastrophe. S'il y a des passages de mes posts qui t'on fait penser ça je veux bien voir lesquels (ce n'est pas une façon de chercher à te prendre à défaut, c'est une façon pour moi de savoir les endroits où ce que j'ai voulu dire est mal passé).

Mon préembule quelques postes plus tôt servait d'ailleurs justement à recadrer cette (fausse) idée :

Préembule : je me fou assez royalement de l'aliasing ^^, vu que de fait je le vois très peu sur mes jeux GameCube. Par compte ça m'intéresse de déméler le vrai du faux sur ce que sait faire la Gamecube, etc...

Je ne crois pas avoir une seule fois cité les autres consoles, donc je ne vois pas ce qui te fais penser que je stygmatise la GameCube.

Ben pourquoi tu expliques cela ? Oui il y a une option (normalement automatique) qui sert juste à indiquer si pour l’écran le Rouge et le Bleu sont inversés (j'en ai parlé 2 fois déjà), et c’est tout... A part cette précision à donner, la technique employée est exactement la même, et toi-même tu le dis en début de phrase donc, dans ce cas, pourquoi discuter à ce sujet ??? Pourquoi encore essayer de trouver une issue.
Tu as commencé par dire que la technique était différente selon que le LCD est RGB ou BRG, et maintenant, tu affirmes l'inverse et tu bifurques sur autre chose.

J'explique ça parce que comme tu me réponds que 'oui, la technique est la même' (lorsque je parlais de la différence RGB/BGR), j'ai pensé qu'il y avait une mésentente sur mon emploi du terme 'technique'.

La 'technique', le concepte est le même (pour le rendering), mais elle doit être mise en oeuvre d'une façon spécifique pour chaque catégorie d'écran, en fonction de l'agencement et de la position physique des sous pixels.
[edit : je précise un peu, c'est pas forcément super plus clair en fait. La première fois que j'ai employé le terme 'technique', je voulais dire 'mise en oeuvre'. Dans ta réponse, j'ai cru comprendre que tu l'avais interperété non pas comme 'mise en oeuvre', mais comme 'le concepte'. Du coup je t'ai répondu derrière en essayant de parler 'ta langue' histoire que l'on parle le même langage et te faire comprendre ce que je voulais dire. C'est ce qui te donne l'impression que j'ai changé de discours entre mes deux réponses, alors que la seule chose qui a changé c'est le sens qui se cache derrière le mot 'technique'. D'abord le miens, puis le tiens, et enfin le miens = le tiens. Je n'ai fait que dire deux fois la même chose, en fait.]

Et mon intervention visait à expliquer que l'option ne peut pas être intelligente et automatique, car personne d'autre que l'être huamin ne peut communiquer à la console comment le moniteur sur lequel elle est branché est physiquement fabriqué.

Ben les 3 luminophores d'un CRT sont toujours gentillement disposés en une sorte de triangle équilatéral et ainsi, on obtient des lignes qui vont parfaitement s’imbriquer… et donc, au final, on obtient des lignes composées des 3 trois luminophores alignées (et chaque luminophore d’une couleur est activé par un faisceau d'électrons qui lui est propre afin de ne pas se mélangés).

J'aimerais bien un dessin, parce que je ne suis pas sûr de comprendre la disposition. Quoi qu'il en soit ce n'est pas très important je crois, vu que mon propos est de dire que sur les CRT, les sous pixels ne sont pas des bâtons, mais autre chose (des triangles donc, d'après ce que tu dis).

J'ai bien lu ce que tu as dis. Si j'ai bien compris (ce qui n'est pas sûr), tu dis qu'on exploite les sous pixel pour redessiner les contours. Mais on allumera pas les mêmes sous-pixels pour faire un rond (exemple de contour pris au hasard) avec des triangles que pour faire un rond avec des bâtons. Et même pire, l'algo doit être complètement différent entre bâton et triangle, puisque ce qui compte avec la technique des sous pixels (pour le rendering en tout cas) ce n'est plus vraiment la couleur des pixels mais leur forme.

Je ferais un dessin chez moi pour expliquer ce que je veux dire, ce sera peut être plus simple à comprendre et à corriger.

Ah tu t’en doutais et je ne t'éclaire pas... et bien excuse-moi alors d’avoir prit le temps de répondre à ta phrase

Je ne te reproche pas de m'avoir répondu, et d'avoir essayer de m'éclairer. Au contraire, je t'en remerci même. Mais je ne vais pas te dire 'ah oui merci j'ai compris !' si je n'ai pas compris ou si ça ne m'apporte rien de nouveau. Donc merci de m'avoir répondu et d'avoir essayé, mais non, ça ne m'éclaire pas davantage (et ce n'est pas une insulte, c'est un constat).

Que le SPA, pour une image donnée, connaît (ou détecte) la composition sous-pixellaire des pixels en bordure et qu’il peut faire varier par calcul cette composition sous-pixellaire selon les pixels environnants (eux mêmes composés de sous-pixels) afin de donner différentes valeurs aux sous-pixels des pixels en bordure, ce qui changera le pixel… ?

Ca ça m'éclaire déjà un peu plus (et à vrai dire, ça me conforte dans la vague idée que j'en avais). Après je t'avoue que ce qui m'interesserait ce serait un exemple de mise en oeuvre dans un cas précis (mais pas avec des pixels noirs à côté de pixels blancs, ça j'ai compris puisqu'on joue uniquement sur la luminosité en jartant la couleur du raisonnement. Mais dès qu'on doit croiser ça avec le rendu d'une couleur, je ne vois pas comment faire en utilisant des sous pixels monocolors) avec des schémas, comme sur le liens sur le subpixel rendering.

[edit : tiens, un bon exemple, ce serait la même chose que sur les liens du subpixel rendering : genre un A majuscule, mais jaune sur fond violet (oui c'est laid, mais c'est pour l'exemple :p).]

[edit2 : Si ça peut te rassurer, moi aussi j'ai l'impression de répéter plusieurs fois la même chose, et même pire, qu'on dit souvent tout les deux la même chose sans se comprendre.]

[JC Tergal]

Je te réponds en MP Akhoran parce-que là on est parti très loin je crois.