Mi hai messo un
executable C:\Games\lockedLauncher.exe
Invece di
executable C:\Games\RockedLauncher.exe
Attract-Mode - blocco avvio multiplo [Risolto]
-
Tox Nox Fox
- Moderatore
- Messaggi: 11788
- Iscritto il: 14/01/2007, 23:35
- Medaglie: 3
- Grazie Inviati: 160 volte
- Grazie Ricevuti: 275 volte
-
alucard
- Affezionato
- Messaggi: 277
- Iscritto il: 02/12/2017, 16:19
- Medaglie: 1
- Città: Ceprano
- Grazie Inviati: 5 volte
- Grazie Ricevuti: 15 volte
Re: Attract-Mode - blocco avvio multiplo [Risolto]
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
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
- Affezionato
- Messaggi: 277
- Iscritto il: 02/12/2017, 16:19
- Medaglie: 1
- Città: Ceprano
- Grazie Inviati: 5 volte
- Grazie Ricevuti: 15 volte
Re: Attract-Mode - blocco avvio multiplo [Risolto]
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à:
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.
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
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
- Moderatore
- Messaggi: 11788
- Iscritto il: 14/01/2007, 23:35
- Medaglie: 3
- Grazie Inviati: 160 volte
- Grazie Ricevuti: 275 volte
-
alucard
- Affezionato
- Messaggi: 277
- Iscritto il: 02/12/2017, 16:19
- Medaglie: 1
- Città: Ceprano
- Grazie Inviati: 5 volte
- Grazie Ricevuti: 15 volte
Re: Attract-Mode - blocco avvio multiplo [Risolto]
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.
Con il nuovo firmware la uso come dual Joy e ho risolto il problema a monte. Niente più interferenze.