ArcadeItalia.NET

Uso felicemente le JammASD (V2 e V3) da molti anni, preferendole alle JPAC per via dell'amplificatore del suono integrato.

Recentemente sono stato informato che la V3 è stata inclusa nel database di MisterAddons, classificata all'ultimo posto della lista per latenza di input. Secondo il tester, è il peggior codificatore di joystick che hanno testato.

Questo non ha alcun senso. È ampiamente noto che per far funzionare i fucili leggeri è necessaria la stessa risposta del frame.

Qualcuno ha prove contrarie? La comunità di lingua inglese ha sbagliato?

https://misterfpga.org/viewtopic.php?p= ... 33fe#p9653

https://docs.google.com/spreadsheets/u/ ... M/htmlview

(Inglese originale nello spoiler)

Basta attendere @picerno

cools ha scritto: ↑10/03/2022, 21:24 Uso felicemente le JammASD (V2 e V3) da molti anni, preferendole alle JPAC per via dell'amplificatore del suono integrato.

Recentemente sono stato informato che la V3 è stata inclusa nel database di MisterAddons, classificata all'ultimo posto della lista per latenza di input. Secondo il tester, è il peggior codificatore di joystick che hanno testato.

il ritardo esiste e per una certa quantità è stato inserito di proposito. nella scheda è implementata una routine antirimbalzo di 15ms che evita falsi eventi dovuti a rimbalzi delle linguette dei microswitch (che durano fino a 10ms) e a disturbi generici. inserire una routine antirimbalzo sugli ingressi digitali è quasi d'obbligo per un firmware professionale. il ritardo inserito evita tanti problemi e non credo possa essere avvertito dall'uomo senza gli strumenti elettronici che hanno adottato per quei test

cools ha scritto: ↑10/03/2022, 21:24 Questo non ha alcun senso. È ampiamente noto che per far funzionare i fucili leggeri è necessaria la stessa risposta del frame.

per quanto riguarda le lightgun, la scheda non ne influenza il rilevamento perchè adatta solo il segnale di sincronismo senza introdurre nessun ritardo

picerno ha scritto: ↑16/03/2022, 13:05 il ritardo esiste e per una certa quantità è stato inserito di proposito. nella scheda è implementata una routine antirimbalzo di 15ms che evita falsi eventi dovuti a rimbalzi delle linguette dei microswitch (che durano fino a 10ms) e a disturbi generici. inserire una routine antirimbalzo sugli ingressi digitali è quasi d'obbligo per un firmware professionale. il ritardo inserito evita tanti problemi e non credo possa essere avvertito dall'uomo senza gli strumenti elettronici che hanno adottato per quei test

Questo vale anche per la vecchia interfasd con interfaccia PS2? L'input LAG si cerca di evitare in tutti i modi, specialmente in ambito emulativo che ne introduce già di suo rispetto all'hardware nativo.
15ms non sono completamente trascurabili, quello che non capisco è il discorso del rimbalzo delle linguette dei microswitch. Anche Sulle schede jamma era implementato questo ritardo? Non mi risulta.

purtroppo anche io sto riscontrando input lag, non sto affermando che sia un problema della Jammasd ci mancherebbe ma piuttosto cerco di indagare per circoscrivere il problema e trovare la possibile causa, vorrei capire a cosa possa essere riconducibile. Ho fatto un video che lascia il tempo che trova ma che fornisce una vaga idea. Se siete interessati lo posso caricare.

Su CRT con JAMMASD e emulatore in pixelperfect ?

Ciao Tox, si, Jammasd + Groovymame + crt monitor

Molto strano
Non ho riscontri in tal senso
Con tutti i giochi ?

15ms sono 1 frame nella peggiore delle ipotesi, no ?

Suonando strumenti collegati alle schede audio, se si superano i 20ms di latenza il ritardo si inizia a percepire. Se ai 15ms si aggiunge la latenza introdotta dall'emulatore è facile arrivare a valori non trascurabili (fortunatamente i monitor CRT non hanno latenza). Ricordo la differenza notevole nel mame con e senza il triple buffering.
Quello che mi piacerebbe approfondire è questo aspetto di introdurre volutamente della latenza, ritenuta da gran parte dei videogiocatori un aspetto molto importante e da ridurre quanto più possibile.

Kernel ha scritto: ↑01/04/2022, 16:16 Questo vale anche per la vecchia interfasd con interfaccia PS2?

si anche nelle versioni precedenti c'è sempre stata una routine di antirimbalzo

Kernel ha scritto: ↑01/04/2022, 16:16 L'input LAG si cerca di evitare in tutti i modi, specialmente in ambito emulativo che ne introduce già di suo rispetto all'hardware nativo.
15ms non sono completamente trascurabili

quando si introduce un ritardo che viene percepito e che non risolve nessun problema è giusto evitarlo

Kernel ha scritto: ↑01/04/2022, 16:16 quello che non capisco è il discorso del rimbalzo delle linguette dei microswitch

se prendi una scopa e colpisci qualcosa, prima di fare un contatto stabile rimbalza alcune volte? nel loro piccolo anche le linguette degli interruttori hanno questo effetto che dura una decina di millisecondi. questo è il motivo del ritardo, quando la scheda rileva un cambio di stato, prima di inviare l'informazione al pc, si accerta che non sia un disturbo o qualcosa del genere

Kernel ha scritto: ↑01/04/2022, 16:16 Anche Sulle schede jamma era implementato questo ritardo? Non mi risulta.

non ho mai approfondito ma qualche accorgimento ci deve essere, basta anche un filtro passa basso sugli ingressi. l'antirimbalzo sugli ingressi è un sistema a cui non si può rinunciare per non avere problemi

Kernel ha scritto: ↑04/04/2022, 12:42 Suonando strumenti collegati alle schede audio, se si superano i 20ms di latenza il ritardo si inizia a percepire

su questo ti do ragione ma l'orecchio è molto più sensibile dell'occhio