r.chatigré

Blazing star (Neo Geo)?

Si tu proposes le 2 un jour, tu mettras Stan STP 🙂

Comme dirait l'autre, Bernard-je-fronce-les-lunettes: "This is all too easy" Donc: Yes.

3, 2, 1...

A cause de la flèche et du design, je dirais Action Fighter. Une version Master System peut-être?

Si j'ai bien compris, tu avais un répertoire dans ton /home qui était visible depuis tes machines virtuelles Windows? Dans ce cas ça devait passer par Samba sous ton linux pour partager le dossier. Le fait que les partages soient visibles montrent que Samba est toujours configuré. Les raisons qui peuvent te bloquer: Le login & mot de passe de l'utilisateur windows ne fonctionnent plus sur Linux Le login de l'utilisateur Windows n'a pas de droit sur le répertoire Samba n'a pas de droit sur le répertoire Tu pourras trouver des logs dans /var/log/samba

Oui! Pour ce que j'en ai fait, sympa, mais je ne l'ai pas fini.

Allez, tous à vos enquêtes pour trouver ce jeu:

CryoFall?

Yes! No! (hé hé)

Un fastoche totoches!

"C'est étrange, du coup tu es sur une résolution de timer à 1ms avec ou sans latencymon...." J'ai relu le thread, et du coup je suis aller creuser certains points. Ryzen balanced: tu n'as plus ce profil qui te permettait de limiter (résoudre?) le problème. Ryzen balanced est basé sur un idée simple: maintenir TOUS les coeurs actifs même quand ils n'ont rien à faire. Ce qui correspond un peu au fait que si tu as plus de charge, tu as moins le problème. Je me demande si on ne pourrait pas "pinner" le processus de l'emulateur sur seulement 1 ou 2 CPU (cf How To Force Windows Applications to Use a Specific CPU (howtogeek.com) objectif: maintenir la charge sur 1 coeur en évitant aux threads de "s'étaler", afin que le CPU ne baisse pas de vitesse ou autre. Je chercher une solution qui ne demande pas de modifier la config du PC juste pour l'émulateur, donc une solution qu'on pourrait n'appliquer qu'à l'émulateur. J'ai aussi regarde rle code source de l'émulateur PPSSPP pour sa partie windows: pas de trace de SetTimerresolution -> je suppose qu'il tourne bien par défaut à 8 ou 16ms sur les orids des testeurs. Par contre: j'ai relu 2 fois qu'utiliser PCSX2 depuis retroarch ou un autre limite le phénomène de stuttering - j'imagine que soit retroarch maintient une charge, soit il a une config par défaut qui limite le problème. Dans tous les cas, ton ordi est très largement suffisant pour faire tourner ces émulateurs. Tu es plus dans le cas des programmes qui ne supportent pas les ordis "trop" performants (ou là: "trop" évolué)

C'est étrange, du coup tu es sur une résolution de rimer à 1ms quelque sit latencymon.... Latencymon est un truc bizarre: il s'immisce dans windows en tant que pilote pour mesurer les autres pilotes.. Il n'y a pas de raison qu'il flluidifie quoique ce soit (ou alors avec des scénarii tirés par les cheveux avec les J'ai du mal à faire le point sur ta config (PC et émulateur). Sur l’émulateur, tu es bien en vsync et l'écran est en 60hz fixe (pas de gsync ou autre taux de rafraîchissement variable)? As-tu tenté sans antivirus (c'est pas bien, mais les émulateur font de la compilation à la volée,ce qui ne plaît guère aux antivirus)? As-tu tété en lançant l'émulateur en tant qu'admin?

Du coup le résultat c'est avec latencymon en fonctionnement?

Pour vérifier, peux-tu donner le résultat de ceci (il faut le mettre dans un fichier powershell et le lancer en ligne de commande powershell) avec l'émulateur lancé avec ton utilitaire latencymon lancé (il faudra peut-être à l'invite powershell lancer la commande "Set-ExecutionPolicy -Scope Process Unrestricted" ) # # # Set-ExecutionPolicy -scope Process Unrestricted Param ([int] $resolution=-1) Set-StrictMode -v 2 $TimerResolutionApis = @' [DllImport("ntdll.dll", SetLastError=true)] public static extern int NtSetTimerResolution(long DesiredResolution, bool SetResolution, out ulong CurrentResolution); [DllImport("ntdll.dll", SetLastError=true)] public static extern int NtQueryTimerResolution(out ulong MinimumResolution, out ulong MaximumResolution, out ulong CurrentResolution); '@ $NtDll = Add-Type -MemberDefinition $TimerResolutionApis -Name 'Time' -Namespace 'NtDll' -PassThru # Vieux monde: ulong=32 bits, le 64 bit est le type "longlong" [uint32] $result = 0 [uint32] $minResolution = 0 [uint32] $maxResolution = 0 [uint32] $curResolution = 0 [NtDll.Time]::NtQueryTimerResolution([ref] $minResolution, [ref] $maxResolution, [ref] $curResolution) Write-Output "Result: $result" Write-Output "Min: $minResolution" Write-Output "Max: $maxResolution" Write-Output "Current: $curResolution" if($resolution -ge 0) { [uint32] $targetReso = $resolution Write-Output "Trying to set resolution to $resolution" $result = [NtDll.Time]::NtSetTimerResolution($targetReso, $true, [ref] $curResolution) if ($result -ne 0) { Write-Error "NtSetTimerResolution failed ($result)" } Write-Output "Current: $curResolution" }

Arf, le copier coller depuis le tel... https://youtu.be/X3ZmmebE-Kw

Je ne sais pas ce que ça vaut...

Skully?

A ben oui... logique... Mon problème, c'est qu'il est impossible de conseiller de changer d'ordi comme tu le sous-entendais car on ne sait pas ce qui cause le problème - ou plutôt le triplet écran/CG/driver peut être le problème et changer l'ordi ne le résoudra pas forcément. Finalement, sur mon fixe j'ai le 59.94Hz: c'est une TV, si je ne la met pas en mode "ordi", le 59.94Hz apparaît mais en entrelacé. --> Est-ce que logistiquement c'est possible de tenter l'expérience avec l'ordi branché sur une TV? J'ai lu aussi que certains ont des résultats en utilisant retroarch et le moteur ppsspp. Et à priori, PPSSPP peut fonctionner sur une RPI... Qui est plus maniable côté rafraichissement.

Je ne pense PS que la CG soit vieille. Ces émulateurs marchent sur à peu près n'importe quoi depuis des années. Je pars donc sur une autre piste (enfin je reprend une ancienne avec d'autres éléments): Dans ce thread reddition, le gars signale du stuttering avec handbrake à cause du déport de tâches sur les efficiency cores

Je reste convaincu du problème plutôt soft, mais qu'un tout petit changement a déclenché. J'ai recreusé des posts sur PPSSPP et PSCX2, les deux ont des réponses même par les développeurs incriminant surtout le taux de rafraichissement de l'écran et Windows (Linux dans une moindre mesure si on n'a pas les patch realtime). Les posts sont réguliers de 2013 à aujourd'hui (en 2014, 2015, 2017, 2019...) et quelque soit la puissance de l'ordi ou de la CG Dans une réponse de 2017, pour eux le problème est dans la cadence de rendu interne à 59.94Hz et les écran en 60Hz/75Hz. Le problème s'atténue à 120Hz, mais dans ce cas on reste bloqué par la précision de 1ms de Windows. As-tu moyen de caler ton rafraichissement d'écran sur un mode 59.94Hz? (moi je l'ai sur la carte Intel HD de mon portable par exemple, mais pas sur mon ordi fixe en AMD)

Elle touche VIA les entretoises (on voit généralement la ligne de masse sur une couche du dessus ou dessous. L'isoler l'exposerait à des interférences par ondes à l'intérieur du boitier. Effectivement, elle ne doit pas toucher le fond pour ne pas court-circuiter les pattes qui dépassent en-dessous. L'IO Shield EST conducteur et maintient le pourtour des prises VGA/USB/HDMI et le boitier en contact pour que tout soit à la masse pour éviter les interférences, les étincelles et les courants fuyants... Si on essaie d'isoler la CM du boitier, c'est une GROSSE erreur.

Ca se vérifie facilement 🙂 La CM devrait être reliée au chassis: par les vis par la masse de l'alim elle-même reliée au chassis par le "backplate" métallique à l'arrière Si le grésillement survient sur un casque filaire la masse peut être en cause. Si le grésillement survient sur un lien bluetooth, un problème d'interférence ou de pilote peut être en cause.

Ok, donc ce sont bien des grésillements analogiques, on peut oublier ce que j'ai dit avant. Il faut mettre ton ordi à la masse, tu as peut-être des rondelles isolantes qui isolent ta CM de la carcasse, des trucs du genre. Un petit bout de fil devrait régler ce problème de grésillement, ou alors tu as un problème de terre sur ta prise électrique.