brice.wernet a écrit :



C’est plus ou moins le cas, ça fait un temps de réponse de l’ordre de 16ms.

Toutefois, dans ces vieilles consoles, le processeur chargé de l’affichage des sprites pouvait avoir sa propre latence et là je n’ai aucune estimation.



Il y a quelques années, un site français (hardware.fr je crois) avait montré que selon la chaîne souris/ordi/écran, le temps de latence pouvait monter à 160ms dans un FPS.



Par ailleurs, en analogique, tu étais sûr qu’un “pixel” sorti de la console était affiché immédiatement: à part quelques TV 100Hz (qui grâce à des mémoires spéciales préservait toutefois cette synchro), aucune TV ne mémorisait l’affichage.

De nos jours si tu ne désactives pas tous les effets de upscaling, flou ciné, contraste dynamique (basé sur la totalité de l’image en général, donc attendant la fin de l’image pour changer le contraste affiché), … de ta TV, tu ajoutes un décalage dans l’affichage (parfois de l’ordre de 1 ou 2 images soit 16 ou 32ms).



Sur un ordi, certains pilotes de joystick “adoucissent les mouvements”, souvent avec une moyenne de la valeur précédente -> latence.



Actuellement, la vitesse des bus et du traitement des entrées, ne doit pas poser problème. peut-être les manettes en bluetooth posent problèmes, car il ne me semble pas que les périphériques d’entrée bluetooth soient très réactifs (exemples: certains clavier bluetooth “ratent” des touches).





16ms environ 1/60ieme de seconde, ou une frame (sur les console non européenne). D’après ce que j’ai pu comprendre des TAS, c’est que les touches sont testé à chaque frame (seul les touches utiles à cette frame), donc oui, on est dans l’ordre de l’unité de temps pour une console de cette génération.



Pour la latence de l’écran, les téléviseurs actuels peuvent avoir un mode “jeux” qui règle se problème de latence bien réel (qui dépasse les 100ms facilement). Pour voir ça, il suffit de brancher son ordi et faire bouger son curseur.



Sinon, pour tes chiffres, je crains que les conditions soit vraiment mauvaise, un jeux vidéo avec des paramètre réglé avec les pied, genre un V-sync activé sur un CG trop peu puissante. Une tel latence se sens et c’est presque injouable (en plus d’un frame rate proche d’une projection d’une séance de diapo.)

Je pense qu’avec un matos “moyen” actuel, la latence doit tourné au plus à 30ms.

Dr.Wily a écrit :



Intéressante cette new ! En fait le type n’a tort. Si on compare une NES aux machines d’aujourd’hui ça n’est plus vraiment la même façon de penser électroniquement parlant.



Si en terme de puissance de traitement il est évident qu’une 3DS est largement au dessus d’une NES, ce n’est pas forcément le cas au niveau de la réactivité.



La plupart des consoles modernes depuis les PS360 ont largement perdu en temps de réponse. Peu être que Koichi Hayashida a besoin d’un hard proposant des timing précis pour son jeux.



Toutes les machines d’aujourd’hui sont à la ramasse par rapport à une NES ou tout autre console de cette même génération concernant l’input lag.





C’est selon moi la seul explication que j’aurai pour ce “manque de puissance”. La NES et la super NES étaient des consoles pensées pour faire de la 2D par sprite et un calcule basé sur la notion de frame-rate fixe (50 ou 60 FPS selon la région, mais souvent le jeu était pensé à 60 FPS, la conversion à 50FPS n’était pas faite réellement).

Je ne crois pas que ces consoles était doté d’un tampon d’entrée, la manette devait être directement “branché” aux unité de calcule, a chaque frame, les entrées était testé.

En ajoutant des couches logiciel entre le matériel d’input et le programme de la ROM on créer un lag qui peut être variable avec l’occupation du processeur.

En gros, voici le modèle des “vieilles consoles 8/16bit”

manette—>unités de calcule/1frame fixe—>sortie : beaucoup d’électronique pur et du monothread

Et voici le modèle actuel tiré du PC/émulateur

manette—>BusIO–>pilote/systeme (Buffer?)–>émulateur—>rom—>carte graphique—> sortie : beaucoup de logiciel et du temps réparti