Attract-Mode - blocco avvio multiplo [Risolto]

[Tox Nox Fox]

Mi hai messo un

executable C:\Games\lockedLauncher.exe

Invece di

executable C:\Games\RockedLauncher.exe

[alucard]

Si, era il nome a cui avevo pensato all'inizio.

Ho pubblicato il repository su GitHub, anche se devo ancora compilare il readme markdown con la descrizione e le istruzioni: https://github.com/matteocedroni/locked-launcher

Ho cambiato qualcosa, quindi riporto le istruzioni relative alla versione rilasciata.
L'utilizzo rimane quello mostrato nei precedenti post e il wrapper blocca l'input all'avvio. Le politiche di sblocco
sono due e sono gestite dai seguenti parametri:

Sblocco dopo un tempo prefissato
L'input viene riabilitato trascorso un numero di secondi pari a unlockAfter

Sblocco dinamico su base presenza processo
L'input viene riabilitato unlockOnWindowDelay secondi dopo che la finestra unlockOnWindow diventa attiva.
L'attesa dell'attivazione della finestra è limitata da unlockOnWindowTimeout secondi, trascorsi i quali l'input viene comunque riabilitato.
Per la configurazione della finestra target, si utilizzano le espressioni Autoit:
https://www.autoitscript.com/autoit3/do ... vanced.htm


In entrambi i casi, a scopo di regolazione, è possibile abilitare il parametro audibleLockStatusChange. Il wrapper emetterà un beep all'inizio e alla fine dell'intervallo di blocco input. In alcuni casi il beep di fine intervallo non si sente, ma questo è un bene perché significa che l'input è stato riabilitato quando l'emulatore ha già preso il controllo dell'audio.


Configurazione di esempio

Codice: Seleziona tutto

[General]
; fixed unlock delay
unlockAfter=10

; unlock on window
unlockOnWindow=[CLASS:RetroArch]
unlockOnWindowTimeout=40
unlockOnWindowDelay=5

audibleLockStatusChange=True

[alucard]

Salve,
a distanza di tempo e con una migliorata consapevolezza ho apportato alcune modifiche al Bartop Windows.

Ricapitolando, il problema era generale e dovuto all'effetto che alcuni input ricevuti dal sistema possono avere sui transitori da un applicativo all'altro, nello specifico dal passaggio di palla tra il frontend e l'emulatore di turno. I software in gioco c'entrano ben poco.

Interfacciare il comandi arcade con un encoder in modalità Keyboard può avere i suoi vantaggi, ma bisogna anche tenere in considerazione che il sistema e le sue finestre sono sensibili ai comandi ricevuti da una tastiera, non solo quando sono coinvolti gli input "Alt", "Ctrl", "Shift" e simili. Si possono adottare degli accorgimenti (sicuramente disabilitare l'evento che scatta alla 5°pressione del tasto Shift), ma ogni input riesce quantomeno ad interferire sul passaggio di focus in corso tra un programma e l'altro.

Per diversi motivi, può diventare complicato avere un Bartop "stabile" da questo punto di vista.

A differenza delle tastiere, il sistema è del tutto indifferente agli input ricevuti dai JoyPad Dinput/Xinput. Quando ho acquistato l'encoder I-PAC 2, poteva essere visto come tastiera (2 giocatori) oppure come singolo JoyPad Dinput. Successivamente il firmware è stato aggiornato, consentendo le seguenti modalità:

• Tastiera
• 2 Joy Dinput standard
• 2 Joy Xinput standard
• 2 Joy Dinput custom
• 2 Joy Xinput custom

Volendo, la modalità di lavoro può essere cambiata con una combinazione di tasti.

Ho colto subito la palla al balzo e dopo l'aggiornamento del firmware sono passato in modalità "2 Joy Xinput", risolvendo a monte diversi problemi, senza la necessità di alcun accorgimento.

[Tox Nox Fox]

Quindi un problema del firmware della jpac?

[alucard]

Per una plancia a due postazioni, il firmware originale mi "costringeva" all'utilizzo della modalità Keyboard. In quella modalità, l'inghippo è sempre dietro l'angolo. Con il Raspy era ok, ma con Windows accorgimenti vari e remapping erano necessari. Capitava anche che toccando la plancia mentre caricava il gioco, il focus tornasse sul FE e da lì si potevano fare avvii multipli.

Con il nuovo firmware la uso come dual Joy e ho risolto il problema a monte. Niente più interferenze.