ArcadeItalia.NET

Salve,
nella realizzazione del bartop x86, sto utilizzando Attract-Mode come FE.

Pur essendo molto flessibile la configurazione dell'invocazione dell'emulatore, ho deciso di introdurre comunque RocketLauncher come strato software unico per il lancio effettivo del gioco selezionato.

Il tutto sembra funzionare correttamente, ma ho notato che lasciato nelle impazienti mani di mia nipote, viene fuori un fastidioso problema che scaturisce da involontari tentativi di avvio multiplo del gioco.

Dal punto di vista dell'utente
Si seleziona un gioco e si preme l'apposito tasto per avviarlo. Entro un certo intervallo di tempo relativamente breve, il tasto viene premuto di nuovo. Dopo un po' arriva a video un messaggio di errore generico di RL e si torna di nuovo sul FE. Da quel momento in poi non parte più alcun gioco per quell'emulatore. Uscendo dal FE (chiudendolo tramite apposita voce di menù) parte il gioco di cui era stato inizialmente richiesto l'avvio.

Cosa avviene nel sistema
Osservando i log, risulta che RL da seguito alla prima richiesta di avvio, ma mentre la sta lavorando ne riceve un'altra. Identifica correttamente la seconda come possibile richiesta duplicata e non la asseconda. La prima richiesta nel frattempo va avanti, ma il gioco non viene mostrato e rimane attivo come processo nascosto. Dopo il messaggio di errore, la vista torna invece sul FE ma ogni successivo tentativo di avvio, viene identificato come duplicato per via del processo del gioco (attivo e nascosto).

Avete mai provato da FE, anche di altro tipo, a cliccare più volte sul tasto di avvio gioco?
Sarà un problema di AM o dell'accoppiata AM+RL?

Io uso MaLa sul cab e abbiamo testato feel e hyperspin nelle fiere così come Retropie ( in cui va tolto il menù scelta di lancio rom da joypad altrimenti parte quello alla seconda premuta di tasto ) e non ho mai visto quel problema

Penso di aver individuato cosa accade.

AM invoca RL, ma RL sicuramente lancia un altro processo per portare avanti l'effettivo avvio dell'emulatore.
Il processo iniziale invocato da AM, quindi, termina quasi istantaneamente, lasciando AM libero di accettare nuovi input.
In quella fase gli input involontari accettati da AM sono tali da farlo persistere in primo piano.
Nel frattempo l'emulatore lanciato dal processo secondario di RL, è pronto, ma rimane in secondo piano: essendo nello specifico Retroarch, rimane per sua natura in pausa e muto.
AM rimane utilizzabile, ma ogni tentativo di lancio viene giustamente bloccato da RL perché c'è un'altra istanza nascosta avviata. Chiudendo AM, Retroarch rimasto in secondo piano, cattura il focus e va avanti.

Devo trovare un modo per impedire di dare ulteriori input ad AM durante la primissima fase di lancio.
Proverò quindi due alternative:

a. utilizzo del plugin aggiuntivo FadeToGame di AM (purtroppo il Fade di RL non è abbastanza istantaneo);

b. utilizzo di uno script Autoit, che farò invocare dal frontend al posto di RL. Lo script farà da passa carte verso RL, ma per prima cosa bloccherà l'input globale sul sistema (per 10s o finché non ottiene l'handler all'emulatore). Una sorta di LockedLauncher

Problema che ogni tanto succede
In alcuni casi si opta per chiudere il frontend e lanciare l'emulatore ( in questo caso RocketLauncher ) per riaprirlo quando si esce dal gioco.
Tienici informati

Posta il log che c diamo un'occhiata
io attualmente uso Attrac mode e RL insieme

Ok grazie.

Condizioni iniziali: posizionato sulla vista emulatore e gioco selezionato.

A questo punto ho premuto a ripetizione il tasto di lancio gioco.
Il risultato è che il gioco non viene mai mostrato. Rimane la schermata di fade perenne. Condizione (A).
Nei log, fino a questo punto viene tracciato quanto riportato qui
https://pastebin.com/P3JVM1BD

Dalla condizione (A) (l'ho notato solo stasera), se invio da input un ESC, la situazione si sblocca e viene mostrato il gioco, da cui poi sono anche uscito per tornare al frontend. Il tracciato di questa fase (completamento avvio gioco e uscita gioco) è il seguente.
https://pastebin.com/2xVK2tpk

Se invece dalla condizione (A), invio da input un RETURN, torno al frontend senza vedere mai il gioco. Da frontend però ogni tentativo di avvio gioco rimarrà muto, perché RL rileva una esecuzione di Retroarch appesa. Questo è il tracciato
https://pastebin.com/58d2ab4B

alucard ha scritto: ↑07/11/2018, 11:23 Penso di aver individuato cosa accade.

b. utilizzo di uno script Autoit, che farò invocare dal frontend al posto di RL. Lo script farà da passa carte verso RL, ma per prima cosa bloccherà l'input globale sul sistema (per 10s o finché non ottiene l'handler all'emulatore). Una sorta di LockedLauncher

Io per alcuni emulatori ostici tipo makaron per chiuderlo usavo CLOSEMUL molto funzionale e completamente gratis

closemul

che versione di win hai 32 o 64 e retroarch 32 o 64

MaX7o ha scritto:
che versione di win hai 32 o 64 e retroarch 32 o 64

Utilizzo Windows 10 Enterprise 64Bit e Retroarch 64Bit

Vi aggiorno.

La direzione presa penso sia quella giusta. E' auspicabile che un frontend blocchi l'input durante l'avvio di un gioco. Leggevo ad esempio questo in una recensione del frontend Big Blue



Visto che il blocco offerto da RL arriva troppo tardi, userò un wrapper che blocca l'input immediatamente e fino all'avvio dell'emulatore.

Non vorrei insomma dover cambiare FE.

Ok ragazzi, ho risolto.

Il wrapper direi che è completato e, nel caso potesse servire a qualcuno, dovrei riuscire a pubblicarlo su GitHub nel fine settimana.

Il funzionamento è semplice e generico.
Consideriamo ad esempio Attract-Mode, file di configurazione standard per emulatore NEO-GEO con utilizzo RocketLauncher
per l'utilizzo del wrapper, la configurazione diventa così
Quindi il wrapper prende il posto dell'eseguibile principale, mentre l'eseguibile originale si sposta in testa agli altri parametri.

Il wrapper, appena viene invocato blocca l'input di tastiera e mouse ed esegue contemporaneamente il comando originale.
La politica di sblocco invece dipenderà dai parametri di configurazione che al momento sono (in file .ini)
unlockOnProcess - Politica di sblocco basata su presenza processo/i. Quando valorizzato con uno o più nomi processo (separati da virgola), il wrapper mantiene l'input bloccato fino alla presenza di almeno uno dei processi specificati (es. retroarch.exe). In ogni caso, al superamento della soglia di tempo unlockTimeout l'input viene riabilitato.

unlockAfter - Politica di sblocco basata su intervallo di tempo fisso. Indica per quanti secondi l'input rimarrà bloccato.

Le due politiche di sblocco sono mutuamente esclusive e la prima ha priorità sulla seconda.

Dalle prove che ho fatto, posso dire di non aver più il problema di prima.
Ho praticamente ballato la tarantella sulla plancia senza interferire sul corretto avvio del gioco.
Ora è a prova di nipote scatenata.

Mi hai messo un

executable C:\Games\lockedLauncher.exe

Invece di

executable C:\Games\RockedLauncher.exe

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

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.

Quindi un problema del firmware della jpac?

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.