ArcadeItalia.NET

Inviato: **11/12/2022, 16:03**

Ciao
Non so in quanti abbiamo delle LightGun AimTrak, e non so se questo comportamento c'è anche con altre LightGun, ma in breve ho il problema descritto qui: https://mametesters.org/view.php?id=6491
In breve, con i giochi 4:3 la posizione del puntatore della LightGun se mi trovoal centro dello schermo coincide con la posizione del puntatore del mouse, controllato anch'esso dalla LightGun, ma se mi sposto a destra o sinistra, il puntatore del mouse inizia progressivamente a discostarsi dal crosshair della LightGun, fino a far arrivare il puntatore del mouse al bordo del televisore mentre il crosshair è sul bordo dell'immagine 4:3

Sperando di essermi riuscito a spiegare, il problema pare che non si riesca a risolvere fintanto che qualche MAME dev in possesso di una AimTrak non riesca a guardarci.

Essendo passati molti anni senza avanzamenti, ho provato a scaricarmi i sorgenti e penso di aver identificato il problema nel file \src\mame\src\osd\modules\input\input_rawinput.cpp alle righe 408 e 409 dove viene calcolata la posizione:

lightgun.lX = normalize_absolute_axis(rawinput.data.mouse.lLastX, 0, osd::INPUT_ABSOLUTE_MAX);
lightgun.lY = normalize_absolute_axis(rawinput.data.mouse.lLastY, 0, osd::INPUT_ABSOLUTE_MAX);

Non sono però riuscito ad andare molto avanti.

C'è qualcuno di voi con maggiori skill di programmazione dei miei, e magari un po' di conoscenza dei sorgenti del MAME, che potrebbe darmi una mano?

Grazie in anticipo a tutti

Inviato: **11/12/2022, 17:22**

Ciao.

Hai provato a configurare la Aimtrak entrando anche nei parametri specifici del Gioco stesso dentro Mame?

Hai aggiornato il firmware?
https://youtu.be/cLlWepjCVDU

Prova a seguire questa guida:
https://youtu.be/UsQ6SKYZGl4

Inviato: **11/12/2022, 17:53**

Ciao MacGyver
In realtà anche nel video si accenna al problema al minuto 23:55, solo che probabilmente non ha fatto test stretchando l’immagine di gioco. Al minuto 25:59 per un attimo si intravede lo sfasamento di cui sto parlando.
Ho già seguito le indicazioni del video, oltre a quanto indicato nel PDF della AimTrak e sono giunto alla conclusione che sia un bug, come confermato anche da un altro utente sul forum di mamedev.
La cosa si vede bene abilitando il crosshair ed entrando nel menu con TAB: con un’immagine a 16:9 il crosshair ed il puntatore del mouse (mossi dalla lightgun) coincidono perfettamente, con l’immagine a 4:3 al centro coincidono, spostandosi verso i bordi sinistro o destro iniziano a separarsi, fino al limite dove quando il puntatore del mouse raggiunge il bordo dello schermo, il crosshair raggiunge il bordo del gioco (il bordo dell’immagine 4:3).
La Lightgun punta sempre perfettamente il puntatore del mouse, che si muove correttamente su tutto lo schermo 16:9.

Con i giochi con la calibrazione si può ovviare al problema, altrimenti per essere precisi bisogna usare per forza il crosshair o stretchare le immagini.

Se riuscissi a trovare la variabile che indica l’effettiva larghezza dello schermo nei sorgenti del MAME penso si possa riuscire a sistemare la posizione con una proporzione.

Inviato: **11/12/2022, 19:53**

Ciao
Dopo aver fatto un paio di test aggiungo che se disattivo il non integer scaling, e l'immagine quindi anche in verticale non è più a schermo intero (ho praticamente i bordi neri su tutti e 4 i lati), il problema si presenta anche sull'asse verticale, oltre che l'asse orizzontale.

Inviato: **14/12/2022, 1:04**

Ho provato ad approfondire un altro po’ i sorgenti per provare capire meglio il problema, purtroppo sono oltre 20 anni che non tocco il C, ma se ho capito bene le lightgun con rawinput:
-Sono device “posizionali”, cioè forniscono una posizione assoluta in un piano x,y da 0 a 65536, in pratica nell’angolo in alto a sinistra riporta 0,0 e in basso a destra 65536,65536 (indipendentemente dalla risoluzione video)
-Il mouse invece ad ogni ciclo riporta lo spostamento dalla posizione precedente, quindi non si può usare il metodo di calcolo usato per il mouse
-La problematica è ancora più evidente in modalità finestra, e se la finestra non è centrata nello schermo puntatore e crosshair non combaciano mai.
-il valore della posizione viene convertita nel range -65536, 65535, cioè 0 diventa -65535, 32768 diventa 0 e 65535 resta invariato. Questo per entrambi gli assi, poi il range -65536, 65535 viene mappato all’interno dell’area di gioco.

A questo punto per far mappare la posizione all’interno dell’area di gioco bisogna tenere in considerazione la risoluzione e la posizione oltre che la dimensione dell’area di gioco, la cosa si fa più complicata

Non mi è ancora ben chiaro di come sia gestito il puntatore del mouse mosso dalla lightgun, visto che quello si muove perfettamente.

Quando trovo un po’ di tempo continuo ad indagare, ma in ogni caso i suggerimenti son sempre ben accetti

Inviato dal mio iPad utilizzando Tapatalk

Inviato: **14/12/2022, 7:08**

Io seguo con interesse

Inviato: **14/12/2022, 8:00**

Emu ha scritto: ↑14/12/2022, 1:04 Ho provato ad approfondire un altro po’ i sorgenti per provare capire meglio il problema, purtroppo sono oltre 20 anni che non tocco il C, ma se ho capito bene le lightgun con rawinput:
-Sono device “posizionali”, cioè forniscono una posizione assoluta in un piano x,y da 0 a 65536, in pratica nell’angolo in alto a sinistra riporta 0,0 e in basso a destra 65536,65536 (indipendentemente dalla risoluzione video)
-Il mouse invece ad ogni ciclo riporta lo spostamento dalla posizione precedente, quindi non si può usare il metodo di calcolo usato per il mouse
-La problematica è ancora più evidente in modalità finestra, e se la finestra non è centrata nello schermo puntatore e crosshair non combaciano mai.
-il valore della posizione viene convertita nel range -65536, 65535, cioè 0 diventa -65535, 32768 diventa 0 e 65535 resta invariato. Questo per entrambi gli assi, poi il range -65536, 65535 viene mappato all’interno dell’area di gioco.

A questo punto per far mappare la posizione all’interno dell’area di gioco bisogna tenere in considerazione la risoluzione e la posizione oltre che la dimensione dell’area di gioco, la cosa si fa più complicata

Non mi è ancora ben chiaro di come sia gestito il puntatore del mouse mosso dalla lightgun, visto che quello si muove perfettamente.

Quando trovo un po’ di tempo continuo ad indagare, ma in ogni caso i suggerimenti son sempre ben accetti

Inviato dal mio iPad utilizzando Tapatalk

tema interessante, ma a prescindere dal calcolo, trovo strano, che una volta calcolato (per quanto la posizione possa essere giusta o sbagliata), questa possa variare nel tempo spostandosi "da sola".
posso capire il fatto di non essere centrato, di non arrivare ai bordi, ma che non muovendola la posizioni vari mi lascia perplesso.

Seguo.

Inviato: **05/01/2023, 1:38**

Gothrek ha scritto: ↑14/12/2022, 8:00
tema interessante, ma a prescindere dal calcolo, trovo strano, che una volta calcolato (per quanto la posizione possa essere giusta o sbagliata), questa possa variare nel tempo spostandosi "da sola".
posso capire il fatto di non essere centrato, di non arrivare ai bordi, ma che non muovendola la posizioni vari mi lascia perplesso.

Seguo.

Ciao Gothrek
Non è che si sposta "da sola", la posizione nella finestra di gioco in proporzione è sempre uguale alla posizione in cui si sta puntando nello schermo reale, solo che se la finestra non è centrata nello schermo, se miro al centro dello schermo il puntatore sarà al centro della finestra del gioco, che se appunto non è centrata a questo punto sballa completamente il posizionamento.
Se punto la pistola ad 1/4 dello schermo in orizzontale e verticale, poi anche all'interno della finestra di gioco il crosshair si trova ad 1/4 della finestra in orizzontale e verticale, indipendentemente da dove si trovi la finestra.
Spero ora di essermi spiegato

Magari vedrò di installare OBS per registrare qualche secondo di movimento per far capire meglio a tutti.

Intanto durante le feste ho avuto un po' di tempo, ma neanche tanto, per fare qualche altro test e questo è quanto:

* Questo comportamento c'è con rawinput.
* Ho visto che nel file /src/osd/modules/input/input_win32.cpp (righe 290-291) utilizza un modo diverso per convertire le coordinate, ho quindi provato ad usare win32 come input provider della lightgun, ma qui sono sorti ulteriori problemi:
- * Il problema dello sfasamento è invariato
  * La lightgun è molto meno precisa che mediante rawinput
  * La seconda lightgun controlla anch'essa il primo crosshair, quindi entrambe funzionano solo per il giocatore 1. Ho anche provato ad abilitare l'opzione dual lightgun nelle opzioni del MAME ma senza successo (Dopotutto la documentazione AimTrak dice di non abilitarla....)

Ho cercato per diverse ore nel sorgente per vedere di trovare sia la risoluzione dello schermo che la dimensione e posizione della finestra, l'unica cosa che ho trovato è questa funzione GetClientRect, dovrò approfondire come funziona e sostituire le chiamate a normalize_absolute_axis con una che tenga in considerazione la dimensione e posizione della finestra.
La prossima volta magari invece di continuare a ravanare nel codice provo a modificare le righe 408 e 409 di /src/osd/modules/input/input_rawinput.cpp con valori fissi, giusto per vedere se il movimento poi è corretto

Inviato: **24/01/2023, 22:58**

Ciao
Sono finalmente riuscito a ritagliarmi un po' di tempo per fare alcune prove, e devo dire di essere soddisfatto di questi risultati parziali.

Per cercare di spiegare ancora un po' meglio il problema, riporto di seguito uno screenshot dove ho inserito alcuni valori:

PointBlank_1080_values.png

La prima riga, in bianco, indica i pixel della risoluzione per visualizzare l'immagine in 4:3 in uno schermo 16:9, in pratica l'immagine di gioco è 1440x1080 co dei bordi di 240 pixel per lato.
La seconda riga in rosso indica i valori del rawinput alle varie posizioni
La terza riga in azzurro indica come attualmente il MAME calcola la posizione
L'ultima riga è come dovrebbe calcolare la posizione, in pratica il range -65536:65536 deve limitarsi al quadro di gioco, andando oltre per la dimensione dello schermo, in base alla risoluzione stessa.

La funzione che è attualmente usata è la medesima per X ed Y, quindi io intanto ho fatto le prove solo sull'asse X, mantenendo l'immagine a schermo intero sull'asse Y (In pratica stretch + keep aspect ratio)

Nel file src\osd\modules\input\input_rawinput.cpp ho modificato la riga 408, andando a richiamare una funzione diversa per l'asse X rispetto a quella originale usata sull'asse Y:

Codice: Seleziona tutto

			lightgun.lX = normalize_absolute_axis_testx(rawinput.data.mouse.lLastX, 0, osd::INPUT_ABSOLUTE_MAX);
			lightgun.lY = normalize_absolute_axis(rawinput.data.mouse.lLastY, 0, osd::INPUT_ABSOLUTE_MAX);

Nel file src\osd\modules\input\input_common.h invece ho sdoppiato la funzione normalize_absolute_axis creandomi la mia, dove ho aggiunto i calcoli relativi. Di seguito entrambe le funzioni, originale e nuova:

Codice: Seleziona tutto

inline int32_t normalize_absolute_axis(double raw, double rawmin, double rawmax)
{
	double center = (rawmax + rawmin) / 2.0;

	// make sure we have valid data
	if (rawmin >= rawmax)
		return int32_t(raw);

	if (raw >= center)
	{
		// above center
		double result = (raw - center) * osd::INPUT_ABSOLUTE_MAX / (rawmax - center);
		return std::min(result, (double)osd::INPUT_ABSOLUTE_MAX);
	}
	else
	{
		// below center
		double result = -((center - raw) * (double)-osd::INPUT_ABSOLUTE_MIN / (center - rawmin));
		return std::max(result, (double)osd::INPUT_ABSOLUTE_MIN);
	}
}

inline int32_t normalize_absolute_axis_testx(double raw, double rawmin, double rawmax)
{
	double center = (rawmax + rawmin) / 2.0;

	double screen_resolution_x = 1920;	// X Resolution of the screen
	double image_size_x = 1440;			// X size of the game window

	double black_border_size_x = (screen_resolution_x - image_size_x) / 2;	// Size in pixel of each black border
	double screen_center_x = screen_resolution_x / 2;

	// To be recalculated from screen resolution and image size
	//double SCREEN_ABSOLUTE_MAX = 87397;
	//double SCREEN_ABSOLUTE_MIN = -87397;
	double SCREEN_ABSOLUTE_MAX = (screen_resolution_x-screen_center_x) * osd::INPUT_ABSOLUTE_MAX / (image_size_x+black_border_size_x-screen_center_x);
	double SCREEN_ABSOLUTE_MIN = -SCREEN_ABSOLUTE_MAX;

	// make sure we have valid data
	if (rawmin >= rawmax)
		return int32_t(raw);

	if (raw >= center)
	{
		// above center
		//double result = (raw - center) * osd::INPUT_ABSOLUTE_MAX / (rawmax - center);	// Original code
		//double result = (raw - center) * (double)87397 / (rawmax - center);			// Test #1
		double result = (raw - center) * SCREEN_ABSOLUTE_MAX / (rawmax - center);		// Test #2
		return std::min(result, (double)osd::INPUT_ABSOLUTE_MAX);
	}
	else
	{
		// below center
		//double result = -((center - raw) * (double)-osd::INPUT_ABSOLUTE_MIN / (center - rawmin));	// Original code
		//double result = -((center - raw) * (double)-87397 / (center - rawmin));					// Test #1 ==> Wrong, while on left side of the screen, the crosshair is on right side of the screen
		double result = -((center - raw) * -SCREEN_ABSOLUTE_MIN / (center - rawmin));				// Test #2
		return std::max(result, (double)osd::INPUT_ABSOLUTE_MIN);
	}
}

Ora il puntatore è perfettamente allineato al crosshair in 4:3, ma visto l'hard coding sia della risoluzione che della dimensione di gioco, questo workaround è usabile solo a 1920x1080 in 4:3 (O andandosi a modificare i valori e ricompilando...ma non è comodissimo, sopratutto per il tempo di compilazione).

Non è che qualcuno mi saprebbe guidare per capire quale siano esattamente le variabili/oggetti contenenti sia la risoluzione video che la dimensione della finestra? Se ho visto bene per la dimensione dello schermo dovrei usare la funzione GetWindowRect, ma non sono sicuro di come ottenere la dimensione corretta, e per l'area di gioco invece non ho ancora trovato nulla.

Almeno adesso però posso ingannare il tempo facendomi qualche partita mantenendo il form factor corretto di 4:3, senza dover stratchare le immagini

Inviato: **25/01/2023, 9:24**

@Emu
se hai pazienza te lo guardo domenica.

Inviato: **25/01/2023, 14:47**

Buono che si cerchi di fare qualcosa per sistemare un problema di una lightgun parecchio venduta.
Personalmente rimango dell'idea che dato che avevano il monopolio, non hanno mai sistemato quella pistola, con problemi abbastanza evidenti. Oggi ci sono le alternative, sicuramente più costose, ma finalmente l'utilizzo di una lightgun non è più problematico e riesce a far giocare quel tipo di giochi come in sala (limiti emulativi permettendo)

Inviato: **25/01/2023, 20:16**

Gothrek ha scritto:[mention]Emu[/mention]
se hai pazienza te lo guardo domenica.

Grazie Gothrek, nessun problema, quando riesci mi va bene

Inviato: **25/01/2023, 20:38**

cybermat ha scritto:Buono che si cerchi di fare qualcosa per sistemare un problema di una lightgun parecchio venduta.
Personalmente rimango dell'idea che dato che avevano il monopolio, non hanno mai sistemato quella pistola, con problemi abbastanza evidenti. Oggi ci sono le alternative, sicuramente più costose, ma finalmente l'utilizzo di una lightgun non è più problematico e riesce a far giocare quel tipo di giochi come in sala (limiti emulativi permettendo)

Ciao cybermat
Le Aimtrak le ho prese diversi anni or sono (mi pare nel 2016 se non prima) ma facendo un settaggio ed una calibrazione corretta le ho sempre viste funzionare correttamente, a parte questo problema sui giochi 4:3 solo sul MAME (anche perché secondo me gli altri software sfruttano l’emulazione mouse) dovuto a come il MAME calcola la posizione nelle lightgun posizionali, almeno in base a quanto mi pare di aver capito dai sorgenti, ma qui nel caso lascio la parola a chi più esperto di me nel codice, quindi mi aspetto che altre lightgun che funziona o nel medesimo modo si comportino in modo analogo.
Purtroppo non ho mai avuto il piacere di testare né la Silden né la Gun4ir, quindi non so quanto siano precise né come vengono riconosciute dal computer, ma per quanto mi riguarda la Silden è esclusa a priori per il bordo, mentre per la Gun4ir non ho trovato info precise ma sembra che usi un sistema simile alle Aimtrak con dei led da posizionare, ma non ho capito bene quanti e dove.
Fatte queste premesse, tornando alle Aimtrak a quali problemi irrisolti ti riferisci? Io in realtà a parte questo problemino sono contento di come funzionano, non mi pare di aver visto problemi eclatanti, ma magari mi sono sfuggiti e da come ne parli mi hai incuriosito.

Poi non vorrei trasformare questo thread in una discussione “sul sesso delle lightgun”, nel caso magari facciamo un tread apposito

Inviato: **25/01/2023, 21:01**

Emu ha scritto: ↑25/01/2023, 20:38
cybermat ha scritto:Buono che si cerchi di fare qualcosa per sistemare un problema di una lightgun parecchio venduta.
Personalmente rimango dell'idea che dato che avevano il monopolio, non hanno mai sistemato quella pistola, con problemi abbastanza evidenti. Oggi ci sono le alternative, sicuramente più costose, ma finalmente l'utilizzo di una lightgun non è più problematico e riesce a far giocare quel tipo di giochi come in sala (limiti emulativi permettendo)
Ciao cybermat
Le Aimtrak le ho prese diversi anni or sono (mi pare nel 2016 se non prima) ma facendo un settaggio ed una calibrazione corretta le ho sempre viste funzionare correttamente, a parte questo problema sui giochi 4:3 solo sul MAME (anche perché secondo me gli altri software sfruttano l’emulazione mouse) dovuto a come il MAME calcola la posizione nelle lightgun posizionali, almeno in base a quanto mi pare di aver capito dai sorgenti, ma qui nel caso lascio la parola a chi più esperto di me nel codice, quindi mi aspetto che altre lightgun che funziona o nel medesimo modo si comportino in modo analogo.
Purtroppo non ho mai avuto il piacere di testare né la Silden né la Gun4ir, quindi non so quanto siano precise né come vengono riconosciute dal computer, ma per quanto mi riguarda la Silden è esclusa a priori per il bordo, mentre per la Gun4ir non ho trovato info precise ma sembra che usi un sistema simile alle Aimtrak con dei led da posizionare, ma non ho capito bene quanti e dove.
Fatte queste premesse, tornando alle Aimtrak a quali problemi irrisolti ti riferisci? Io in realtà a parte questo problemino sono contento di come funzionano, non mi pare di aver visto problemi eclatanti, ma magari mi sono sfuggiti e da come ne parli mi hai incuriosito.

Poi non vorrei trasformare questo thread in una discussione “sul sesso delle lightgun”, nel caso magari facciamo un tread apposito

Ciao! Per quanto riguarda la gun4ir lavora "simulando il mouse" per quanto riguarda il "movimento del puntatore"...anche se, grazie all'utilizzo dei led IR posizionati su ogni angolo del monitor (3 per lato ma io ne uso 4 o 5 a seconda della grandezza del monitor), è capace grazie alla camera ad infrarossi, di sapere l'esatto punto in cui si sta mirando...

Io ho provato tutte le soluzioni da te citate e devo dire che, la gun4ir la ritengo la miglior soluzione a livello di versatilitá, prontezza nelle risposte e precisione, oltre al fatto che qualsiasi dispositivo con porta Usb la riconosce (incluso le "amate" Pandora's box DX)... ovviamente è una mia opinione ..
Sabato se riesco dó un occhiata al setting delle mie aimtrack, seguo Comunque con interesse!

Inviato: **26/01/2023, 23:24**

Emu ha scritto: ↑25/01/2023, 20:38
cybermat ha scritto:Buono che si cerchi di fare qualcosa per sistemare un problema di una lightgun parecchio venduta.
Personalmente rimango dell'idea che dato che avevano il monopolio, non hanno mai sistemato quella pistola, con problemi abbastanza evidenti. Oggi ci sono le alternative, sicuramente più costose, ma finalmente l'utilizzo di una lightgun non è più problematico e riesce a far giocare quel tipo di giochi come in sala (limiti emulativi permettendo)
Ciao cybermat
Le Aimtrak le ho prese diversi anni or sono (mi pare nel 2016 se non prima) ma facendo un settaggio ed una calibrazione corretta le ho sempre viste funzionare correttamente, a parte questo problema sui giochi 4:3 solo sul MAME (anche perché secondo me gli altri software sfruttano l’emulazione mouse) dovuto a come il MAME calcola la posizione nelle lightgun posizionali, almeno in base a quanto mi pare di aver capito dai sorgenti, ma qui nel caso lascio la parola a chi più esperto di me nel codice, quindi mi aspetto che altre lightgun che funziona o nel medesimo modo si comportino in modo analogo.
Purtroppo non ho mai avuto il piacere di testare né la Silden né la Gun4ir, quindi non so quanto siano precise né come vengono riconosciute dal computer, ma per quanto mi riguarda la Silden è esclusa a priori per il bordo, mentre per la Gun4ir non ho trovato info precise ma sembra che usi un sistema simile alle Aimtrak con dei led da posizionare, ma non ho capito bene quanti e dove.
Fatte queste premesse, tornando alle Aimtrak a quali problemi irrisolti ti riferisci? Io in realtà a parte questo problemino sono contento di come funzionano, non mi pare di aver visto problemi eclatanti, ma magari mi sono sfuggiti e da come ne parli mi hai incuriosito.

Poi non vorrei trasformare questo thread in una discussione “sul sesso delle lightgun”, nel caso magari facciamo un tread apposito

Non mi fraintendere, non è un colabrodo, ma spostandomi poi perdeva sempre la precisione. Mi snervava giocare nel medesimo punto dove l'avevo calibrata. Con la Gun4ir, mi muovo liberamente e ha tante features comode. Senza contare che l'ho costruita con meno di 60 euro (senza recoil che personalmente mi infastidisce).

Inviato: **29/01/2023, 9:05**

Emu ha scritto: ↑25/01/2023, 20:16
Gothrek ha scritto:@Emu
se hai pazienza te lo guardo domenica.
Grazie Gothrek, nessun problema, quando riesci mi va bene

partiamo dalle cose facili

diciamo che in generale una risoluzione potrebbe cambiare nel corso dell'esecuzione del programma, banalizzo su windows dove hai impostato una risoluzione e con una app aperta gliela cambi, piuttosto che switch la risoluzioen da orizzontale a verticale

dando per scontato che questo non avvenga, e che resti la stessa dall'avvio alla chiusura del programma, diverse funzioni dovrebbero restituire gli stessi valori:

Codice: Seleziona tutto

    
    int h = GetSystemMetrics(SM_CXSCREEN);
    int v = GetSystemMetrics(SM_CYSCREEN);

piuttosto che:

Codice: Seleziona tutto

    int h = GetDeviceCaps(GetDC(NULL), HORZRES);
    int v = GetDeviceCaps(GetDC(NULL), VERTRES);

cosi togli le costanti sulla risoluzione del monitor

ora capire i valori di risuluzione del mame del gioco devo dedicargli un pò di tempo, ti aggiorno.

ArcadeItalia.NET

Sfasamento puntatore LightGun AimTrak con giochi 4:3 su schermi 16:9

Sfasamento puntatore LightGun AimTrak con giochi 4:3 su schermi 16:9

Re: Sfasamento puntatore LightGun AimTrak con giochi 4:3 su schermi 16:9

Sfasamento puntatore LightGun AimTrak con giochi 4:3 su schermi 16:9

Re: Sfasamento puntatore LightGun AimTrak con giochi 4:3 su schermi 16:9

Re: Sfasamento puntatore LightGun AimTrak con giochi 4:3 su schermi 16:9

Re: Sfasamento puntatore LightGun AimTrak con giochi 4:3 su schermi 16:9

Re: Sfasamento puntatore LightGun AimTrak con giochi 4:3 su schermi 16:9

Re: Sfasamento puntatore LightGun AimTrak con giochi 4:3 su schermi 16:9

Re: Sfasamento puntatore LightGun AimTrak con giochi 4:3 su schermi 16:9

Re: Sfasamento puntatore LightGun AimTrak con giochi 4:3 su schermi 16:9

Re: Sfasamento puntatore LightGun AimTrak con giochi 4:3 su schermi 16:9

Re: Sfasamento puntatore LightGun AimTrak con giochi 4:3 su schermi 16:9

Re: Sfasamento puntatore LightGun AimTrak con giochi 4:3 su schermi 16:9

Re: Sfasamento puntatore LightGun AimTrak con giochi 4:3 su schermi 16:9

Re: Sfasamento puntatore LightGun AimTrak con giochi 4:3 su schermi 16:9

Re: Sfasamento puntatore LightGun AimTrak con giochi 4:3 su schermi 16:9