Pagina 49 di 109
Re: FEEL 1.5
Inviato: 28/06/2014, 0:20
da dR.pRoDiGy
Okkei, 1.5.3 rilasciata
Novità:
- supporto per font aggiuntivi (bisogna sempre generarli in xnb, ma ora, se disponibile, viene usato il font scelto nei parametri del layout, invece che sempre l'arial)
- fix bassa luminosità prima dell'autostart
- fix piccolo glitch grafico ad avvio video
- ottimizzazioni
Enjoy
Re: FEEL 1.5
Inviato: 29/06/2014, 8:55
da baritonomarchetto
Testato e non ho riscontrato problemi, grande!
Io continuo ad avere gli snap che non si ridimensionano, che codec mi consigli per risolvere?
Per quanto riguarda i nuovi fonts, per la cronaca, ricordate di usare il nome del file xnb (senza la parte finale che descrive la dimensione e stile), non il nome del font vero e proprio (quindi esempio agencyfb, non Agency FB)
[RICHIESTA] opzione show_mechanical
Inviato: 29/06/2014, 12:10
da pucci
così come c'è una bella opzione "show_clones", io ne aggiungerei una "show_mechanical" di default imposta a 0
che ne dici?
Re: FEEL 1.5
Inviato: 29/06/2014, 12:30
da griffon
Testato un po' e per ora funziona alla grande, in particolare la questione font alternativi.
Vi allego una schermata del mio menu con i font modificati. Il layout ha come base quello di Adolfo, stuprato bellamente(?) per adattarlo alle mie esigenze
PS.: Feel mente. Anche se è la 1.5.3.ultimaversione, scrive che è ancora la 1.5.0
Re: [NEW FEATURE] opzione show_mechanical
Inviato: 30/06/2014, 10:45
da dR.pRoDiGy
Ciao Pucci, la richiesta è chiara, ma su quali campi/valori del file xml dovrebbe filtrare?
Re: FEEL 1.5
Inviato: 30/06/2014, 10:49
da dR.pRoDiGy
Ebbravo griffon, ottimo lavoro!
PS: cosa intendi con "mente"? Nel tuo screenshot si legge chiaramente "F.E.E.L. 1.5.3"..
Re: FEEL 1.5
Inviato: 30/06/2014, 15:38
da griffon
Re: [NEW FEATURE] opzione show_mechanical
Inviato: 30/06/2014, 21:43
da pucci
viewtopic.php?f=56&t=8749&hilit=mame+cl ... =30#p95954
ismechanical <> NULL
se vuoi fare il figo:
viewtopic.php?f=56&t=8749&hilit=mame+cl ... =50#p96894
aggiunge anche in un seconda condizione (in AND con la prima):
screen <> NULL
Re: [RICHIESTA] opzione show_mechanical
Inviato: 30/06/2014, 23:01
da dR.pRoDiGy
Okkei, allora confesso che non sapevo la definizione di mechanical!
Il fatto è che l'attributo ismechanical non so da dove venga! Ho guardato il file xml di mame 133u3 (la versione che uso io da tempo immemore), ma non c'è
I casi sono 2:
- l'attributo è stato aggiunto in versioni mame "recenti"
- l'informazione viene desunta da Mame Clean da altre info (che so, se i control non sono 2-3-4 joy, o volanti, o, o, o .. è mechanical)
Tu ne sai un pò di più?
Re: [RICHIESTA] opzione show_mechanical
Inviato: 30/06/2014, 23:16
da motoschifo
Io l'attributo ismechanical l'ho sempre visto da quando uso il Mame, dipende poi da quale xml usi per generare le liste.
Ad esempio questo è il risultato di "mame -listxml mslug":
<?xml version="1.0"?>
<!DOCTYPE mame [
<!ELEMENT mame (game+)>
<!ATTLIST mame build CDATA #IMPLIED>
<!ATTLIST mame debug (yes|no) "no">
<!ATTLIST mame mameconfig CDATA #REQUIRED>
<!ELEMENT game (description, year?, manufacturer?, biosset*, rom*, disk*, device_ref*, sample*, chip*, display*, sound?, input?, dipswitch*, configuration*, adjuster*, driver?, device*, slot*, softwarelist*, ramoption*)>
<!ATTLIST game name CDATA #REQUIRED>
<!ATTLIST game sourcefile CDATA #IMPLIED>
<!ATTLIST game isbios (yes|no) "no">
<!ATTLIST game isdevice (yes|no) "no">
<!ATTLIST game ismechanical (yes|no) "no">
<!ATTLIST game runnable (yes|no) "yes">
<!ATTLIST game cloneof CDATA #IMPLIED>
<!ATTLIST game romof CDATA #IMPLIED>
<!ATTLIST game sampleof CDATA #IMPLIED>
<!ELEMENT description (#PCDATA)>
<!ELEMENT year (#PCDATA)>
<!ELEMENT manufacturer (#PCDATA)>
<!ELEMENT biosset EMPTY>
...
...
Se vuoi scaricarti il
mio programmino, scritto in C#, trovi anche alcuni esempi di raggruppamenti/pulizia per ignorare alcune tipologie di rom (es. working, nogood, imperfect, ecc).
Re: [RICHIESTA] opzione show_mechanical
Inviato: 30/06/2014, 23:18
da griffon
La prima che hai detto.
TI incollo un esempio dal mio mame.xml del mame 0.153:
Codice: Seleziona tutto
<game name="zekepeak" sourcefile="icecold.c" ismechanical="yes" cloneof="icecold" romof="icecold">
<description>Zeke's Peak</description>
<year>1983</year>
<manufacturer>Taito</manufacturer>
<rom name="zp23.bin" size="8192" crc="ef959586" sha1="7f8a4787b340bfa34180164806b181b5fb4e5cfa" region="maincpu" offset="e000"/>
<rom name="zp24.bin" size="8192" crc="ee90c8f5" sha1="27a513000e90536e485ccdf43786b415b3c95bd7" region="maincpu" offset="c000"/>
<device_ref name="m6809"/>
<device_ref name="pia6821"/>
<device_ref name="pia6821"/>
<device_ref name="pia6821"/>
<device_ref name="i8279"/>
<device_ref name="timer"/>
<device_ref name="timer"/>
<device_ref name="speaker"/>
<device_ref name="ay8910"/>
<device_ref name="ay8910"/>
<chip type="cpu" tag="maincpu" name="M6809" clock="1500000"/>
<chip type="audio" tag="mono" name="Speaker"/>
<chip type="audio" tag="ay0" name="AY-3-8910A" clock="1500000"/>
<chip type="audio" tag="ay1" name="AY-3-8910A" clock="1500000"/>
<sound channels="1"/>
<input players="1" coins="1" service="yes">
<control type="doublejoy" ways="vertical2" ways2="vertical2"/>
</input>
<dipswitch name="Automatic Attract Mode" tag="DSW3" mask="1">
<dipvalue name="Off" value="0"/>
<dipvalue name="On" value="1" default="yes"/>
</dipswitch>
<dipswitch name="Rounds to Complete to Light Star" tag="DSW3" mask="2">
<dipvalue name="1 Frame" value="0" default="yes"/>
<dipvalue name="2 Frames" value="2"/>
</dipswitch>
<dipswitch name="Automatic Attract Mode Delay" tag="DSW3" mask="12">
<dipvalue name="1 Min" value="0" default="yes"/>
<dipvalue name="5 Min" value="4"/>
<dipvalue name="10 Min" value="8"/>
<dipvalue name="15 Min" value="12"/>
</dipswitch>
<dipswitch name="Manual Attract Mode Delay" tag="DSW3" mask="48">
<dipvalue name="0 Min" value="0" default="yes"/>
<dipvalue name="2 Min" value="16"/>
<dipvalue name="5 Min" value="32"/>
<dipvalue name="10 Min" value="48"/>
</dipswitch>
<dipswitch name="Difficulty (Prompt Time)" tag="DSW3" mask="192">
<dipvalue name="Easy (5, 4, 2, 1)" value="0" default="yes"/>
<dipvalue name="Factory (4, 2, 1, 1)" value="64"/>
<dipvalue name="Hard (2, 2, 1, 1)" value="128"/>
<dipvalue name="X-Hard (1, 1, 1, 1)" value="192"/>
</dipswitch>
<dipswitch name="Dispense Option" tag="DSW4" mask="7">
<dipvalue name="Disabled" value="0" default="yes"/>
<dipvalue name="2 Tickets after Hole 6, 3 Tickets after Hole 10" value="1"/>
<dipvalue name="1 Ticket after Holes 5 - 10" value="2"/>
<dipvalue name="No Tickets Dispensed" value="3"/>
<dipvalue name="5 Tickets after Hole 5" value="4"/>
<dipvalue name="No Tickets Dispensed" value="5"/>
<dipvalue name="5 Tickets after Hole 10" value="6"/>
<dipvalue name="No Tickets Dispensed" value="7"/>
</dipswitch>
<dipswitch name="Coin A" tag="DSW4" mask="8">
<dipvalue name="2 Coins/1 Credit" value="0"/>
<dipvalue name="1 Coin/1 Credit" value="8" default="yes"/>
</dipswitch>
<dipswitch name="Score for Extra Ball" tag="DSW4" mask="48">
<dipvalue name="No Extra Ball" value="0" default="yes"/>
<dipvalue name="2000" value="16"/>
<dipvalue name="4000" value="32"/>
<dipvalue name="8000" value="48"/>
</dipswitch>
<dipswitch name="Bonus Countdown Speed" tag="DSW4" mask="192">
<dipvalue name="Slow" value="0" default="yes"/>
<dipvalue name="Factory" value="64"/>
<dipvalue name="Fast" value="128"/>
<dipvalue name="X-Fast" value="192"/>
</dipswitch>
<port tag=":DSW3">
</port>
<port tag=":DSW4">
</port>
<port tag=":TEST">
</port>
<port tag=":JOY">
</port>
<port tag=":X0">
</port>
<port tag=":X1">
</port>
<port tag=":X2">
</port>
<driver status="preliminary" emulation="preliminary" color="good" sound="good" graphic="good" savestate="unsupported"/>
</game>
EDIT: azzo, doppia risposta a tipo 20 secondi di distanza
Re: Richiesta - bezel multipli per layout
Inviato: 30/06/2014, 23:38
da dR.pRoDiGy
Re: Richiesta - bezel multipli per layout
Inviato: 01/07/2014, 6:51
da baritonomarchetto
Eh certio,si. Il discorso animazioni, effetti etc vale per tutti i tipi di layout però! (Non ce la faccio a fartene un ad-hoc senza la feature inserita... un po' di immaginazione
)
Re: [RICHIESTA] opzione show_mechanical
Inviato: 01/07/2014, 23:54
da dR.pRoDiGy
Ci ho ragionato un pò su ragazzi..
Purtroppo questa cosa non si può proprio fare, perchè richiederebbe di modificare i formati dei file lista (*.lst) per salvare anche quel parametro.
Questo porterebbe a:
- rottura compatibilità con le liste mamewah (male), perdendo anche la possibilità di usare tutti i relativi tool esterni
- rottura compatibilità con le liste di *tutte* le precedenti versioni di FEEL (malissimo!
), con necessità di ricrearle tutte da zero
Mi spiace ma di qui non ci si scappa proprio..
Re: [RICHIESTA] opzione show_mechanical
Inviato: 02/07/2014, 1:23
da motoschifo
Non conosco come è strutturato Feel, ho visto solo screenshot e qualche video, comunque l'idea di essere "limitati" nell'impostazione di questi parametri mi sembra qualcosa di molto forte.
Mi spiego meglio: usando xml per memorizzare i dati, se ci sono parametri in più vengono ignorati dalle vecchie versioni e non ci sono problemi, mentre invece le nuove possono sfruttarle (come ad esempio è il formato del Mame).
In ogni modo hai una mina vagante perchè molto probabilmente stai spostando il problema... quindi non sarà oggi, ma domani dovrai rompere la compatibilità per forza se vorrai estendere qualcosa di non previsto.
Però mi sembra strano... cioè una volta dentro al front-end, se sai che è mechanical lo togli e basta no? Mi sfugge il motivo per cui mamewah non possa leggere più nulla o del perchè le vecchie liste siano tutto da buttare.
Parlo da profano si intende, magari se hai maggiori dettagli puoi inviarmeli in pm senza sporcare il thread
Re: [RICHIESTA] opzione show_mechanical
Inviato: 02/07/2014, 10:51
da griffon
Feel e mamewah non usano xml, ma un file piano di testo.
Quindi o il dottore molla/converte le vecchie liste in xml (le si importa con un tool o similari), ma credo sia una gran rottura di palle, o ci teniamo i mechanical (che, per inciso, odio anche io fortissimamente).
Re: [RICHIESTA] opzione show_mechanical
Inviato: 02/07/2014, 12:49
da dR.pRoDiGy
motoschifo ha scritto:Non conosco come è strutturato Feel, ho visto solo screenshot e qualche video, comunque l'idea di essere "limitati" nell'impostazione di questi parametri mi sembra qualcosa di molto forte.
Mi spiego meglio: usando xml per memorizzare i dati, se ci sono parametri in più vengono ignorati dalle vecchie versioni e non ci sono problemi, mentre invece le nuove possono sfruttarle (come ad esempio è il formato del Mame).
In ogni modo hai una mina vagante perchè molto probabilmente stai spostando il problema... quindi non sarà oggi, ma domani dovrai rompere la compatibilità per forza se vorrai estendere qualcosa di non previsto.
Però mi sembra strano... cioè una volta dentro al front-end, se sai che è mechanical lo togli e basta no? Mi sfugge il motivo per cui mamewah non possa leggere più nulla o del perchè le vecchie liste siano tutto da buttare.
Parlo da profano si intende, magari se hai maggiori dettagli puoi inviarmeli in pm senza sporcare il thread
Beh, perdonami, prima di parlare di "mine vaganti" o "spostare i problemi", non pensi sarebbe il caso di provarlo almeno, il prodotto?
Non fa niente, spiegherò lo stesso a beneficio di tutti.
Ad avvio progetti (informatici e non) ci sono sempre scelte tecniche preliminari da prendere, che portano pro e contro e condizionano, in misura variabile, tutta la vita del progetto stesso.
In FEEL, una di queste è che il formato *interno* (per la sua creazione viene cmq parsato l'xml di MAME) delle liste è in testo piano, delimitato solo da a capo, che ha corrispondenza diretta field-by-field con le classi interne che rappresentano le rom.
I pro sono che:
- il formato è lo stesso di MameWah. Questa compatibilità permette di importare le sue liste direttamente, e utilizzare tool già esistenti (es.: Mame Clean, progetto Emma, altri) per crearne di nuove
- vista l'estrema semplicità del formato, una lista di varie migliaia di titoli può venire caricata in memoria in pochi millisecondi, a differenza dell'xml (o mini-database su disco, o qualunque altra cosa ti venga in mente), che richiede secondi per il parsing.
Un contro è sicuramente l'impossibilità di estendere la lista con parametri in più, ma considerato che MameWah esiste da 10 anni e continua ad essere uno dei FE più nominati e apprezzati, mi fa pensare che la cosa non sia così drammatica
Non si desiderano i mechanical? Si apre Mame Clean (che permette un milione di cose in più che FEEL non farà mai, per scelta!), si disabilitano, si crea la lista pulita di proprio gusto, e si copia così com'è nella cartella data di FEEL. Facile e pratico.
A mio vedere dovrebbe essere così anche per il filtro dei cloni, ma quella funzione è stata aggiunta a FEEL in un tempo remoto in cui non ero ancora io a sviluppare, e là è rimasta.
PS: non è da escludere che in un domani più o meno lontano questa e altre scelte progettuali possano venire messe in discussione e FEEL venga completamente ridisegnato, ma spero converrai con me che rompere la compatibilità con 3 anni di storia di FEEL (per sopprimere i mechanical con un parametro!) sia quantomeno poco conservativo e rispettoso degli utenti che in tutto questo tempo l'hanno adottato e lo usano con passione..
Re: FEEL 1.5
Inviato: 02/07/2014, 18:01
da isaac
Re: [RICHIESTA] opzione show_mechanical
Inviato: 02/07/2014, 19:23
da motoschifo
In effetti "mina vagante" forse è stato un po' eccessivo... diciamo un possibile problema con la compatibilità per le versione precedenti
Però mi hai già risposto dicendo che è stato scelto di gestire liste semplici e formati già usati da altri software, quindi il problema non si pone nemmeno fino a quando loro non cambieranno metodo di generazione liste (probabilmente mai).
Il discorso su database o xml che rallentano è corretto, ma a volte ne vale la pena: se devo filtrare su più campi con particolari metodi, molto meglio una query o un semplice albero xml che una scansione di tutto il file come si faceva una volta. Poi ci sono i casi in cui questa logica occupa solo risorse inutilmente e che sarebbe meglio lasciare agli emulatori. Per esempio salvarsi in memoria l'xml del Mame completo è pura follia perchè sarebbe un spreco di risorse enorme. Anzi, di default sistemi come C# vanno in crash anche solo con 10 mila elementi, io per fargli digerire tutte le rom ho dovuto usare qualcosa di alternativo.
Stando così le cose, la mia proposta è questa: gestire due sistemi di input "semplice" ed "esteso".
Quindi lista normale come ora ed in più la possibilità di leggere un formato che dia modo di gestire più campi e che non sia limitato per espensioni future (es. xml). I parametri aggiuntivi non avrebbero effetto nel primo caso ma lo avrebbero sul secondo. Ovviamente chi crea le liste sa cosa fa e quindi sceglie quale metodo sfruttare.
Si tratta di un suggerimento, valuta tu se c'è interesse per questa cosa
Re: [RICHIESTA] opzione show_mechanical
Inviato: 02/07/2014, 22:49
da dR.pRoDiGy
motoschifo ha scritto:
Il discorso su database o xml che rallentano è corretto, ma a volte ne vale la pena: se devo filtrare su più campi con particolari metodi, molto meglio una query o un semplice albero xml che una scansione di tutto il file come si faceva una volta. Poi ci sono i casi in cui questa logica occupa solo risorse inutilmente e che sarebbe meglio lasciare agli emulatori. Per esempio salvarsi in memoria l'xml del Mame completo è pura follia perchè sarebbe un spreco di risorse enorme. Anzi, di default sistemi come C# vanno in crash anche solo con 10 mila elementi, io per fargli digerire tutte le rom ho dovuto usare qualcosa di alternativo.
Infatti in FEEL è implementato un parser custom, che sostanzialmente lavora come una libreria SAX, così possiamo supportare xml di qualsiasi dimensione (vd. MAME molto recenti). Di lì in poi si usano solo le liste interne, molto più veloci.
motoschifo ha scritto:
Stando così le cose, la mia proposta è questa: gestire due sistemi di input "semplice" ed "esteso".
Quindi lista normale come ora ed in più la possibilità di leggere un formato che dia modo di gestire più campi e che non sia limitato per espensioni future (es. xml). I parametri aggiuntivi non avrebbero effetto nel primo caso ma lo avrebbero sul secondo. Ovviamente chi crea le liste sa cosa fa e quindi sceglie quale metodo sfruttare.
Si tratta di un suggerimento, valuta tu se c'è interesse per questa cosa
La questione non è solo di compatibilità, ma anche di "scope di progetto": FEEL è pensato per essere leggero al massimo, e un appesantimento delle operazioni sulle liste (come nel caso dell'adozione di xml o db) finirebbe per peggiorare la fluidità dell'interfaccia (tutta la UI è sviluppata custom come in un videogame, e non con i classici controlli event-driven di windows, quindi tutte le operazioni girano nel thread principale che disegna la grafica).
Inoltre, l'idea di base è che le liste all-games "speciali" (ovvero diverse dalla lista completa delle rom disponibili) vengano preparate con tool esterni (se servono cose molto particolari è molto meglio usare strumenti specifici: anche volendo FEEL non potrebbe mai gestire tutte le possibili necessità dalla sua interfaccia "low-res"), e FEEL venga usato come frontend puro, a cose fatte e finite. Per questo non ci sono opzioni di questo tipo (il caso del filtro clones come detto è un'eccezione).
In breve, se si cambierà, lo si farà per stravolgere completamente tutta la logica della configurazione di FEEL.. non ti nego che ce l'ho in mente da un pò, ma non sarà certo nè domani nè dopodomani..
