Progetto BarettoCab

[eldiau]

Mi sa che per pura pigrizia utilizzero la 3 nel cab cosi' non devo smontare nulla!

Confermo che con uno qualsiasi dei i seguenti parametri:
use_bezels 1
use_cpanels 1
use_marquees 1
mame rallenta parecchio sia su windows xp che su linux, anche aggiungendo "artwork_crop 1" che dovrebbe evitare ridimensionamenti del video per far spazio all'artwork, non che sia una problema enorme, per me la cosa aveva senso solo per riempire i bordi neri dei giochi verticali su monitor orizzontali....

[Puccilillo]

use_cpanels 1
use_marquees 1

Ok per i bezel... ma marquee e cpanels non li sapevo proprio ma è vero?

EDIT: avevo risposto da me ma è meglio scrivere qua!

Come ti trovi con la grafica.. Io ho trovato un tipo in locale qua che per 25€ al mq mi fa la stampa su pvc (bianco adesivo).

Per un totale di 100x50 cm spendo 12,50€
Solo che il tipo mi sconsiglia il pvc perché poi col tempo si rovina... che materiale hai preso per il controllo?
Ho visto che parli di vinile plastificato (cosa che mi dice il tipo essere il pvc a doppio strato, uno colorato e l'altro trasparente).
E' esatto? Quanto hai speso per le tue? ...e dove hai trovato il marquee di mario e il cpanel?

[eldiau]

si, con use_cpanels 1e use_marquees 1 li disegna sopra e sotto allo schermo, penso solo nelle versioni recenti, io lo ho visto sulla .145

Con la grafica mi son trovato bene, la stampa e' molto ben fatta, il marquee sul cab di mario e' troppo trasparente, dovro' dargli uno strato di qualche vernice opaca, ma quella era la stampa per vetrofanie.

Io ho preso PVC monomerico plastificato, anche se secondo me non lo hanno plastificato ma e' la prima volta che lo vedo quindi e difficile da dire. In effetti sembra delicato ma ora non saprei dirti, vedremo con l'uso, al massimo lo faro' ristampare, poco male.

Il marquee di mario e' quello originale preso da qui http://vectorlib.free.fr/MarioBross/ su consiglio di bopaul, il control panel lo ho ridisegnato io prendendo elementi dal control panel originale di mario e da altre grafiche mentre il cpanel stile anni 80 lo ho disegnato da zero ispirandomi al marquee dell'altro cab, se vuoi te lo passo ma e' molto specifico per le misure del mio control panel.

Ecco i costi:
€ 9.77 Stampa cpanel Vinile adesivo monomerico opaco, Plastificazione No filtro opaca, 54x36 ne ho fatti due uno mario bros e l'altro anni 80
€ 15.28 Stampa bezel Vinile adesivo trasparente speculare 55x53
€ 18.88 Stampa marquee Vinile adesivo opalino per retroilluminazione 54x15

Quindi il tuo 100x50 cm a 12,50€ mi sembra un buon prezzo, ma per un confronto serio bisognerebbe sapere il tipo di stampa, la risouzione e la qualita' del vinile. Lui cosa ti propone al posto del vinile che non si rovini facilmente?

[Puccilillo]

Il tipo mi consiglia la plastificazione per far durare il prodotto nel tempo.
Il problema che non ho considerato è questo: 100x50 è 1/2 mq.. il minimo è 1 mq quindi ha un costo di 25€al mq che mi sembra esagerato rispetto al prezzo online.
E poi sarebbe in un materiale unico.. nel caso di più materiali tipo base trasparente o bianca il costo sarebbe raddoppiato cioè di 1 mq per ogni materiale.

Se ti ritieni soddisfatto penso che acquisterò anche io da pixarprinting... digli di farti uno sconto la prossima volta che gli porti i clienti

[eldiau]

Hahaha ma io sono stato consigliato a mia volta sul forum

[Puccilillo]

PS Oltre al cab e al layout ora ti ho fregato anche la firma...

[eldiau]

A me il tuo cab sembra decisamente originale! Comunque se il mio lavoro ti ha ispirato ne sono onorato.

[Puccilillo]

Secondo te... il marquee avresti potuto anche farlo con lo stesso sistema del bezel, sarebbe abbastanza trasparente il pvc per farne un marquee dall'interno?

[eldiau]

Sarebbe troppo trasparente, quello che pixartprinting vende col nome di "pvc per vetrofanie" e troppo trasparente anche per il bezel, per cui, sul cab del mio amico, quello in "stile mario bros", dovremo trovare un modo di verniciare il bordo di bianco opaco sotto all'adesivo, questa foto della grafica applicata al vetro rende bene il problema, e' stata fatta su una tovaglia a quadretti apposta:

DSCN1439.JPG

Per il marquee si puo' fare un sandwich con un plexy bianco semitrasparente dietro, la grafica in mezzo e poi il vetro davanti il tutto viene tenuto insieme dalle due cornici ad L che reggono il marquee, oppure si puo' fare una stampa sul materiale che sempre pixartprinting chiama PVC opalino per retroilluminazione, anche in questo caso e' consigliabile usare la tecnica "sandwich" per proteggere la stampa.

[Ansa89]

Probabilmente mi orientero' su Lubuntu, semplice e leggero

Come fai a spiegare a Lubuntu che deve uscire a 15KHz?
Metti solo una modeline in Xorg o ricompili anche il kernel (per avere le tty in caso di bisogno)?

Nel secondo caso, ti posso passare le patch (aggiornate per l'ultima versione del kernel) per avere l'uscita a 15KHz appena viene abilitato il KMS.

[Puccilillo]

E infatti è quello che temevo....ma a questo punto conviene fare tutto senza trasparenze.
Grazie per aver fatto da cavia no, scherzi a parte: io farei bianco l'Interno del bezel anche con una bomboletta.

[eldiau]

E' proprio quello che pensavo di fare, solo che il vinile e' incollato dall'interno quindi la vernice andrebbe direttamente sul foglio di plastica per cui non idea di che vernice utilizzare, ho paura che il solvente della vernice rovini il vinile. una altra possibilita' e' quella di incollare un altro strato di plastica bianca adesiva.

[eldiau]

Come fai a spiegare a Lubuntu che deve uscire a 15KHz?
Metti solo una modeline in Xorg o ricompili anche il kernel (per avere le tty in caso di bisogno)?
Nel secondo caso, ti posso passare le patch (aggiornate per l'ultima versione del kernel) per avere l'uscita a 15KHz appena viene abilitato il KMS.

Inzialmente ho intenzione di utilizzare uno schermo LCD che ho in cantina, cosi mi tolgo tutti i problemi , dopo tutto sto tempo a lvorarci su ho voglia di giocare! Poi perche' rendere i giochi sia verticali che orizzonatli su un 15Khz senza girarlo e' impossibile a meno di non cambiare le frequenza di refresh e quindi la velocita' del gioco, preferisco dare priorita' alla corretta esecuzione del gioco piuttosto che alla visualizzazione piu' "originale", se avessi due cab uno verticale e uno orizzontale sarebbe il massimo ma verrei cacciato di casa , poi ho fatto varie prove e sono molto soddisfatto della resa con il CRT simulato in GLSL. In ogni caso ho assemblato un supporto per l'LCD che si monta esattamente come il monitor arcade quindi in qualsiasi momento posso decidere di cambiare idea:

lcd.jpg

anche il cablaggio e' tutto fatto in standard jamma.
In ogni caso ti ringrazio, passami le patch che sicuramente provero' anche il CRT per fare poi una scelta definitiva "informata"! Per quanto riguarda le modlines su X pesavo di fare esattamente come hai descritto, non mi risulta ci siano limiti nella quantita' di modlines inseribili in xorg.conf, al contrario di windows dove si e' costretti ad usare i driver di calamity proprio il basso numero di risoluzioni, quindi in teoria sarebbe possibile crearsi una collezione di modelines, sicuramente una certa quantita' si possono copiare direttamente dai driver di calamity, per avere tutti i giochi pixel perfect con anche vertical refresh corretto, sempre con la limitazione di usare solo giochi verticali o solo giochi orizzontali (nel mio cab posso ruotare lo schermo ma devo sfilarlo e riinfilarlo quindi non e' certo un operazione da fare frequentemente) inoltre esattamente come succede con le PCB ad ogni cambio gioco devi mettere mano ai potenziometri, ma con la semplificazione che mantenendo i timinig corretti si puo' agire sui tempi di horizontal e vertical blank per allargare o stringere sia in verticale che orizzontale la particolare risoluzione rendendo piu' uniformi i vari giochi.
Tra l'altro c'e' un bel documento, molto semplice, sul funzionamento dei moniotr http://kirurg.org/emame/timing/ e http://kirurg.org/emame/arcadetiming/ che vale assolutamente la pena leggere!

[Ansa89]

Io ho solo una modeline in Xorg, che serve per visualizzare il frontend; poi groovymame (o switchres) cambia automaticamente la risoluzione dello schermo a seconda del gioco avviato (i due tool fanno abbondante uso di xrandr).
In questo modo riesco a giocare anche a titoli verticali (più o meno pixel perfect) sul mio schermo orizzontale alla giusta velocità di esecuzione.

[eldiau]

Ottimo! Appena finisco il cab lo provo di sicuro, grazie.

A proposito di groovymame il repo git non funziona:

Codice: Seleziona tutto

[1000] diego@mother ~/tmp> git clone git://git.groovy.org/groovy/groovymame0143.git
Cloning into groovymame0143...
fatal: The remote end hung up unexpectedly

Il sito e' un gran casino con il grovymame sparso fra alcune pagine separate per versione 142 e 143 e poi il resto mischiato insieme ai driver ATI, la versione precompilata per linux (groovymame64_0145u5.013f_wiimote_linux.tar.bz2) non va su Ubuntu 11.10 per incompatibilita' fra glibc

Codice: Seleziona tutto

[1004] diego@mother ~/tmp> ./groovymame 
bash: ./groovymame: No such file or directory
[1005] diego@mother ~/tmp> ldd groovymame 
./groovymame: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by ./groovymame)

e 0145_groovymame_013e.diff non si applica correttamente, anche dopo aver applicato la hiscore, anche se non capisco perche la patch di groovy debba dipendere da una patch per gli hiscore...
Tu hai dei sorgenti compilabili? O sai indicarmi dove sbaglio

Calamity dovrebbe fare una bella pulizia! Considerando anche che c'e' un sacco di gente che usa il suo codice!

[Ansa89]

Non usare il repo git: è outdated e non lo aggiorna più nessuno.
Confermo che il sito ufficiale di groovymame/groovyarcade è un gran casino, ma dopo un po' ci si fa l'abitudine e si capisce dove guardare.
La patch di groovymame dipende da quella per gli highscore per scelta progettuale: groovymame supporta gli highscore e non ha il nag-screen.

Probabilmente non riesci ad applicare la patch perché i sorgenti di mame usano la codifica CR-LF tipica del dos, mentre la patch usa la codifica LF tipica di unix.
Soluzione: installa il pacchetto "dos2unix" (che dovrebbe contenere anche l'eseguibile "unix2dos") e poi

Codice: Seleziona tutto

unix2dos groovymame_patch.diff

Adesso dovrebbe riuscire ad applicare la patch senza problemi.


[OT] Si potrebbe aprire una discussione infinita sul fatto che Calamity usi la codifica LF invece di CR-LF; così come gli sviluppatori di mame usano CR-LF invece di LF, si ostinano a distribuire i sorgenti come archivio zip e usano patch incrementali che vanno applicate con "-p0" invece del classico "-p1". [/OT]

[eldiau]

Acc!!! Avevi ragione, dopo la passata a unix2dos funziona, non ci avrei mai pensato... dovrebbe scriverlo sul sito!!! O meglio visto che la patch e' riferita ad un albero sorgente codificato con CRLF dovrebbe avere di logica la stessa codifica... ma sto' zitto perche' io ho fatto la stessa ca77ata con la patch cave vado subito ad aggiornarla!

Compilato... ho dovuto aggiungere

Codice: Seleziona tutto

CCOMFLAGS = -Wno-unused-but-set-variable

nel makefile

[Ansa89]

ma sto' zitto perche' io ho fatto la stessa ca77ata con la patch cave vado subito ad aggiornarla!

È vero, infatti ho dovuto passare la patch con dos2unix.
Piccola precisazione: io faccio il contrario, cioè converto tutti i sorgenti di mame in LF e tengo le patch in LF (in fondo io uso linux, non windows).

Compilato... ho dovuto aggiungere

Codice: Seleziona tutto

CCOMFLAGS = -Wno-unused-but-set-variable

nel makefile

Quello potrebbe essere dovuto alla versione di gcc che usi (io non l'ho mai aggiunto).
Altro consiglio: nel "makefile" ci sono due variabili (che di default sono commentate) usate per aggiungere un prefisso e/o un suffisso all'eseguibile che verrà creato:

Codice: Seleziona tutto

#-------------------------------------------------
# configure name of final executable
#-------------------------------------------------

# uncomment and specify prefix to be added to the name
# PREFIX =

# uncomment and specify suffix to be added to the name
# SUFFIX =

Io di solito imposto "PREFIX = groovy".

[eldiau]

Piccola precisazione: io faccio il contrario, cioè converto tutti i sorgenti di mame in LF e tengo le patch in LF (in fondo io uso linux, non windows).

Vero, anche se il mame e' storicamente un progetto MS-DOS. Come lo converti? io ho fatto un bel "find ./ -type f -exec dos2unix {} \;" passa anche file binari ma dos2unix e' abbastanza intelligente da convertire solo i file corretti.

Altro consiglio: nel "makefile" ci sono due variabili (che di default sono commentate) usate per aggiungere un prefisso e/o un suffisso all'eseguibile che verrà creato: Io di solito imposto "PREFIX = groovy".

Si, mi sembra ragionevole dovrebbero metterlo di default nella patch, ho fatto qualche esperimento con groovymame, notevole! Appena finisco il cablaggio interno del cab lo mettero' alla prova con il mio hantarex 900e.

Pero' bitbytebit e Calamity devono mettere ordine in quel tremendo sito!! Non dico tanto, ma almeno la roba giusta nelle cartelle giuste fatti dare un login e mettiglielo in ordine tu! Altrimenti facciamogli un sito noi con un minimo di grafica decente sono piccole cose che aiutano in maniera spaventosa la diffusione di un software.

Piccola curiosita', la mia macchina principale e' un ubuntu 64bit quella nel cab provvisoria un 32bit e non volendo installarmi tutto l'ambiente per il cross compiling ho provato a compilare sul cab... bene con 512Mb di ram (+512Mb di swap) non si riesce a compilare mame l'assurdita' e' che gcc 4.6 da questo errore:

Codice: Seleziona tutto

Generating TMS57002 source file...
obj/groovysdl/build/tmsmake src/emu/cpu/tms57002/tmsinstr.lst obj/groovysdl/emu/cpu/tms57002/tms57002.inc
Compiling src/emu/cpu/tms57002/tms57002.c...
{standard input}: Assembler messages:
{standard input}:1594: Warning: end of file not at end of a line; newline inserted
{standard input}: Error: .size expression for _ZL18cpu_reset_tms57002P17legacy_cpu_device does not evaluate to a constant
gcc: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.6/README.Bugs> for instructions.
make: *** [obj/groovysdl/emu/cpu/tms57002/tms57002.o] Error 4

riprovato con 1Gb di ram, tutto ok

[Ansa89]

Come lo converti? io ho fatto un bel "find ./ -type f -exec dos2unix {} \;" passa anche file binari ma dos2unix e' abbastanza intelligente da convertire solo i file corretti.

Stesso identico comando (sempre confidando nell'"intelligenza" di dos2unix).

Pero' bitbytebit e Calamity devono mettere ordine in quel tremendo sito!! Non dico tanto, ma almeno la roba giusta nelle cartelle giuste fatti dare un login e mettiglielo in ordine tu! Altrimenti facciamogli un sito noi con un minimo di grafica decente sono piccole cose che aiutano in maniera spaventosa la diffusione di un software.

Dalle ultime notizie che avevo io, bitbytebit è completamente impegnato in un trasloco + impegni familiari (sta cambiando casa), quindi ha completamente mollato tutti i progetti di cui si occupava.
Piuttosto che farmi dare l'accesso al sito ftp ufficiale, IMHO sarebbe meglio creare un nuovo sito con un'impaginazione decente e magari appoggiarsi al sito ufficiale solo per i link dei download. Il problema è che io non ho il tempo per fare questo .
In parole povere dovresti fare tutto tu, trovando un dominio, uno spazio web e creare il template per il sito.
Per il resto sono d'accordo quando dici che sono queste piccole cose ad aiutare la diffusione di un software.

Piccola curiosita', la mia macchina principale e' un ubuntu 64bit quella nel cab provvisoria un 32bit e non volendo installarmi tutto l'ambiente per il cross compiling ho provato a compilare sul cab... bene con 512Mb di ram (+512Mb di swap) non si riesce a compilare mame l'assurdita' e' che gcc 4.6 da questo errore:

Codice: Seleziona tutto

Generating TMS57002 source file...
obj/groovysdl/build/tmsmake src/emu/cpu/tms57002/tmsinstr.lst obj/groovysdl/emu/cpu/tms57002/tms57002.inc
Compiling src/emu/cpu/tms57002/tms57002.c...
{standard input}: Assembler messages:
{standard input}:1594: Warning: end of file not at end of a line; newline inserted
{standard input}: Error: .size expression for _ZL18cpu_reset_tms57002P17legacy_cpu_device does not evaluate to a constant
gcc: internal compiler error: Killed (program cc1plus)
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.6/README.Bugs> for instructions.
make: *** [obj/groovysdl/emu/cpu/tms57002/tms57002.o] Error 4

riprovato con 1Gb di ram, tutto ok

Evidentemente è un problema di quantità di memoria .
Comunque ci vuole un pazzo per compilare mame su un pc con 512MB di ram, sopprattutto perché durante il linking finale dell'eseguibile, il compilatore arriva a mangiare circa 1GB di ram.