Reprise du message précédent :
personne a nié le gain de vitesse entre la GF3 et la GF4...   ou t allé pecher ca ?
 
edit: et selon moi UT2003 a atteint le meme nivo que Quake3, c'est a dire une grosse daube qui sert a vendre un engine 3D. LE vrai jeux d'epic c'est unreal 2 faut arreter de faire semblant de pas savoir, mais bon vu que ut2k3 va surment etre utilisé comme bench et qu'il est estempillé du logo de nvidia (donc pour hardcore gamers ) sa en fait surment un tres bon jeux    
 
c'étais mon coup de gueul pour ut2k3

Va être updaté pour UT 2003.
 
Pour Doom3, tu te base sur un plan qui date d'enore plus loin où les drivers étaient encore moins optimisés. ATI a commencé à vraiment travailler avec Carmack qu'à partir de Janvier février (mauvais point).

###
Pour Doom3, tu te base sur un plan qui date d'enore plus loin où les drivers étaient encore moins optimisés. ATI a commencé à vraiment travailler avec Carmack qu'à partir de Janvier février (mauvais point).
###
 
Je veux une source pour pouvoir te croire.
Je te signale que tous mes extraits du .plan de Mr Carmack date de Fevrier 2002. Et que le contact entre ATI et Id existait deja avant comme on peut le voir ici
 
###
My judgment was colored by the experience of bringing up Doom on the original
Radeon card a year earlier, which involved chasing a lot of driver bugs. Note
that ATI was very responsive, working closely with me on it, and we were able
to get everything resolved
###
 
Edité: Je rajoute encore une fois le lien du .plan :
http://www.webdog.org/plans/1/

ATI venait juste de commencer à bosser avec Carmack. Faut vraiment être naïf pour croire que des drivers ça se bosse en 2-3 semaines.....
 
Sinon, l'article a été updaté avec tes renseignements les plus objectifs...
 
Le .plan dont tu parle mentionne ceci avant ton passage, montrant qu'ATI n'avait pas encore réellement commencé à travailler avec Carmack sur le Radeon 8500.
 

 
Il dit aussi ceci :
 

 
ça faisait une paire de mois que ATI leur demandait de faire des tests... Carmack s'est finalemnet décidé et a mis à jour des bugs qu'ATI a commencé à corriger le plus rapidement possible....
 
Donc, tu vois, considèrer dans les pefs un .plan qui date juste du début du réveil de Carmack face au R8500 alors qu'il a utilisé quasi exclusivement du nvIDIA avant..... C'est un epu chaud, non ?
 
Par là je veux aussi souligner le fait que extraire un paragraphe d'un tout sans replacr le paragraphe dans son contexte, ça permet de lui faire dire pas mal de choses.....
 
Effectivement, si on ne tient compte que de ton paragraphe, tu as raison, le problème est que Carmack a un peu plus parlé que ça ce jour là.

Mwouais ...
 
Sorti des débats de tétracapiliculteur, je dirais que l'avenir est pour les PS 1.4 ... et que dans cette optique la R8500 est plus pereine que la concurrence.
 
[IRONIQUE] Maintenant, faut m'expliquer la différence entre une rés de 1280 et une de 1600 (différences visuelles), et puis aussi celle qu'il y a entre 90 FPS et 100 FPS sur des écrans qui rafraichissent à 75 ou 85 Hz (sans synchro verticale bien sûr) ....

 
nan c 1.4  et les gf3 et 4 font 2 passent

TNZ a écrit a écrit : Mwouais ...   Sorti des débats de tétracapiliculteur, je dirais que l'avenir est pour les PS 1.4 ... et que dans cette optique la R8500 est plus pereine que la concurrence.   [IRONIQUE] Maintenant, faut m'expliquer la différence entre une rés de 1280 et une de 1600 (différences visuelles), et puis aussi celle qu'il y a entre 90 FPS et 100 FPS sur des écrans qui rafraichissent à 75 ou 85 Hz (sans synchro verticale bien sûr) ....

 
 
ya moin de baisse de fr stoo.
 
si on était kapable de faire du 85 fps konstant ca serait le reve.....

Ben avec des moteurs 3D multi threadés C possible !
 
Seulement pour ça faut que les programmeurs enlèvent leurs moufles et fassent de la programmation temps-réel (CàD synchronisée, multi tache, multi threads (et/ou multi process pourquoi pas) avec l'utilisation de mémoires globales etc ...

 
Ouais mais les effets sont archis simplissimes. Résultat, les GF4 se tapent quand même une passe. Ce sont des effets de niveau 1.3.

 
je sais pas pour ATI, mais je sais que chez nVidia ils utilisent une unité de symulation matérielle (l'Ikos Box je crois), et des drivers sont écrits avant même que des samples sortent de chez TSMC.
 
Ceci dit y'a une différence entre avoir une base fonctionelle, et avoir des drivers optimisés et débuggués

 
[BIS MOD ON]
nan c du 1.4  et les gf4 font 2 passes  
dixit MR madonion himself.
 
 
l aventage du ps 1.4 cai aussy d apliker + de textures en 1 passe.

le .plan date c affreux
y'a rien rien rien sur les évolutions depuis l'été:
RV250 et R300 et NV18/NV23
je suppose qu'il *attend* la dispo publique du NV30 mais bon

 
oui mais si l'effet nécessite un nombre de textures < au nombre max des 1.3, alors que ta carte fasse du 1.3 ou du 1.4, elle fera le même nombre de passes, même si c'est codé en 1.4. Et c'est là que la bat blesse, même si c'est codé en 1.4, et bien il manque la complexité des effets... Même en pixel shaders 2.0 tu pourras faire une réfraction simple, et toutes les cartes le feront à la même vitesse même si c'est du 2.0 tout simplement parce que l'effet est archi cimple. C'est tout. Y'a pas à chercher plus loin, ni midi à 14h.

Oxygen3 a écrit a écrit : le .plan date c affreux y'a rien rien rien sur les évolutions depuis l'été: RV250 et R300 et NV18/NV23 je suppose qu'il *attend* la dispo publique du NV30 mais bon

 
c'est un epu ce qe je soulignais... Se baser sur des plan qui datent..... (j'avais au moins dit que je parlais de théorie et que POUR L'INSTANT la pratique ne collait pas.....

ben oui personne na dit le kontraire.

magisim a écrit a écrit :     Le reviewer avait dû oublier de règler le post filter sur sharp et high...... Non, parce que j'ai jamais vu Unreal aussi pourri sur V3... Et on ne peut se fier à des captures d'écran pour apprécier le post -filter d'une V3, car l'image finale n'est que dans le Ramdac. En prenant un snapshot du framebuffer si c'est déclaré en 16 bits, tu as une reconversion en 16bits vrais à l'arrachée, quelque soit le soft de capture....... L'image final e n'est PAS dans le frame buffer. Y'a eu le même pb avec les V5..... C'est bien gentil les comparos screenshotiens, mais ça tient pas forcément compte de tout......   C'était la grande époque de Q3 où les nVIDIOTS lèchaient le ciel parce qu'il était plus beau sur les screenshots mais le viraient dés que possible parce que ça faisait ralentir le jeu......

ben oui, Marc ne fait des tests qu'avec des screenshots, il ne regarde jamais son écran donc il ne voit pas que l'image est sublime  
 
 
P.S. je devais être un nvidiots à l'époque puisque je jouais à Q3 avec un ciel en 32bits sur ma TNT

 
Si, Mr THOT.

mareek a écrit a écrit : ben oui, Marc ne fait des tests qu'avec des screenshots, il ne regarde jamais son écran donc il ne voit pas que l'image est sublime       P.S. je devais être un nvidiots à l'époque puisque je jouais à Q3 avec un ciel en 32bits sur ma TNT

 
Ne pas généraliser. Après, y'a les considérations personnelles. Reste que le niveau qu'utilisait Marc, je l'avais téléchargé, et jamais, ô rand jamais j'ai vu un bnding aussi fort sur ma V3.... mais postfilter règlé correctement.
 
Pour les utilisateurs de TnT, il ne faut pas généraliser...... Mais j'ai effectivement connu ça sur 3dfx Attack des nVIDIOTS finis au sens premier du terme qui vantaient le 32 bpp sur le ciel dans Q3 et jouaient sans le ciel..... MAIS, ils ne sont pas la majorité, heureusement...... Tout comme il n'y a qu'une majorité qui va désactiver des options graphiques dans UT 2003 pour passer de 60 à 120 fps par ex.......

 
Pour UT, je me demerde pour avoir au moins 80 fps, histoire de pas tomber en dessous de 30 dans les passages vraiment chauds, surcharges en roquette, et ainsi me dire : merde, ca a lagge, j'ai pas pu faire ce que je voulais).
 
J'ai des souvenirs de UT premier du nom en instagib... maman
 
Bref, 60 fps, pour les fps, c'est loin d'etre la panacee pour moi.
 

Môssieur Magicsim...
 
Ce que j' essayais de te faire comprendre, c'est que tu ne peux absolument pas prédire les performances de n'importe quelle carte dans Doom3 que ce soit d'un point de vue théorique ou pratique.  
 
Tu dis :
###
En gros, même si dans le meilleur des cas un GF4 Ti 4600 (reviews les plus optimistes) était à 160% de la vitesse d'un R8500, sous Doom3, il ne tournerait qu'à 80% de la vitesse d'un R8500 !  
###
 
Désolé mais c'est du PIPEAU. T'en sais rien, zéro, nada
Alors que moi je te montre un .plan ou le developpeur de Doom 3 estime que la radeon 8500, niveau performances sera grosso modo équivalente à une GF3, donc inférieure à une GF4.  
 
Tu dis aussi
 
###
Par là je veux aussi souligner le fait que extraire un paragraphe d'un tout sans replacer le paragraphe dans son contexte, ça permet de lui faire dire pas mal de choses.....  
###
 
Et les liens dans mes posts, tu t'imagines que je les mets pour quelle raison ? Pour faire joli ? Justement c'est pour que tu puisses te réferer au texte complet. Texte qui serait trop long à poster en entier sur ce forum.
 
 
A part ca, l'avenir des pixels shaders n'est évidemment pas le PS 1.4. Ca c'est deja de l'histoire ancienne, l'avenir c'est le PS 2.0. Et j'ose espérer que Nvidia va pas nous faire le coup d'un PS 2.X juste pour se venger
 

mareek a écrit a écrit :  c'est le multicrepe tefal powwaaaa

 
 
C'est Bilig powered        
 
 
 
Pour en revenir au debat bien que je sois quand meme bien a la rue niveau explications techniques, y a ce petit bench e Marc qui m'intrigue. C'est de l'Aquanox, donc a priori massivement DirectX 8 et donc les shaders qui vont avec.
 
On voit que les 8500(LE) sont un cran au-dessus des GF 4 Ti 4200 qui pourtant les laisse bien derriere d'habitude.
 
Ca devrait avoir un lien avec tout ce qu'il sait dit ici et dans l'article de Magisim. Un debut de justification en tout cas (si je suis pas completement a cote de la plaque  )
 
Source : http://www.hardware.fr/articles/433/page11.html
 

Tout à fait conforme à ce que j'avais deja vu sur d'autre sites...Mais il me semble que les shaders utilisés ici sont encore de type "simple" c'est à dire inclus dans directx 8 et non DX8.1 (pixel shader 1.1). Donc en 1.4, l'écart sera encore plus grand... (attente confirmation).

 
En efet, tu mets bien les liens vers tes sources, mais tu ne te base que sur les paragraphes que tu cite.
 
Alors que ceci, sortis de leur contexte comme tu le fais déforment la réalité.
 
La réalité était que Théoriquement on devait avoir ça mais dan sla pratique, on ne l'avait pas parce que Carmack avait juste daigné jeter un coup d'oeil aux R8500.
 
Sinon, le nV30 est bien parti pour supporter les PS 2.0+ (comme on les appelle). plus d'instructions, etc. Sinon, tu as raison, l'avenir est aux PS 2.0 et à leur compatibilité/capacité à parler aux cartes dans leur version de shader si elles sont < ou = aux PS / VS 2.0.

 
Oui, c'est u_n des rares cas où la pratique rejoint d'assez près la théorie. A noter que tout de même Aquanox aura plus servi de bench pour les shaders que comme jeu. Sinon, bien vu SullivanXP et Ernestor.
 
Au départ Aquanox/mark ramait comme pas possible sur R8500 car utilisait les extensiosn nVIDIA seulement. Depuis la version 2.3, ils ont aussi optimisé pour les R8500 avec leurs instructions.
 
Chose que n'avait pas encore vraiment fait Carmack dans le plan que Thot n'arrête pas de citer.... Et le pire, c'est que Carmack avoue lui-même que ça faisait un bout de temps que ATI grondait pour qu'il se bouge le fion.

La theorie et la pratique s'equilibreront quand les programmeurs trvailleront d'avantage  avec les radeons. Ca s'éuilibre peu à peu.  
Remarque : J 'ai verifié les dates
Quand Carmack a dit que les GF4 resteraient superieures aux Rad à cause des drivers limite en Ogl des radeons, c'etait AVANT les catalysts (quelques jours d'intervalles) . Pour avoir testé quasiment tous les pilotes, je peux dire que les 2.2 ont été un bond en avant terrible en Ogl. A ce moment on va vu les R200 se rapprocher beaucoup des GF4 (voir depasser dans JK2 et RTCW )
Alors ON VERRA BIEN POUR CE DOOM III. un peu de subjectivité c'est dur c'est dur ...

Ici jusqu'a présent on parle d'appli tournant sous directx (8.x, 9)
Mais il y a eu une news assé interessante sur 3dchips...
 
 

 

 
Enfin je sais pas vous, mais j'ai toujours trouver que les jeux tournant sous opengl était dans la plupart des cas plus beau et plus fluide que sous directx!
 
Et qu'en est'il des pixels shaders dans l'opengl actuel (geforce3/4, radeon 8500 et +) ?

 
dx9 devait renverser la tendance

 
oui mais bon lors de ses premiers essais, le driver opengl de la radeon8500 n'était pas capable de traçer la console correctement.
alors il a dû un peu se vexer

[mode je troll + je fais des generalisation à 2 balles ON]
c'est marrant, tous les fanatiques de 3DFX ne veulent jamais reconnaitre que les voodoo 3 et 5 étaient pourries    
[mode je troll + je fais des generalisation à 2 balles OFF]
 
Sans rire, quand je poste des screenshots où on voit que le FSAA de la voodoo 5 rends l'image toute floue (beaucoup plus que les FSAA des radeon et geforce 2), les nostalgiques de 3DFX me disent que ça vient des réglages et que le testeur ne sait pas régler sa carte. Quand je poste des screenshots qui montrent que le 16bits amélioré de la voodoo 3 ne vaut pas mieux que le 16 bit des autres cartesles nostalgiques de 3DFX me disent que ça vient des réglages et que le testeur ne sait pas régler sa carte.  
Je veux bien vous croire les gars, mais faudrait me prouver que Marc et Anand sont dezs brèles qui ne savent pas régler correctement une CG.

trop cool, un document marketting de nvidia qui ne donne aucune information technique  

ça dépends beaucoup plus du programmeur que de l'API utilisée.

Disons qu'à ces débuts Direct X 5 et 6 étaient de grosses usines à Gaz, et direct 3D en retard par rapport aux possibilités et à la vitesse des librairies Open GL.
 
Maintenant je pense que ce retard est comblé (ou presque)

 
ouais depuis dx7 il me semble, direct3D est passé devant opengl au niveau des fonctionnalités ( voir des performances koi ke pas sur) d'ailleurs opengl 1.2 ne gére pas les shaders. Opengl 2 devrait changer tout ca mais il a été maintes fois retardé... pourrait on y voir un lien avec le fait que microsoft fasse partir du groupe qui le dévelloppe  

cai fini ?

mareek a écrit a écrit :   [mode je troll + je fais des generalisation à 2 balles ON] c'est marrant, tous les fanatiques de 3DFX ne veulent jamais reconnaitre que les voodoo 3 et 5 étaient pourries     [mode je troll + je fais des generalisation à 2 balles OFF]   Sans rire, quand je poste des screenshots où on voit que le FSAA de la voodoo 5 rends l'image toute floue (beaucoup plus que les FSAA des radeon et geforce 2), les nostalgiques de 3DFX me disent que ça vient des réglages et que le testeur ne sait pas régler sa carte. Quand je poste des screenshots qui montrent que le 16bits amélioré de la voodoo 3 ne vaut pas mieux que le 16 bit des autres cartesles nostalgiques de 3DFX me disent que ça vient des réglages et que le testeur ne sait pas régler sa carte.   Je veux bien vous croire les gars, mais faudrait me prouver que Marc et Anand sont dezs brèles qui ne savent pas régler correctement une CG.

 
1 : pour les V5 : oui sur un screen tu vois un effet de flou, et c'est normal, mais, quand ton jeu bouge, le flou tu le vois moins, par contre, ce qui te saute aux yeux, c'est de ne plus voir de pixel popping. Au final, l'impression en est améliorée de beaucoup (niveau limites de polys ou moirages).
 
Pour le filtre 16bpp des Voodoo3, je le dis et je le répète, et c'est pareil pour les V5, AUCUN logiciel de capture d'image ne capture correctement en 16bpp sur ces cartes.
 
Pourquoi ?
1 : l'image est déclarée être du 16bpp mais traitée en interne en + (je ne sais plus si c'est 22bpp, 32 bpp ou autre).
2 : l'image est envoyée telle qu'elle en sortie de pipeline ou elle subit un filtre de passage en 16bpp avec le moins de pertes possible (donc pas de vrais aplats).
3 : le soft capture AVANt le filtrage en 16bpp vrai. Il fait des approximations en 16bpp grossières.
 
Les résultats finaux sur écran et sur le screen apparaissent comme suit ou après peu près comme ceci.... (Simulation grossière mais plus réaliste qu'un bête screen !)
 

(obtenu à partir d'un sample 32 bits de ciel dans DM-antalus sous UT 2003 downsampling à 32 couleurs en pattern [colordiffusion de la Voodoo3/4/5]C'est ce que l'on verrait à l'écran, à peu près.... Disons théoriquement, l'aspect sera de plus ou moins ça parce que je ne connais pas la conversion photoshopienne et en plus le nombre de couleurs est en 16bpp à palette non adaptative, pas comme ici.).  
 

(obtenu à partir d'un sample 32 bits de ciel dans DM-antalus sous UT 2003 downsampling à 32 couleurs sans filtrage + mêem remarque qu'en ahut. A part qu'ici c'est ce que verrai le soft à screenshot, ou la fonction screenshot d'un jeu).
 
SI 3dfx a fini (trop tardivement) par incormporer une fonction screenshot dans ses drivers, il y a bien une raison, et les résultats sont très différents.
 
Moralité, je ne dis pas que les reviewers sont des empotés, je dis juste que screenshotés et montrer sur des screenshots, c'est réducteur. Pareil pour le FSAA, sur un screen, ça ne veut rien dire. Un jeu c'est fait pour être animé, donc il faut voir le résultat en mouvement.
 
Pour le sample en 32bpp, tu lance UT 2003 et tu regarde le ciel.
 
Pour finir, si le FSAA de 3dfx te gènait car trop, c'était aussi un peu normal, rien qu'un FSAA 2x avait la qualité d'un FSAA 4x de la concurrence (RGSS inside). Alors comme un FSAA 4x équivalait à un FSAA 16x en qualité, c'et très normal que cela t'ai pru "flou". Reste que plus un FSAA est puissant plus il génère un flou sur les screenshots. Maintena,t, ce flou, tu ne l'aperçoit plus en jeu. Ah, et ça sert à rien de jouer au guignol avec une loup ou un zoom sur des screens pour voir les "défauts", c'est pas zoomé sur un 10ème de l'écarn qu'on joue, c'est bel et bien en plein écran.
 
Pour en revenir au 16bpp 3dfx, certes c'est pas du 32bpp, mais au moins ça s'en rapproche sacrément (sauf si tu joue à screenshotmark), sans en avoir l'impact de perfs. C'est tout.
 
Et à part le non support t&l, très important dans treemark et 3dmark.... et rien d'autre pour l'époque, je vois pas ce que la V5 avait de pourri...... même les grosses textures non gèrées par le V3 (à part qq unes très rares dans Q3), il a fallut attendre un bon bout de temps pour les voir.
 
Au fait, le T&L, commence à peine à devenir utile (en dehors des fins benchmarkiestes). Parce que même avec le T&L, faut un gros CPU.

A propos de 3dfx pour avoir possede une V5 et maintenant une GF4, je peu affirmer que la qualitee d'un jeu glide (16 bits) comme operation flashpoint sur une V5 et du meme jeu sur une GF4  en 32 bits n'a rien a voir.
Je n'ai jamais retrouve la meme qualitee au niveau du rendu des couleurs de la V5.Je ne parle meme pas de l'aa qui a commence a etre apporche en terme de qualitee uniquement avec la GF4...
 
Pour se faire une idee des chips qu'avait en preparation 3dfx et des raisons de son declin je conseil vivement cet article:
 
http://firingsquad.gamers.com/hard [...] efault.asp

Arf, enfin quelqu'un de censé...... et au fait, pour égaler la qualité d'une V3/5 sur UT  en Glide 16bpp, fallait quand même qu'une GF tourne en 32 bpp, parce quen 16bpp mon dieu l'horreur (mais bon, UT était à la base optimisé glide aussi).....

 
waaaa!!!!      
 
kelkun ki parle vrai!!!    

en parlant de FSAA je trouve que ca fait un effet de flickering dans les jeux