[DEV] M.A.M.E. SDL Plus by F. Lancioni

Qui si parla di M.A.M.E.
Rispondi
Avatar utente
Administrator
Site Admin
Messaggi: 451
Iscritto il: gio feb 25, 2016 6:32 pm
Ha ringraziato: 0
È stato ringraziato: 339 volte

[DEV] M.A.M.E. SDL Plus by F. Lancioni

Messaggio da Administrator »

Current version v2.3 (29-07-2021)
Immagine

In questo thread si parla del progetto che porto avanti nel tempo libero ovvero un emulatore M.A.M.E., il cui sviluppo si basa sulla versione 0.61, disponibile per Raspberry Pi, Ubuntu (e derivati), Windows e OSX/macOS.

Senza perdere tempo vi presento subito l'indice dei contenuti, leggete tutti gli argomenti per utilizzarlo al meglio!

Indice dei contenuti: Versione 2.3:
- Raspberry Pi - v0, v1, v2, v3, v4
- Ubuntu (e derivati)
- Windows
- OSX/macOS

Download link is inside this file (you must be logged):
M.A.M.E. SDL Plus - v2.3.txt
Non hai i permessi necessari per visualizzare i file allegati in questo messaggio.
Questi utenti hanno ringraziato l'autore Administrator per il post (totale 8):
GuybrushPadremayiNewtonIonicpaologClaus83JohnTitorretro_mame
Reputazione: 80%
"A volte sono le persone che nessuno immaginava potessero fare certe cose quelle che fanno cose che nessuno può immaginare" A. Turing
_____________________________________________________________
Aiutiamo il forum con una donazione :-)

Hardware:
Raspberry Pi Model B Rev 2
Raspberry Pi 3 Model B Rev 1.2
Raspberry Pi 4 Model B Rev 1.2

Avatar utente
Administrator
Site Admin
Messaggi: 451
Iscritto il: gio feb 25, 2016 6:32 pm
Ha ringraziato: 0
È stato ringraziato: 339 volte

[DEV] M.A.M.E. SDL Plus by F. Lancioni

Messaggio da Administrator »

|<---| Torna all'indice dei contenuti

### NASCITA DEL PROGETTO ###
Lo scopo da cui tutto è partito era poter utilizzare degnamente il M.A.M.E. su Raspberry Pi v1 con l'aggiunta del supporto agli artworks.

Qualcuno si chiederà perché 0.61? Inizialmente l'ho scelta perché era la prima versione con il supporto nativo ad artworks esterni ma poi mi sono reso conto che non c'era la possibilità di utilizzarli in alta definizione. A quel punto però una parte del lavoro era già stata fatta, motivo per cui successivamente ho scritto da zero il codice per supportarli. Inoltre la 0.61 è una versione intermedia e matura tra la 0.37b5 (usata in passato da altri porting) e la famosissima 0.78, quindi sono andato avanti su questa strada
Il porting non è volutamente appesantito dall'ulteriore layer delle versioni Libretro (quindi niente lr- davanti al nome) e della versione 0.61 mantiene soltanto il core di base ;-)
Il codice è altamente ottimizzato, ho usato lookup table e tutta una serie di logiche per ridurre il carico della CPU, e funziona su diversi sistemi! Per raggiungere l'obiettivo del multipiattaforma il layer verso il sistema operativo utilizza la libreria SDL in modo che il codice possa esser compilato per qualsiasi sistema che la supporti, ovvero Windows, Linux, macOS ecc. Inoltre rispetto alla versione 0.61, il cui core è la base di partenza, sono stati aggiunti (e all'occorrenza ne verranno aggiunti altri) ulteriori giochi e questo è uno dei motivi, oltre alle nuove funzionalità rispetto alla versione di partenza, per cui il progetto si chiama M.A.M.E. SDL Plus :D

Tra le varie modifiche, che trovate illustrate negli argomenti presenti nell'indice, c'è la possibilità, come accennato all'inizio, di utilizzare artworks in alta risoluzione (formato .lyt) oltre a poter giocare con 4 trackballs e 4 spinners contemporaneamente!

Il porting regge senza problemi 60 frames al secondo "reali" sui Raspberry Pi, a parte nel primo modello. Per RPi v1 arriva però in aiuto il codice che ho scritto dove, implementando un sistema di frameskipping automatico e dinamico, vengono saltati al bisogno alcuni frames rendendo l'esecuzione sui primi Raspberry Pi praticamente full speed per molti giochi (qui trovate 2 video dimostrativi)! I nostri occhi fortunatamente non si accorgono quando questo accade :lol:

Per il Raspberry Pi v1 è richiesto (come con tutti i M.A.M.E.) l'overclock, seguite questa guida

|<---| Torna all'indice dei contenuti
"A volte sono le persone che nessuno immaginava potessero fare certe cose quelle che fanno cose che nessuno può immaginare" A. Turing
_____________________________________________________________
Aiutiamo il forum con una donazione :-)

Hardware:
Raspberry Pi Model B Rev 2
Raspberry Pi 3 Model B Rev 1.2
Raspberry Pi 4 Model B Rev 1.2

Avatar utente
Administrator
Site Admin
Messaggi: 451
Iscritto il: gio feb 25, 2016 6:32 pm
Ha ringraziato: 0
È stato ringraziato: 339 volte

[DEV] M.A.M.E. SDL Plus by F. Lancioni

Messaggio da Administrator »

|<---| Torna all'indice dei contenuti

### VIDEO DIMOSTRATIVI ###
Per darvi subito un'idea del lavoro svolto ecco un paio di video dimostrativi!

PC di sviluppo vs Raspbery Pi v1
Ecco un video con un confronto di esecuzione tra il portatile sul quale sviluppo e il Raspberry Pi v1:
PC vs Raspberry Pi v1

Guardare per credere ;-)

M.A.M.E. SDL Plus vs lr-mame2003
In questo video viene mostrata la differenza di prestazioni su Raspberry Pi v1 tra lr-mame2003 e il mio emulatore:
Raspberry Pi v1: lr-mame2003 vs M.A.M.E. SDL Plus

Non credo di essere di parte se dico che lr-mame2003 non regge il confronto ;-)

|<---| Torna all'indice dei contenuti
"A volte sono le persone che nessuno immaginava potessero fare certe cose quelle che fanno cose che nessuno può immaginare" A. Turing
_____________________________________________________________
Aiutiamo il forum con una donazione :-)

Hardware:
Raspberry Pi Model B Rev 2
Raspberry Pi 3 Model B Rev 1.2
Raspberry Pi 4 Model B Rev 1.2

Avatar utente
Administrator
Site Admin
Messaggi: 451
Iscritto il: gio feb 25, 2016 6:32 pm
Ha ringraziato: 0
È stato ringraziato: 339 volte

[DEV] M.A.M.E. SDL Plus by F. Lancioni

Messaggio da Administrator »

|<---| Torna all'indice dei contenuti

### ADAPTIVE DYNAMIC FRAMESKIPPING ###
Ho cambiato totalmente la logica di frameskipping presente nel M.A.M.E. migliorando notevolmente le prestazioni sui Raspberry Pi v1 e v0. Per capire come è andata l'esecuzione quando l'emulatore viene chiuso vedrete, tra le altre, queste informazioni:

Codice: Seleziona tutto

End game summary:
Main loop frequency: 60.000802 Hz
Nominal FPS: 60.000000
Real FPS: 60.000802

Total play time: 3192.074000 seconds
Real FPS si riferisce ai frames al secondo mostrati a video, se il valore è identico a Nominal FPS le prestazioni saranno in tutto e per tutto uguali a quelle del cabinato originale. Però attenzione, la magia è questa: Main loop frequency si riferisce ai cicli al secondo del loop principale del gioco, ovvero input, sound, video ecc. Se questo valore è prossimo o identico al valore Nominal FPS le prestazioni percepite saranno identiche a quelle del cabinato originale anche se Real FPS non coincide con Nominal FPS.

Normalmente quando Main loop frequency e Real FPS coincidono significa che nessun frame è stato saltato durante l'esecuzione: nel caso però in cui il vertical sync sia attivo potrebbero risultare diversi per motivi di sincronia
La sincronizzazione audio/video, nonché il mantenimento dei frames al secondo nominali, sfrutta una logica basata sull'hardware audio. Se avete problemi di audio, una configurazione errata, audio non funzionante ecc., i FPS potrebbero non essere rispettati (ad esempio potreste incappare nel superamento del framerate nominale con i giochi che risulteranno accelerati)
|<---| Torna all'indice dei contenuti
"A volte sono le persone che nessuno immaginava potessero fare certe cose quelle che fanno cose che nessuno può immaginare" A. Turing
_____________________________________________________________
Aiutiamo il forum con una donazione :-)

Hardware:
Raspberry Pi Model B Rev 2
Raspberry Pi 3 Model B Rev 1.2
Raspberry Pi 4 Model B Rev 1.2

Avatar utente
Administrator
Site Admin
Messaggi: 451
Iscritto il: gio feb 25, 2016 6:32 pm
Ha ringraziato: 0
È stato ringraziato: 339 volte

[DEV] M.A.M.E. SDL Plus by F. Lancioni

Messaggio da Administrator »

|<---| Torna all'indice dei contenuti

### SIMPLE SCANLINES ###
Le scanlines servono per imitare l'effetto video dei vecchi schermi CRT e di default sono disabilitate: è possibile aggiungere il parametro simple-scanlines alla riga di comando per attivarle, ad esempio

Codice: Seleziona tutto

./mame_rpi4 -rompath /home/pi/RetroPie/roms/mamesdlplus dino -simple-scanlines
Questo effetto non potrà essere attivato se uno degli effetti CRT pixel risulta attivo.

Oltre a ciò nel menù del M.A.M.E. c'è la possibilità di configurare l'opzione Scanlines On/Off per attivare/disattivare le scanlines con il M.A.M.E. in esecuzione premendo semplicemente un pulsante

|<---| Torna all'indice dei contenuti
"A volte sono le persone che nessuno immaginava potessero fare certe cose quelle che fanno cose che nessuno può immaginare" A. Turing
_____________________________________________________________
Aiutiamo il forum con una donazione :-)

Hardware:
Raspberry Pi Model B Rev 2
Raspberry Pi 3 Model B Rev 1.2
Raspberry Pi 4 Model B Rev 1.2


Avatar utente
Administrator
Site Admin
Messaggi: 451
Iscritto il: gio feb 25, 2016 6:32 pm
Ha ringraziato: 0
È stato ringraziato: 339 volte

[DEV] M.A.M.E. SDL Plus by F. Lancioni

Messaggio da Administrator »

|<---| Torna all'indice dei contenuti

### FRAMEBUFFER PERSONALIZZABILE ###
E' possibile impostare in modo arbitrario la dimensione del framebuffer video, ovvero la dimensione dell'area in cui verrà mostrato il gioco, quando l'emulatore è in esecuzione in modalità fullscreen. Basterà lanciare l'emulatore con i parametri framebuffer-width e framebuffer-height, ad esempio

Codice: Seleziona tutto

./mame_rpi4 -rompath /home/pi/RetroPie/roms/mamesdlplus dino -framebuffer-width 1280 -framebuffer-height 996
Il codice è intelligente quindi le dimensioni finali verranno ricalcolate all'avvio del gioco in modo che l'aspect ratio del cabinato originale venga mantenuto.

Questo può essere particolarmente utile nel caso in cui avete uno schermo molto grande e volete ridurre la dimensione del gioco, oppure avete costruito un cabinato arcade ma l'apertura nel legno copre leggermente i bordi dello schermo: in questo secondo caso potete utilizzare questa funzionalità e successivamente centrare il framebuffer rispetto all'apertura del cabinato con i comandi posti sul vostro monitor

|<---| Torna all'indice dei contenuti
"A volte sono le persone che nessuno immaginava potessero fare certe cose quelle che fanno cose che nessuno può immaginare" A. Turing
_____________________________________________________________
Aiutiamo il forum con una donazione :-)

Hardware:
Raspberry Pi Model B Rev 2
Raspberry Pi 3 Model B Rev 1.2
Raspberry Pi 4 Model B Rev 1.2

Avatar utente
Administrator
Site Admin
Messaggi: 451
Iscritto il: gio feb 25, 2016 6:32 pm
Ha ringraziato: 0
È stato ringraziato: 339 volte

[DEV] M.A.M.E. SDL Plus by F. Lancioni

Messaggio da Administrator »

|<---| Torna all'indice dei contenuti

### HD ARTWORKS ###
Gli artworks sono quelle grafiche che circondavano il monitor dei cabinati
Retrostoria: L'origine degli artworks è molto varia.
Il supporto inizialmente era solo hardcoded nel driver del gioco, questo fino alla versione 0.60: in parole povere non era possibile aggiungere un, detto genericamente, overlay esterno (motivo per cui spesso leggo di persone che chiedono come mai in M.A.M.E. 0.37b5 gli artworks non funzionano seppur presenti nella cartella artwork).
La versione 0.61 è stata la prima versione che permetteva l'utilizzo degli artworks in formato .art, artworks che però potevano essere solo in bassa risoluzione. Dalla versione 0.107 invece gli artworks sono supportati (anche in alta risoluzione) in formato .lay
Il codice sorgente è stato modificato quindi con M.A.M.E. SDL Plus sono utilizzabili gli artworks in alta risoluzione nel formato .lyt. Vi basterà inserire l'immagine in formato .png nella cartella artwork con lo stesso nome del romset (per Final Fight quindi sarà ffight.png) e un file di testo, con estensione .lyt e sempre con il nome del romset (per Final Fight quindi sarà ffight.lyt).

Ad esempio per il romset sf2ce si ha il seguente contenuto del file sf2ce.lyt:

Codice: Seleziona tutto

Width="4000" Height="3743"
GameAreaWidth="2920" GameAreaHeight="2190"
GameAreaX="540" GameAreaY="822"
ArtworkType="merged"
Width e Height sono banalmente larghezza e altezza in pixel dell'immagine .png, niente di misterioso.

GameAreaWidth e GameAreaHeight rappresentano larghezza e altezza dell'area dove si vuole che venga mostrato il gioco, nel caso di sf2ce rappresentano il "buco" presente nell'immagine, espresse in pixel rispetto all'immagine.

GameAreaX e GameAreaY sono la coordinata X e la coordinata Y, espresse in pixel, dove il gioco verrà posizionato (l'origine è in alto a sinistra) e in questo caso rappresentano l'angolo in alto a sinistra del "buco" nell'immagine.

ArtworkType accetta le opzioni ontop e merged. Il valore di default è merged quindi se il parametro è assente il comportamento sarà quello. Il significato è presto spiegato:
  • merged: ad esempio nel romset warrior l'artwork linkato in questo post altro non è che lo sfondo del gioco, quindi il risultato finale mostrato a video sarà una fusione di immagini, il frame del gioco, l'artwork ed eventuali effetti video attivi
  • ontop: a differenza della modalità merged l'artwork viene disegnato sopra al frame del gioco. In questo modo se l'artwork si sovrappone all'area del gioco l'effetto finale sarà, a mio avviso, più gradevole a discapito di non vedere una parte dell'area di gioco
Per farvi capire ancora meglio, qui potete osservare rispettivamente la differenza tra merged e ontop in Bubble Bobble:
Immagine Immagine

Alla fine è una questione di gusti, chiaramente se nel romset warrior utilizzate l'opzione ontop, e l'artwork stesso non prevede trasparenze (come nel caso di quello allegato), non vedrete il gioco ma soltanto lo sfondo :lol:

Warrior configurato correttamente:
Immagine

Il codice è intelligente quindi successivamente le dimensioni verranno ricalcolate all'avvio del gioco in modo che l'aspect ratio del cabinato originale venga mantenuto, quindi se GameAreaWidth e GameAreaHeight non sono ad esempio 4:3 (come ad esempio vuole il cabinato originale di sf2ce) non importa, ci penserà M.A.M.E. SDL Plus (diciamo c'ho pensato io con parecchie linee di codice :lol:) a ricreare tutto correttamente.

Fatto questo basterà lanciare l'emulatore con il parametro hd-artwork, ad esempio

Codice: Seleziona tutto

./mame_rpi4 -rompath /home/pi/RetroPie/roms/mamesdlplus dino -hd-artwork
Oltre a ciò nel menù del M.A.M.E. c'è la possibilità di configurare l'opzione HD Artwork On/Off per mostrare/nascondere l'artwork con il M.A.M.E. in esecuzione premendo semplicemente un pulsante.

Questi sono alcuni artworks di esempio in formato .lyt creati dagli utenti del forum:
1942 1943 altbeast asteroid baddudes bublbobl dkong invaders mercs puckman sf2ce shdancer simpsons spacewar warrior

|<---| Torna all'indice dei contenuti
"A volte sono le persone che nessuno immaginava potessero fare certe cose quelle che fanno cose che nessuno può immaginare" A. Turing
_____________________________________________________________
Aiutiamo il forum con una donazione :-)

Hardware:
Raspberry Pi Model B Rev 2
Raspberry Pi 3 Model B Rev 1.2
Raspberry Pi 4 Model B Rev 1.2

Avatar utente
Administrator
Site Admin
Messaggi: 451
Iscritto il: gio feb 25, 2016 6:32 pm
Ha ringraziato: 0
È stato ringraziato: 339 volte

[DEV] M.A.M.E. SDL Plus by F. Lancioni

Messaggio da Administrator »

|<---| Torna all'indice dei contenuti

### VERTICAL REFRESH SYNCHRONIZATION ###
Ho inserito la possibilità di attivare o meno il vertical sync per evitare fenomeni di tearing. Per default il vertical sync è attivo ma è possibile disattivarlo passando il parametro novsync da riga di comando, ad esempio

Codice: Seleziona tutto

./mame_rpi3 -rompath /home/pi/RetroPie/roms/mamesdlplus dino -novsync
Su PC (Windows o Linux) e su Raspberry Pi v0, v1, v2 e v3 decidete voi se lasciare attiva l'opzione mentre su Raspberry Pi v4 è necessario non disattivarla a causa di un bug nel driver video (leggete qui per capire cosa accade). Da quel che ho visto su Raspberry Pi v1 è leggermente deleterio
Prestate attenzione al fatto che se il vostro schermo ha un refresh di 50 Hz non andrete mai oltre i 50 frames al secondo
Riporto un esempio di cosa succede su un display 50 Hz (15 secondi circa di runtime giusto per dare l'idea):

Opzione vsync attivata

Codice: Seleziona tutto

End game summary:
Main loop frequency: 60.052562 Hz
Nominal FPS: 60.000000
Real FPS: 49.737188

Total play time: 15.220000 seconds
Opzione vsync disattivata

Codice: Seleziona tutto

End game summary:
Main loop frequency: 60.152317 Hz
Nominal FPS: 60.000000
Real FPS: 60.152317

Total play time: 15.494000 seconds
Come vedete (parametro Real FPS) se il vsync è disattivato pur essendo lo schermo a 50 Hz il gioco viene eseguito al framerate nominale, ovvero 60 FPS. Al contrario con il vsync attivato essendo lo schermo a 50 Hz il gioco viene eseguito a 50 FPS
Ovviamente se un gioco ha un framerate nominale di 37 Hz e lo schermo ha un refresh video di valore superiore (ad esempio 50 Hz o 60 Hz) il gioco funzionerà regolarmente a 37 FPS
Ricapitolando:
se avete un Raspberry Pi v4 non dovete disattivare il vsync, negli altri casi vedete voi ;-)
|<---| Torna all'indice dei contenuti
"A volte sono le persone che nessuno immaginava potessero fare certe cose quelle che fanno cose che nessuno può immaginare" A. Turing
_____________________________________________________________
Aiutiamo il forum con una donazione :-)

Hardware:
Raspberry Pi Model B Rev 2
Raspberry Pi 3 Model B Rev 1.2
Raspberry Pi 4 Model B Rev 1.2

Avatar utente
Administrator
Site Admin
Messaggi: 451
Iscritto il: gio feb 25, 2016 6:32 pm
Ha ringraziato: 0
È stato ringraziato: 339 volte

[DEV] M.A.M.E. SDL Plus by F. Lancioni

Messaggio da Administrator »

|<---| Torna all'indice dei contenuti

### VIDEO INTERPOLATION - CRT BLUR ###
Esiste la possibilità di attivare un filtro video utilizzato nello scaling dell'immagine, a discapito dell'aggiunta di un effetto blur, che va a smussare i pixel. Per usarlo è possibile passare il parametro linear-filter o il parametro best-filter, alla riga di comando, ad esempio

Codice: Seleziona tutto

./mame_rpi4 -rompath /home/pi/RetroPie/roms/mamesdlplus dino -linear-filter

Codice: Seleziona tutto

./mame_rpi4 -rompath /home/pi/RetroPie/roms/mamesdlplus dino -best-filter
Attualmente è indifferente utilizzare uno o l'altro
|<---| Torna all'indice dei contenuti
"A volte sono le persone che nessuno immaginava potessero fare certe cose quelle che fanno cose che nessuno può immaginare" A. Turing
_____________________________________________________________
Aiutiamo il forum con una donazione :-)

Hardware:
Raspberry Pi Model B Rev 2
Raspberry Pi 3 Model B Rev 1.2
Raspberry Pi 4 Model B Rev 1.2

Avatar utente
Administrator
Site Admin
Messaggi: 451
Iscritto il: gio feb 25, 2016 6:32 pm
Ha ringraziato: 0
È stato ringraziato: 339 volte

[DEV] M.A.M.E. SDL Plus by F. Lancioni

Messaggio da Administrator »

|<---| Torna all'indice dei contenuti

### SUPPORTO TRACKBALL ###
Le versioni per Raspberry Pi e quella per sistemi Ubuntu-based supportano l'utilizzo di 4 trackballs connesse contemporaneamente, ovvero il numero massimo di giocatori disponibile nei giochi che utilizzavano tale sistema di controllo.

Le versioni per Windows e OSX/macOS supportano un solo giocatore con questo sistema di controllo e non è necessario eseguire la configurazione.

Il M.A.M.E. non distingue tra movimento analogico di una trackball e movimento analogico di uno spinner. Il core del M.A.M.E. si occupa del movimento dei Players, non distingue la richiesta per tipo di periferica, se sono presenti sia trackball che spinner associati al medesimo Player (sempre vero sulle versioni per Windows e OSX/macOS) è possibile usare entrambe le periferiche per controllarlo.

Questo non comporta nessun problema di gameplay, è chiaro che dovrete evitare di giocare a Missile Command II con la trackball mentre il nipotino/amico dispettoso armeggia sullo spinner :lol:

Ovviamente per giocare al meglio dovete utilizzare la periferica per cui il gioco è stato progettato. Se non sapete quale sia premete Tab e spostatevi in Analog Controls, se trovate la parola Dial il gioco utilizzava uno spinner (o un volante tipo A.P.B.), se trovate la parola Track utilizzava una trackball, se il sottomenù Analog Controls non è presente non usava né uno né l'altra. Sempre nel menù Analog Controls è possibile aumentare la sensibilità del dispositivo qualore fosse necessario.

Se aumentando la sensibilità del dispositivo tramite il menù del M.A.M.E. non ottenete l'effetto desiderato potete utilizzare il parametro analog-boost da riga di comando, che di default è disabilitato, ad esempio

Codice: Seleziona tutto

./mame_rpi4 -rompath /home/pi/RetroPie/roms/mamesdlplus arcadecl -analog-boost
Oltre a ciò nel menù del M.A.M.E. c'è la possibilità di configurare l'opzione Boost Analog Sensitivity On/Off per attivare/disattivare l'aumento di sensibilità con il M.A.M.E. in esecuzione premendo semplicemente un pulsante.

TRACKBALL:
https://www.amazon.it/dp/B0774KWCGY/ref ... B0774KWCGY

USB CONNECTION CABLE:
https://www.amazon.it/dp/B008DFVQFW/ref ... B008DFVQFW

|<---| Torna all'indice dei contenuti
Questi utenti hanno ringraziato l'autore Administrator per il post:
JohnTitor
Reputazione: 10%
"A volte sono le persone che nessuno immaginava potessero fare certe cose quelle che fanno cose che nessuno può immaginare" A. Turing
_____________________________________________________________
Aiutiamo il forum con una donazione :-)

Hardware:
Raspberry Pi Model B Rev 2
Raspberry Pi 3 Model B Rev 1.2
Raspberry Pi 4 Model B Rev 1.2

Rispondi