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.