Latenza di input di JammASD

[cools]

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)

► Mostra testo

Input latency of JammASD

I have been happily using JammASD (V2 and V3) for many years, preferring them to JPAC because of the built in sound amplifier.

Recently I was made aware that the V3 has been included in the MisterAddons database, ranked the very bottom of the list for input latency. According to the tester there, it's the worst joystick encoder they've tested.

This doesn't make any sense. It's widely understood that for lightguns to work you need same frame response.

Does anyone have any evidence to the contrary? Has the English speaking community got it wrong?

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

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

[Tox Nox Fox]

Basta attendere @picerno

[picerno]

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

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

[Kernel]

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.

[Domino]

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.

[Tox Nox Fox]

Su CRT con JAMMASD e emulatore in pixelperfect ?

[Domino]

Ciao Tox, si, Jammasd + Groovymame + crt monitor

[Tox Nox Fox]

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

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

[Kernel]

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.

[picerno]

Questo vale anche per la vecchia interfasd con interfaccia PS2?

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

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

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

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

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

[picerno]

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.

se lo riesci a notare ad occhio nudo è molto probabile che non sia il ritardo di 15ms di cui si discute

[picerno]

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

infatti è proprio questo

[Domino]

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.

se lo riesci a notare ad occhio nudo è molto probabile che non sia il ritardo di 15ms di cui si discute

So che non è una test affidabile, non c'è nulla che misura nulla però da l'idea di quello che intendo, che poi si tratti di input lag o altro questo non lo so: di seguito il video che ho prodotto (link temporaneo in download da wetransfer):

https://we.tl/t-l5ZM6omEUb

fatemi sapere cosa ne pensate, grazie.

[Tox Nox Fox]

Non mi ricordo se su groovymame c'è l'opzione ma penso di sì
Un sistema era quello di mettere in pausa il gioco evidenziando i frame di gioco
Muoversi con un comando e avanzare di 1 frame alla volta fino allo spostamento nel gioco. Ogni pausa è un 1 frame.

Che gioco è quello del video ?

[Domino]

Cavolo non mi ricordo il nome del gioco ma cerco di recuperarlo (ne ho provato una a caso per il video). Cosa ne pensi del test che ho fatto?

[Tox Nox Fox]

Che mi fa un po' strano un lag così
Per quello volevo provare il gioco

[Kernel]

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

Grazie della risposta. Anche nei decoder delle tastiere c'è questo ritardo? (non ho mai avuto problemi con i keyhack ghosting a parte)

[Kernel]

So che non è una test affidabile, non c'è nulla che misura nulla però da l'idea di quello che intendo, che poi si tratti di input lag o altro questo non lo so: di seguito il video che ho prodotto (link temporaneo in download da wetransfer):

https://we.tl/t-l5ZM6omEUb

fatemi sapere cosa ne pensate, grazie.

Si tratta di uno degli Aero Fighters? Stai quindi usando una risoluzione verticale su monitr orizzontale?
Mi vengono in mente due cose:
- Per visualizzare la risoluzione verticale su monitor orizzontale stai usando una risoluzione "alta" (es 352x288) quindi frequenza a 50Hz (e non i 60 nativi del gioco). Questo introduce molto lag.
- Hai il triple buffering attivo

Vedo inoltre che in quel gioco la navicella ha inerzia (non si muove immediatamente di suo). Converrebbe fare il test con qualche gioco orizzontale che esegue immediatamente il comando.

[Domino]

Ciao Kernel,

grazie della risposta. Molto interessante ciò che hai scritto, recupero le info appena finisco di lavorare e ti faccio sapere.

[Tox Nox Fox]

Se usi groovymame non hai il triplebuffer attivo di default.
A che risoluzione esci ?
Il discorso del verticale su orizzontale mi era sfuggito, stavo guardando solo il lag ma se usi un verticale su orizzontale il discorso di kernel ci può stare