Reprise du message précédent :
Pour moi, c'est loin d'etre indispensable (si l'on pouvait éviter de reproduire les "faiblesses" du cinéma, ce serait même mieux). Pire que ça, dès que c'est utilisé c'est mal rendu, iréel, abusif et tue inutilement le framerate.

Du tout

On s'en bas les youk du filmréaliste, aux dernières nouvelles ont est devant un programme interactif donc la seule référence en terme de réaliste doit être la reproduction de ce qui est vu à travers nos yeux pas de ce qui est vu à travers une anthique caméra

Si on veut du film-réaliste déjà faut bloquer les fps à 24/s, avec 24 temps de noir

oui parce que jusqu'à présent on a eu du motion blur merdique
Le vrai motion blur n'est pas qu'une reproduction des faiblesses du cinéma mais bien une reproduction d'un phénomène biologique il est indispensable pour contourner les faiblesses d'un écran
 
la démo http://www.daionet.gr.jp/~masa/rthdribl/ m'a convaincu il y a un momen déjà

bah oui mais y a du motion blur dans nos yeux

Le processeur 3D R600 digne successeur du R300 selon ATI
http://www.onversity.com/cgi-bin/p [...] P=00000750

Qu'en pense le trolleur en chef d'onversity?

rien de neuf nan?
sinon c'est ça qui pourrait m'intéresser
http://www.matbe.com/actualites/13 [...] 600gs-agp/

C'est limite comme motion blur, on est plus proche de ce qu'on voyait sur Voodoo 5 que ce que proposent les jeux ajourd'hui.

non non carrément pas Sur voodoo 5 c'était une rémanence sur les frames déjà vues dans l'accumulation buffer comme beaucoup de "motion blur" dans les "vieux" jeux  ( Moto GP ... ) reconnaissable au fait que les frames les plus "vieilles" sont plus "transparentes" , là c'est une moyenne sur des frames intermédiaires comme un vrai motion blur, c'est bien plus proche de la réalité que les flous directionnels localisés des motion blur des jeux d'aujourd'hui
augmente le nombre de multisample
 
http://www.daionet.gr.jp/~masa/rth [...] /mb_01.jpg

Le motion blur n'est pas la reproduction d'un phénomène biologique (persistence rétinienne) mais la reproduction du temps de pose.
 
le temps de pose ayant son importance pour la lisibilité du mouvement par le cerveau. (qui est habitué au flou de mouvement dû à la persistence rétinienne dans la réalité)
 
ceci dit la persistence rétinienne est effectivement un comportement complexe: d'ailleurs est-ce la rétine qui a une persistence ou est-ce neuronal pour faciliter la réprésentation spaciale des objets en mouvements, ou une combinaison des deux c'est une question certes interressente. (vu qu'on a jamais pu poser un instrument de mesure entre l'oeil et le cerveau pour savoir où se situait la persistance)

le motion blur reproduit le temps de pose qui reproduit la persistence retiniene koi

Pourquoi essayer de "simuler" la persistence rétiniene ? Elle disparait quand on regarde un écran ? Je ne crois pas.
Le motion blur c'est le mal

parce qu'un écran à 60Hz et des jeux à 60FPS ne permettent pas aux yeux ( ou cerveau ) une persistence rétinienne continue ( encore moins les CRT où il y a des images noires entre chaque image ), en fait ça permet de pallier à cet échantillonage de l'animation ( y a une image toutes les 60 secondes au lieu d'un flux continu d'image ! ). Dans un jeu à 60 FPS motion blurré, nos yeux croient voir les animations intermédiaires entre chaque image alors qu'elles sont calculées et affichées sur une seule image

Le pb c'est qu'il vaut mieux ne rien mettre tant que ce n'est pas parfait, parce qu'en attendant ça attaque le cerveau.

je trouve le motion blur de fight night round 3 ou du jeu de zombie sur x360 très convaincant perso

 
"Jeux : L'Iran lance un jeu vidéo nationaliste"
http://www.infos-du-net.com/actual [...] video.html
 
vous allez voir que bientot ils vont faire une guerre preventive contre un pays parce qu'il fait des jeux video ou on tue des americains! ce qui est bien sur une honte car les americains sont tjrs les vaincqueurs puisqu'ils defendent la liberté
(rigolez pas pour ca qu'on peut pas jouer les Allemands nazis dans CoD    

 
Honnêtement je ne sais plus quoi dire en lisant ce genre de news sur Onversity tellement il y a d'erreurs grossières dedans  
C'est déprimant de retrouver ce genre de chose sur un site qui se veut au-dessus de la news de base en matière d'analyse.

Plutôt que de poster ca autant envoyer un mail à jf avec les dites erreurs, ce serait plus constructif

Je crois bien qu'ils s'étaient fachés et ont décidé de ne plus se parler, non ?

en même temps, on est sûr qu'au départ le temps de pose est là pour (enfin participe à) une bonne exposition de la pellicule/capteur.
la persistence rétinienne, il y a ptet un temps d'intégration des photons au niveau des cônes/battonnets et les neurones à l'autre bout, mais c'est pas sûr. (ça peut être aussi pour traquer plus facilement le mouvement d'un objet) enfin là on est pas neurologue. (déjà ptet qu'a ce niveau il y a des tas d'inconnues)

 
bah il a pas regardé le SDK, il code ptet pas en DirectX donc il fait une analyse détachée sans connaissance de cause et fait une confusion entre l'unification du jeu d'instruction des shaders vu du développeur et l'unification matérielle des différentes unitées et autres trucs...
a trop vouloir s'interresser à la théorie on peut faire des HS.

 
 
Comme d'hab je suis ouvert a toute amélioration de texte. j'attends donc tes remarques. Mais les lecteurs peuvent dès a présent vérifier la très grande majorité de mes informations depuis que j'ai systématisé depuis plusieurs mois la mise a disposion de liens multiples pour chaque actu. Pour cette actu il y en a 3 + une citation.
 
ps : je passais juste par ici pour t'encourager à m'écrire. Pour les discussions du texte lui-même l'email reste le meilleur outil.

 
DirectX n'impose pas d'architecture (matérielle), il impose des fonctionnalitées (architecture=implémentation de fonctionnalitées).
 
Direct3D 9 autorisait les fabricants a supporter tout ou partie du jeu de fonctions normalisé par l'API (via un système de "caps" qui permettent de déclarer ce qui est supporté par le périphérique).
 
Direct3D 10 impose de supporter tout le jeu de fonction de l'API.
 
Déjà en ça D3D 10 est une révolution avec ses avantages et ses inconvéniants (pas de rétro compatilibté avec du matériel D3D 9, mais fonctionnalitées garanties pour le développeur avec performances variables suivant le matériel D3D 10), il pose un nouveau référentiel 0.
 
---
 
Les shaders unifiés, c'est l'unification du jeu d'instructions, et donc des possiblitées calculatoires entre vertex, pixel (et geometry shader qui a été oublié, ceci dit j'ai regardé vite fait pour le geom shader il y a certainement des particularitées de jeu d'instruction pour supprimmer la primitive courante ou en créer d'autres ).
 
Ce qui différenciera toujours pixel, vertex, geometry shader, c'est la nature des données en entrée et en sortie.
 
accessoirement l'unification du jeu d'instruction imposé par l'API n'impose en rien de le faire ou pas au niveau hardware, il y a des particularitées propres aux pixels, vertex, et geometry shaders qui peuvent justifier d'avoir des unitées différentiées au niveau implémentation transistor (mise en pipeline, dépendances).
 
accessoirement perso je suis pour l'unification hardware, mais comme je se suis pas ingénieur chez ati ou nvidia, j'ai pas le liste de pour & contre, et comme en tant que développeur ça ne change -rien- à l'utilisation de D3D 10 ou 9, ça me traumatise pas qu'un constructeur ou l'autre fasse tel ou tel choix au niveau de l'implementation d'un jeu de fonctionnalitées.

 
Quand je vois des spécifications qu'un mec à balancé en spéculant sur un forum qui sont affichées telles quelles en affirmant que ce sont les spécifications de la puce c'est qu'on n'a pas envie d'être constructif
 
Je suis peut-être méchant mais bon à force de ne même plus avoir l'impression de retrouver le minimum d'éthique et de technique sur un site comme Onversity on perd l'envie de jouer au politiquement correct et de ne pas critiquer.

 
Non

 
Minimum d'éthique ? tu es qui pour dire des choses pareils ? Vraiment lourd.
 
je passe des architectures de processeur AMD, ATI aux plasmas des tokamaks en passant par la métathèse en chimie et les équations de l'effet de fronde gravitationnelle. C'est très complexe et je ne suis pas omniscient. Jamais je me suis venté d'être infaillible. Mais jamais non plus je n'ai refusé de corriger des erreurs si on me proposait des informations cohérentes. On contraire je suis très demandeur de la participations de tous.
 
Au lieu de dire des choses pareils n'était-il tout simplement pas plus simple de dire que tu ne voulais pas me donner ces informations. Ou ne rien dire du tout.
 
Mais je n'ai pas envie de me facher avec toi, même s'il y a des chsoes que je ne peux pas laisser dire.  

 
je me suis douté a travers une de tes remarques qu'il pouvait s'agir essentiellement de ce paragraphe. Je l'ai déjà modifié en mettant en avant une grande prudence dans mes affirmations. Avec ces infos complémentaires je vais pouvoir aller plus loin
 
Merci .

oki. ceci dit j'ai peut être fait des approximations aussi

C'est la non retro compatibilité qui me pose problème. C'est récent pour moi ça. Ca veut dire quoi ? que sous Vista on ne pourra pas executer des jeux DX9 ?
 
Pas de prob. l'idée c'est de donnéer une idée. la direction que suit DirectX 10 pas un article sur DirectX 10.

en fait comme j'ai dit sur le topic des Geforces 6/7 avec le modèle à 650€
 
quand tu fais un moteur avec Direct3D 9, tu as des capacitées d'exposées (des champs de bits que tu testes avec des masques pour savoir quoi est supporté).
 
sur qui fait qu'avec le Direct3D 9, le moteur peut savoir si la carte est matériellement Direct3D 7,8,9, et d'autres details, et peut donc basculer sa logique interne sur des techniques de rendu différentes (et compatibles avec le matériel).
 
Direct3D 10 n'autorise pas ce mécanisme et impose le support total des fonctionnalitées de l'API.
 
ça veux dire qu'un moteur codé avec D3D 10 ne peut pas s'adapter a du matériel 7,8,9 (donc le mec qui a acheté une carte D3D 9 à 600€ ou qui s'est fait un SLI/CrossFire en pensant rester compétitif face a une carte D3D 10 moyenne gamme peut se le .... dans le ....)
 
mais en contre-partie il (le moteur) peut piocher a tire-larigot dans les fonctionnalitées sans avoir à rencontrer du matériel ne supportant pas une fonction.
 
ce qui est potentiellement plaisant coté dev et qui devrait permettre enfin des expérimentations techniques sur un moteur de jeu en production.
 
en fait pour toute la vie du D3D 10, il n'y aura pas vraiment d'évolutions en termes de fonctionnalitées (le D3D 10 mets la barre assez haut), juste des évolutions de performances pratiques.

sinon pas de problèmes pour la rétro-compatibilité "applicatif", sous Vista avec une carte D3D 10, il n'y aura aucuns problèmes pour faire tourner un jeu D3D 7/8/9...
 
c'est la rétro-compatibilitée "materielle" qui est cassé (du materiel non D3D 10 ne donnera pas accès à un moteur D3D 10)

ouais enfin, c'est plutot une question de compatibilité ascendante là, la rétro compatibilité, ca voudrait dire que les cartes DX10 supporteraient pas DX9

 
Quelqu'un qui est déçu de retrouver les erreurs grossières (que ce soit technique ou transformation de rumeur en fait sans autre explication) des sites à news sur Onversity. Les retrouver chez quelqu'un qui a de la réflexion comme toi témoigne pour moi d'un manque d'éthique (de sérieux et d'objectivité).  
 
Le fait que tu confondes ROP et unité de texturing sur base d'une lecture vite fait d'un post sur B3D en est un exemple frapant.

heu ouais, enfin je me plaçais dans le référentiel du SDK

Enfin en meme temps on parle de ROP que depuis les GF6 ...

 
en fait comme j'ai pas du tout suivit les rumeurs de specs, j'ai même pas calculé

Spéculations : possible rachat d'ATI par AMD
http://www.presence-pc.com/actuali [...] ati-17235/

On est le 1er joint en même temps ..