Distro per JammaPi 15Khz Pixel and refresh perfect

[frezeen]

non trovo la documentazione di include.. ad ogni modo retropie , tramite runcommand, lancia advmame che deve per forza lanciare un advmame.rc.. e fin qua ci siamo, io adesso in questo advmame.rc ci metterei un include ad un altro file con altre impostazioni ma a che mi serve,sarebbe uguale per tutte le rom o mi sfugge qualcosa? a meno che non posso usare in advmame.rc qualcosa tipo "include nomerom/nomerom.rc".. ma ho provato e mi da errore e non ho trovato modo di fare una cosa del genere. se ho capito bene questa cosa la potrei usare lanciando un qualche comando da shell con advmenu.. tipo advmemu rom.zip nomerom.rc (senza includere nulla?) ma non funziona nemmeno cosi' o non ho capito come usare advmenu e include per ogni rom... e poi come potrei far lanciare a runcommand advmenu ? se modifico runcommand per lanciare advmenu, appena si aggiorna poi si sputtana.... se modifico il nome advmenu in advmame facendogli credere di lanciare advmame, se poi aggiorno si sputtana uguale.

[frezeen]

per le risoluzioni invece l'uso di advcfg e' esattamente quello che spiega la guida pixel perfect, ed e' quello che fa il profilo "advmame". e' gia' implementato quel modo.. ma ha dei limiti... infatti come vedi nella foto advcfg non genera un 240x240@57 anzi per dire, lui genera solo risoluzioni senza preoccuparsi del refresh. tutto sto discorso, picerno, serve solo per i verticali, perche' degli orizzontali,oggi, te ne puoi dimenticare completamente facendo gestire tutto a mme4crt. 1 perche' advmame funziona solo con gli arcade e solo fino alla 0.106 mentre mme4crt si espande a tutto quello che supporta retroarch con libretro,set nuovi di mame, console e computer compresi e due perche' advmame usando advcfg nemmeno gli orizzontali li setta bene al 100%... se hai provato questa distro, prova a lanciare un gioco neogeo con advalt1 che e' quello che fa advcfg e poi lancia lo stesso gioco tramite runcommand menu con qualsiasi core libretro. vedi le differenze soprattuto sullo scrolling, advmame fa tearing perche' viene settato a 60hz, retroarch no, fluido perche' usa il refresh originale del gioco, qualunque esso sia. potresti fare a meno di advmame al 100% se non fosse che dietro la filosofia di mme4crt c'e' la volonta' di rendere tutto originale, e per lui, se un gioco e' verticale, deve essere eseguito in verticale e infatti cosi' fa, lo esegue in verticale con ress e refresh perfetti. il developer non ha nessuna intenzione di scrivere routine per adattare verticali su scherzi orizzontali o almeno ha detto che posso fare un request, se poi c'e' volonta' di altri ad avere questa cosa, lui ci lavora su anche se mi ha anticipato che serve il supporto alle risoluzioni interlacciate e il raspberry ha problemi di firmware su questo. ti diro' di piu', la risposta in privato e' stata: perche' non usi advmame visto che lui adatta?

[picerno]

non trovo la documentazione di include.. ad ogni modo retropie , tramite runcommand, lancia advmame che deve per forza lanciare un advmame.rc.. e fin qua ci siamo, io adesso in questo advmame.rc ci metterei un include ad un altro file con altre impostazioni ma a che mi serve,sarebbe uguale per tutte le rom o mi sfugge qualcosa?

L'utilizzo di advmenu era un esempio per come l'ho utilizzato io. Il file ha sempre lo stesso nome ma gli cambi il contenuto. In advmame.rc metti sempre la stessa riga "include risoluzioni.rc". Nello script che fa partire i giochi metti un comando prima di lanciare advmame che sostituisce risoluzioni.rc con il tuo file advalt.rc. Esempio "cp advalt.rc risoluzioni.rc"

[picerno]

per le risoluzioni invece l'uso di advcfg e' esattamente quello che spiega la guida pixel perfect, ed e' quello che fa il profilo "advmame". e' gia' implementato quel modo.. ma ha dei limiti... infatti come vedi nella foto advcfg non genera un 240x240@57 anzi per dire, lui genera solo risoluzioni senza preoccuparsi del refresh.

Io parlavo solo di mame, ma non sono d'accordo sul fatto che advcfg setta male le risoluzioni. Forse questo succede con raspberry o con le schede video attuali ma con il pc in dos o linux e le schede video supportate dalla libreria svgalib, le risoluzioni erano quasi tutte fedeli all'originale, senza nessun difetto. Quelle poche che venivano calcolate male si potevano correggere aggiungendole a mano con advv. Il discorso però poteva cambiare da una scheda video all'altra e da come veniva settato advcg, se gli dicevi di avere un monitor che accettava refresh da 58 a 62hz, la risoluzione a 57 originale non l'avrebbe creata. Per avere le risoluzioni originali verticali ci voleva per forza il monitor in verticale e ľinterlacciato sull'orizzontale era l'unica alternativa

[frezeen]

Nello script che fa partire i giochi

e' questo il punto, lo script che esegue e' runcommand di retropie, se lo modifichi e poi aggiorni runcommand perdi le modifiche. su raspberry invece advcfg e relativa config: il neogeo lo setta a 60hz e una risoluzione di 240x240@57 anche se metti che hai un monitor che supporta da 0 a 100hz in automatico non te la crea giusto per fare 2 esempi... ci devi andare tu di advv cosi' come credo succedesse in dos o forse no, non lo so ma anche adesso , ok advcfg ti crea quello che il monitor supporta ma le modeline giuste poi gliele devi dare tu. il raspberry non ha supporto per l'interlacciato e non solo, ha un pixel clock closed... ovvero non funziona con qualsiasi pixel clock, quindi delle risoluzioni native degli arcade ne puoi fare al massimo 7 o 8, le piu' comuni. forse sara' anche per quello che su rpi, advcfg funziona male se non malissimo, sara' limitato dall'hw. resta il fatto che ora non ci interessa piu' , perche' anche su rpi e sugli orizzontali, mme4crt fa tutto in auto e lo fa bene, certo usando le super resolution e fra l'altro solo la 1920x e non le native ma meglio di niente. su windows e linux invece il discorso migliora di tantissimo

[picerno]

e' questo il punto, lo script che esegue e' runcommand di retropie, se lo modifichi e poi aggiorni runcommand perdi le modifiche.

Lo dicevo in alternativa ad andare a modificare advmame con un hex editor. Non si può applicare nemmeno al front-end questo discorso? Se non ti aiuta, come non detto

su raspberry invece advcfg e relativa config: il neogeo lo setta a 60hz e una risoluzione di 240x240@57 anche se metti che hai un monitor che supporta da 0 a 100hz in automatico non te la crea giusto per fare 2 esempi... ci devi andare tu di advv cosi' come credo succedesse in dos o forse no, non lo so ma anche adesso , ok advcfg ti crea quello che il monitor supporta ma le modeline giuste poi gliele devi dare tu. il raspberry non ha supporto per l'interlacciato e non solo, ha un pixel clock closed... ovvero non funziona con qualsiasi pixel clock, quindi delle risoluzioni native degli arcade ne puoi fare al massimo 7 o 8, le piu' comuni. forse sara' anche per quello che su rpi, advcfg funziona male se non malissimo, sara' limitato dall'hw.

Da quello che mi dici sembrerebbe che il sistema automatico di advmame per la generazione delle risoluzioni non funzioni per niente bene su rpi, forse anche per il pixel clock limitato. La cosa è un po' strana anche perché avevo letto del rilascio di nuove versioni proprio per il supporto all'rpi ma i dettagli non li conosco. Io in dos mettevo solo la riga dei limiti del mio monitor in advmame.rc (tramite advcfg o a mano) e advmame già settava quasi tutto alla perfezione da solo, ero io che quando notavo un'imperfezione su una specifica risoluzione la andavo a forzare tramite advv

su windows e linux invece il discorso migliora di tantissimo

Infatti ritengo il pc la scelta migliore per un cabinet, sia perché è più potente, sia perché è più versatile

[frezeen]

Non si può applicare nemmeno al front-end questo discorso? Se non ti aiuta, come non detto

purtroppo no, se usi una distro tipo retropie poi sei vincolato al suo modo strutturale di fare le cose, modifichi una virgola va bene, ma con gli aggiornamenti poi lui rimette i suoi script "a posto". il frontend non lancia direttamente l'emulatore, ma lancia una serie di script racchiusi sotto il nome di "runcommand" che sono tutti collegati fra loro. dovresti abbandonare un qualcosa di "gia' pronto" e partire da zero con script tuoi...che non sarebbe nemmeno complicato da fare, ma resta comunque un lavoraccio. non e' un caso che poi tutte queste soluzioni hardware per collegare raspberry su crt hanno le loro distribuzioni personalizzate proprio per avere maggiore liberta' nelle configurazioni e non avere vincoli.. cmq advmame non e' che non va bene, anzi, senza il grandissimo lavoro di chi sta dietro advmame non ci saremmo goduti belle cose fino ad oggi.e per i verticali sull'orizzontale e' ancora l'unico che ti sistema le cose al meglio senza tanti sforzi. il limite non e' di advmame, ma di sicuro del rasp.

[picerno]

Ho visto un paio di anni fa retropie. Mi ricordo di quel runcommand tutto molto intricato. Io usai attract mode che era abbastanza configurabile e pensavo se magari, prima di lanciare runcommand, non potesse far eseguire un altro script quando si trattava dei verticali, visto che gestisce anche la divisione dei giochi in categorie.
Si advmame è un grande progetto, si difende bene anche dopo oltre 10 anni dal suo abbandono

[frezeen]

effettivamente , tramite attractmode posso lanciare uno script che poi richiama runcommand e questo lo posso fare anche solo per i verticali. una volta completata il test e la scelta idonea per ogni rom fra i 3 profili disponibili, posso creare uno script che segue questa logica di selezione... ma cosi' facendo , renderei difficoltoso poi andare a modificare magari a szelezione di un profilo. per farlo devo modificare una list.txt preconfigurata da me di default. mmmm ora funziona cosi', lanci il gioco, se premi un tasto entro 1 secondo nella schermata di loading, si apre il menu e selezioni i profili. e' molto funzionale e semplice.. devo vedere un po' come fa... cmq ottimo consiglio, grazie

[picerno]

cmq ottimo consiglio, grazie

Mi fa piacere averti dato uno spunto, magari ti servirà un'altra volta