[OLD] FEEL - NEWS E PROPOSTE

[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

[dR.pRoDiGy]

Ma questo non è un layout generico Marco.. E' il tuo di guida!!

[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 )

[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..

[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

[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).

[dR.pRoDiGy]

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..

[isaac]

Per problemi tecnici non vi ho potuto seguire per un bel po', ma ora sono di nuovo in carreggiata.
Vedo con piacere che ci sono tante novità !! Che figata !!

[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

[dR.pRoDiGy]

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.

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..