Newsgroup: it.comp.software.emulatori
Titolo: Ancora sul mame e sulla sua lentezza

Negli anni si sono susseguite moltissime ipotesi sul continuo diminuire 
delle prestazioni del mame, ma quella che ogni volta viene tirata in 
ballo da qualcuno ï¿œ che la semplice presenza di piï¿œ driver, per renderlo 
compatibile con piï¿œ giochi, sia sufficiente a farlo rallentare.
Allo stesso tempo, ogni volta che qualcuno avanza quest'ipotesi, ecco 
subito apparire la risposta secondo cui il numero di driver presenti 
nell'eseguibile sarebbe ininfluente, perchï¿œ verrebbe solamente eseguito 
il codice del gioco emulato.
 
Ma fermiamoci un attimo e poniamoci la domanda che ogni razionalista si 
deve porre: "Perchï¿œ credo a quello che credo?"
In questo caso, sono coloro che NEGANO l'ipotesi che il numero di giochi 
emulati infici le prestazioni, a doversela porre. Perchï¿œ costoro credono 
a quello che credono?
Io sono pronto a scommettere che nessuno di essi ha fatto delle prove di 
modifica del codice per confermare o smentire quell'ipotesi, ma si 
limitano a crederci perchï¿œ l'ha detto il mame team. A questo punto, 
voglio mettere in evidenza l'irrazionalitï¿œ di quel comportamento. Ci 
credono perchï¿œ qualcuno gliel'ha detto. Ma ï¿œ come credere che la bibbia 
sia la parola di Geova perchï¿œ c'ï¿œ scritto sulla bibbia stessa! Oppure 
credere che Silvio risolverï¿œ i problemi dell'Italia perchï¿œ l'ha detto 
lui! O come credere che io sia la reincarnazione di Assurbanipal, Giulio 
Cesare e Naruto perchï¿œ lo dico io!
 
A questo punto, riesco a immaginare l'obiezione di chi crede ancora che 
non esista alcun rapporto tra prestazioni del mame e numero di giochi 
emulati. Una variante di frasi come "ï¿œ ragionevole" o "ha intuitivamente 
senso". Un'obiezioni dal valore pari a zero: in qualsiasi campo esistono 
esempi di eventi che si verificano pur non essendo intuitivamente 
sensati, perchï¿œ l'intuito umano ï¿œ imperfetto. Gli esempi possono 
spaziare dalla dilatazione del tempo e dello spazio a velocitï¿œ prossime 
a quella della luce, alla dualitï¿œ tra onde e particelle, alla 
non-separabilitï¿œ quantistica, al comportamento di un masochista. 
Duemilatrecento anni fa, secondo Aristotele "era ragionevole" supporre 
che un corpo cadesse tanto piï¿œ rapidamente quanto maggiore era il suo 
peso, ma la "ragionevolezza" di quell'ipotesi non ci dice nulla sulla 
sua correlazione con la realtï¿œ. E come se non bastasse, per secoli 
nessuno aveva fatto esperimenti per provarla o smentirla, ma ci si 
credeva semplicemente perchï¿œ l'aveva detto lui (ipse dixit), e si torna 
al discorso di prima.
 
E a questo punto cosa mi direste, se vi dicessi che ho fatto un test 
sperimentale e ripetibile, da cui risulta che la semplice presenza di 
piï¿œ codice eseguibile in un programma lo rallenta, anche se questo
codice non viene eseguito? Potreste dirmi che non mi credete, al che io 
risponderei che non mi aspetto che mi crediate, mi aspetto che ripetiate 
l'esperimento e ve ne rendiate conto da soli! O avete paura di quello 
che voi stessi osserverete?
Nello specifico, stavo lavorando su Hi65. Cercavo un modo di fargli 
interpretare espressioni matematiche complesse, quando ho trovato 
MuParser, un valutatore di espressioni matematiche, scritto in C++ e 
open source. Allora ho scaricato il codice sorgente da 
http://sourceforge.net/projects/muparser/
 e l'ho inserito nel progetto 
di Hi65 secondo le istruzioni a 
http://muparser.beltoforion.de/mup_usage.html#idInstInc
 (il paragrafo ï¿œ 
"Including the source code directly"). Oltre ai files elencati lï¿œ, nella 
directory del progetto ho messo anche il file muParserTemplateMagic.h, 
per non avere errori in fase di compilazione.
Poi ho aggiunto due sole linee all'inizio della funzione di Hi65 
chiamata evaluateexpression, che si trova in arrayops.cpp:
 
using namespace mu;
   Parser p;
 
Ossia ho aggiunto un oggetto parser, senza perï¿œ farlo utilizzare da 
ALCUNA funzione nel programma. Ho ricompilato, ho lanciato Hi65 e gli ho 
fatto eseguire il programma gfxdemo1 (che si trova a 
http://devilmaster.altervista.org/gfxdemo1.zip
 ). Risultato: mentre 
prima l'immagine veniva tracciata in 0,116667 secondi (valore ottenuto 
dividendo /60 la differenza tra i valori della variabile TI dopo e prima 
dei cicli FOR che tracciano l'immagine), la semplice PRESENZA di un 
oggetto parser NON UTILIZZATO ha portato il tempo a 55,983333 secondi!
QUATTROCENTOOTTANTA VOLTE PIU' LENTO!!!
 
A questo punto, le domande sorgono spontanee: quanti oggetti 
inutilizzati ci sono nel codice del mame? Non necessariamente MAI 
utilizzati, ma presenti anche quando viene emulato un gioco che non li 
utilizza? E di quanto aumenterebbero le prestazioni, scegliendo un solo 
gioco dal codice del mame e togliendo TUTTO quello che non lo riguarda 
(ossia tutti gli oggetti relativi alle migliaia di altri giochi che non 
interessano)?
Il codice del mame ï¿œ notoriamente un ginepraio, ma qualche anno fa il 
dott. Piergiorgio ci ha messo le mani dentro e l'ha esaminato con piï¿œ 
pazienza di quanta ne avrei avuta io, quindi gli chiedo, per favore, di 
fare questa prova. Grazie.

 ALCUNA funzione nel programma.
 
E' qui l'errore.... una funzione c'ï¿œ... cosa fa il costruttore di
suddetto oggetto?
 
da muParser.cpp:
   ...
//---------------------------------------------------------------------------
  /** \brief Constructor.
 
    Call ParserBase class constructor and trigger Function, Operator and
Constant initialization.
  */
  Parser::Parser()
    :ParserBase()
  {
    AddValIdent(IsVal);
 
    InitCharSets();
    InitFun();
    InitConst();
    InitOprt();
  }
...
 
in realtï¿œ ogni volta che tu esegui la tua funzione per il solo fatto che
hai istanziato quell'oggetto tu esegui anche tutto sto mandrone di roba...
OOP gioie e dolori... Soprattutto dolori... ;-)
 
Ciao
A.

 hai istanziato quell'oggetto tu esegui anche tutto sto mandrone di roba...
 
Okay, applichiamo il metodo scientifico.
 
IPOTESI DA VERIFICARE:
i rallentamenti sarebbero causati dalle ripetute inizializzazioni 
dell'oggetto, che avvengono ogni volta che si esegue la funzione
 
CONSEGUENZE DELL'IPOTESI:
se l'ipotesi risulta vera, i rallentamenti spariranno portando l'oggetto 
fuori dalla funzione
 
SVOLGIMENTO DELLA PROVA:
sono stati fatti questi cambiamenti:
- l'inclusione di muParser.h ï¿œ stata spostata da arrayops.cpp a var.h
- ï¿œ stata cancellata la linea "using namespace mu;" dalla funzione 
evaluateexpression
- l'oggetto parser ï¿œ stato spostato dalla funzione evaluateexpression 
alla fine di var.h, con la linea modificata in "umode mu::Parser p;"
 
Ricompilando ed eseguendo il codice... effettivamente i rallentamenti 
non si verificano piï¿œ, e gfxdemo.prg viene di nuovo eseguito in 0,116667 
secondi.
Bene, resta da implementare una evaluateexpression alternativa che fa 
uso di MuParser e vedere come si comporta il programma in quel caso.
 
La richiesta al dott. Piergiorgio perï¿œ rimane valida: non posso 
escludere che qualcuno nel mame team abbia fatto lo stesso errore che ho 
fatto io, ma nessuno se ne sia mai lamentato perchï¿œ tutti danno i 
rallentamenti per scontati e "basta cambiare computer una volta 
all'anno" per non notarli.

 all'anno" per non notarli.
 
guarda che il mio infilarmi nel ginepraio ï¿œ per capire l' 
implementazione software dell' hardware passato, e difatti la mia 
lamentela principale era (ed ï¿œ) che lo scopo dichiarato ("documentare il 
funzionamento dell' hardware") non era consistente (eufemismo) coll' 
applicazione reale del software; un ipocrisia forse comprensibile all' 
epoca, ma non oggi; ed in effetti, pur essendo migliorata, anche 
sostanzialmente, la leggibilitï¿œ e modularitï¿œ del codice, non ï¿œ che mi 
sia messo a fare profiling dei tempi d' esecuzione e localizzare dove 
rallenta di piu; bensï¿œ ho avuto la pazienza di comprendere, ad. es. dove 
sta la parte del driver che si occupa della gestione di un particolare 
registro video o di un gruppo di opcode del processore.
 
esempio commodoriano banalissimo, non ï¿œ che sia cosï¿œ immediato che 
quando mem[$d020/d021] cambia, deve cambiare il colore di bordo o di 
sfondo; e nel caso del MAME, un singolo driver audio o video deve tenere 
traccia dell' hardware disparato emulato intorno al chip (a prescindere 
dalle implementazioni in logica discreta, che non sono solo audio)
 
Molti chip grafici degli anni '80 furono adottati da diversi produttori, 
ciascuno colla sua idea sul modo migliore di interfacciare, (e 
aggiungiamoci pure le varianti dei vari bootlegs) e non ï¿œ detto che l' 
interfaccia sia implementata in un solo sorgente tra drivers/ machines/ 
and video/
 
Inoltre, il mio settore di homebrewing non ï¿œ che sia precisamente 
arcade, anche se occasionalmente giocherello col concetto di 
implementare un RPG su un architettura arcade (il cui comparto video 8 e 
16 bit ï¿œ ottimizzato per la grafica a tiles; da cui il mio ravanare nei 
meandri oscuri del MAME...) da questo punto di vista, le cose stanno 
gradualmente migliorando, ma non so a quale prezzo dal pdv del tempo di 
esecuzione.
 
quindi, scusami se ti deludo; conosco sï¿œ abbastanza bene il MAME, ma il 
mio interesse ï¿œ definitivamente piï¿œ per il down/bottom che il top/up 
quindi non ï¿œ che mi sia messo a compilare il MAME con i simboli di 
debugging e dare in pasto l' eseguibile a un profiler; mi limito a 
scavare nei sorgenti fino a che non comprendo come, prendendo l' esempio 
precedente, come il MAME emula il VIC-II o un suo specifico registro. e 
personalmente, reputo piï¿œ unico che raro che un centinaio o due di 
coders e hackers sia riuscito a mettere insieme in software, nel corso 
negli ultimi 10-15 anni in maniera piï¿œ o meno consistente e funzionante 
il lavoro realizzato in hardware da migliaia di ingegneri elettronici 
nel corso degli ultimi 40 anni.....
 
Saluti,
dott. Piergiorgio.

compatibile con pi� giochi, sia sufficiente a farlo rallentare.
[...]
 
Che confusione!
 
Ne abbiamo gi� parlato nel 2007 (se vuoi puoi andare a ripescare il
thread di quell'anno), facendo riferimento ad un articolo di Aaron
Giles che spiega, in termini abbastanza semplici, di quanto sia
peggiorato il MAME nelle varie release e *da cosa* sia causato il
peggioramento:
 
http://aarongiles.com/?p=208
 
 
In sostanza, il peggioramento delle performance *non �* causato di per
se' dalla presenza "di pi� driver". I motivi del peggioramento sono:
 
1) che � cambiata negli anni la gestione del video (da 8 bit a 32 bit
di default)
2) che i driver diventano pi� "generici" (ovvero, con lo stesso driver
vengono emulati pi� giochi leggermente diversi)
3) che i driver diventano pi� accurati (e quindi pi� complessi)
 
Mo' basta con 'sta storia del MAME per almeno altri 7 anni :)
 
friol

 friol
 
Pur di non aggiornare il suo p3 800Mhz dimostrerebbe che il sole ruota 
attorno alla terra

 attorno alla terra
 
Ma infatti quello non lo aggiorno: uso direttamente altri PC ben pi� 
potenti, invece. Quello lo lascio in un armadio e lo tiro fuori solo per 
valutare il decadimento di prestazioni di certi programmi.

 peggioramento:
 
Me lo ricordo, quell'articolo. In sostanza, ipse dixit.
Ma se basta dichiarare un oggetto all'interno di una funzione anzich� 
nello spazio globale per veder diminuire le prestazioni di 480 volte 
(perch� l'oggetto in questione si reinizializza ogni volta che viene 
chiamata quella funzione), � probabile che una cosa del genere sia 
successa pi� volte nella storia del mame, e nessuno se ne sia accorto 
perch� nessuno si � preoccupato di fare test su macchine su cui UNA 
VOLTA il mame girava bene e ora non pi�, perch� "tanto i rallentamenti 
sono normali" e perch� "tanto la gente gli tira dietro un ferro all'anno".

 sono normali" e perch� "tanto la gente gli tira dietro un ferro all'anno".
 
 
Una domanda seria, visto che qualcosina di programmazione la sai: hai 
mai provato a contribuire? sarebbe il metodo migliore per dimostrare la 
tua tesi.

 mai provato a contribuire?
 
No, perch� i miei contributi andrebbero contro la religione del mame 
(accuratezza a tutti i costi anche a scapito delle prestazioni, 
emulazione a livello pi� basso possibile) e quindi non verrebbero MAI 
accettati.
Per darti un'idea: l'anno scorso, nel forum del MESS, qualcuno ha 
nominato Hi65, e quando in quel topic sono intervenuto io, uno 
sviluppatore mi si � subito scagliato contro, mandandomi letteralmente 
affanculo perch� ho commesso l'"eresia" di creare un emulatore basato 
completamente sull'HLE invece di seguire la dottrina del mame team. C'� 
da dire che me l'aspettavo, perch� mi ricordavo la sterile polemica 
contro Olivier Galibert quando aveva osato utilizzare l'HLE per emulare 
Virtua Racing, e per questo avevo gi� deciso di rilasciare Hi65 sotto 
GPL, che � incompatibile con la licenza del mame.

sono normali" e perch� "tanto la gente gli tira dietro un ferro all'anno".
 
Cio� secondo te il mame � peggiorato di 480 volte in una versione
sola, perch� un programmatore "sbadato" ha messo la dichiarazione di
un oggetto "mostruoso" nell'inner loop non di uno, ma di tutti i
driver? E poi chiaramente non si � accorto che il framerate � sceso da
mettiamo 60 a 60/480=0,125 fps...
 
Fammi sapere in che versione � successo che lo segnalo subito al mame
team!
 
friol

 team!
 
A parte che i rallentamenti non seguono lo stesso pattern in tutti i 
giochi tranne nel caso di modifiche globali (come quando sono state 
inserite le Direct3D di default) ci sono almeno quattro precedenti di 
lentezza mostruosa dovuta a incompetenza, tre dei quali sono stati 
corretti, ma uno invece no.
1) Mortal Kombat, nelle prime versioni in cui era emulato andava 
lentissimo perch� qualcuno nel mame team era convinto che la macchina 
originale avesse una CPU a 200 MHz anzich� a 20.
2) Cruis'n USA andava lentissimo finch� uno degli sviluppatori si � 
accorto che si era scordato di togliere del codice di debug.
3) Dalla versione 0.87 alla versione 0.102, il caricamento di qualsiasi 
gioco freezava l'emulatore per 20 secondi, mentre nelle versioni 
precedenti e successive era istantaneo.
4) Questo � il pi� eclatante. Sul famoso Pentium III a 800 MHz, fino 
alla versione 0.60, Tempest volava alla velocit� di 294 fps. Dalla 
versione successiva invece � precipitato a 65 fps, poi a 48, 46, 41... e 
non si � pi� ripreso. Se ti ricordi, l'avevo nominato nel 2011 nel topic 
della mia analisi delle prestazioni del mame, in cui avevo anche 
mostrato un grafico: 
http://devilmaster.altervista.org/mamelento.pdf
 
(s�, lo so che non mostra dati sulla versioni 0.61, ma l'ho testata in 
seguito, e se fai tu stesso la prova, ti accorgi che il crollo delle 
prestazioni � stato in quella)

non si � pi� ripreso.
 
Con la versione attuale di MAME, sul mio PC Tempest va a 60fps fissi,
e se tolgo il limitatore va a qualcosa come 400fps. 
 
Chiaramente dimmi se devo recuperare un Pentium 3 dalla soffitta per
provarlo anche li' :)
 
friol

 provarlo anche li' :)
 
Il decadimento prestazionale si verifica su qualsiasi computer, anche se 
ovviamente i valori saranno diversi a seconda della potenza del 
processore. Confronta pure sul tuo computer: Tempest con la versione 
attuale, e Tempest con la versione 0.60.

 chiamata quella funzione)
 
Ma perch� non far girare il MAME sotto un profiler, tipo valgrind 
--tool=Cachegrind, per vedere dove effettivamente sono i colli di 
bottiglia, invece di fare ipotesi senza portare prove a loro sostegno?
 

E il frameskip l'hai settato a 0 (NON auto)?
 
Ho provato in tutti i modi, anche lanciando in parallelo la
masterizzazione di un CD e aprendo il sito di sovox sui numeri di
Special Program...
 
Ma siamo seri!!!
Tempest girava su un 6502 ad 1Mhz!!!!!
Mi spieghi come potrebbe andare lento su un i5?
 
friol

bottiglia, invece di fare ipotesi senza portare prove a loro sostegno?
 
Guarda, ho fatto girare la versione 0.01 del mame su un 8088 a casa di
mio cugino nel 1982 e ti giuro che andava lento!!!
 
friol

 Special Program...
 
E allora hai sbagliato. Non dovevi lanciare alcun altro programma in 
parallelo, dovevi solo lanciare Tempest, con throttle disattivato e 
frameskip a zero, prima con la versione 0.153, poi con la versione 0.60, 
e infine dovevi fare la cosa pi� importante, che non hai fatto: 
comunicare quanti frame al secondo fa nell'uno e nell'altro caso.

 mio cugino nel 1982 e ti giuro che andava lento!!!
 
<tot�>Ma mi faccia il piacere!</tot�>
 
E Tempest sul tuo i5 attuale con la versione 0.60 del mame, con throttle 
disattivato e frameskip 0, l'hai provato? Perch� sono pronto a 
scommettere che superer� i 2000 fps. In contrapposizione ai 400 che 
raggiunge con la versione 0.153.
Adesso, ricordandoti che su un PIII a 800 MHz, Tempest sul mame 0.60 
raggiunge i 294 fps, ti pare logico e accettabile che con l'ultima 
versione, su un i5, vada solo 1.3 volte pi� veloce?

 versione, su un i5, vada solo 1.3 volte pi� veloce?
 
Ciao a tutti,
 
ho fatto alcuni test per verificare il peggioramento delle prestazioni 
tra il mame 0.153 e la versione 0.60. Ho fatto le prove con i seguenti 
giochi: "Tempest" e "Bomb Jack (set 1)". I test sono stati effettuati 
con un pc con CPU Core i5 2500K overcloccato a 4.5 GHz, 8 GB di RAM e 
Windows 8.1 Update 1. Ecco i risultati:
 
MAME 0.60 e Bomb Jack: 2601.738187 FPS
MAME 0.60 e Tempest: 1121.763027 FPS
MAME 0.153 e Bomb Jack: 3624.65%
MAME 0.153 e Tempest: 354.16%
 
Per il MAME 0.153 ho usato il seguente comando per lanciare i giochi: 
"mame <GIOCO> -fs 0 -nothrottle -noautoframeskip -seconds_to_run 30".
Per il MAME 0.60 ho usato il seguente comando per lanciare i giochi: 
"mame <GIOCO> -fs 0 -nothrottle -noautoframeskip".
Nella vecchia versione del MAME l'opzione "-seconds_to_run" non 
esisteva, quindi non ho potuto utilizzarla. Inoltre, prima veniva 
indicato il numero di FPS che si riusciva a raggiungere, ora le nuove 
versioni indicano la percentuale rispetto all'esecuzione del gioco a 
velocit� normale. Quindi, ho fatto un test provando i giochi con il 
throttle abilitato e ho appurato che 60 FPS corrispondono al 100% della 
velocit�.
Con un semplice calcolo si pu� stabilire che i 2601.738187 FPS di Bomb 
Jack corrispondono ad una velocit� di 4336.23%, mentre i 1121.763027 FPS 
di Tempest corrispondono ad una velocit� di 1869.60%.
 
In conclusione, si pu� affermare che per quanto riguarda Bomb Jack, la 
versione 0.60 � leggermente pi� veloce della 0.153, con una differenza 
del +19%. Per quanto riguarda Tempest, la differenza � enorme, essendoci 
una differenza del +427%, ovvero pi� di 5 volte la velocit� raggiunta 
dalla versione 0.153. Quindi Devil Master ha ragione dicendo che con 
Tempest le prestazioni del MAME sono crollate. Il MAME Team dovrebbe 
rivedere l'emulazione di questo gioco, visto che non � accettabile che 
una CPU come la mia faccia girare un gioco del 1980 appena poco oltre il 
triplo del dovuto!
 
Scorpion77

 sia accorto perchè nessuno si è preoccupato di fare test [cut]
 
Rincaro la dose.
Dato che si tratta di un emulatore «non gradito», la cui
capacità di far giocare la gente è soltanto un «effetto
secondario» (per pararsi il chiurlo), domando, senza saper
né leggere (i vecchi post) né scrivere (codice):
 
non può essere un rallentamento voluto?
 
Voluto come i VG di ultima generazione, le cui versioni per
PC vengono appositamente rallentate per non superare quelle
su console (e quindi non far sfigurare quest'ultime).
Non ho mai lavorato in nessun SW Team, ma non credo che nel
MAME Team vinca la pigrizia (e la sordità/cecità) piuttosto
che il «compromesso vitale».
 
Cmq Grazie Devil Master.
 
 
-- 
++stralix++

 Scorpion77
 
Nice job!
Ci voleva :)
 
 
--
++stralix++

 Cmq Grazie Devil Master.
 
Di niente.
 

> Cmq Grazie Devil Master.
 
Secondo me la soluzione e' piu' semplice: se ti guardi le vecchie FAQ
c'e' scritto chiaramente quancosa tipo "la velocita' arrivera'
semplicemente perche' saranno disponibili computer piu' veloci".
 
Ergo non c'e' bisogno di ottimizzare il codice, tanto girera' piu'
veloce l'anno prossimo. E se il codice lo smerdi, pazienza, prima o
poi usciranno computer piu' veloci.
 
Sono finiti i tempi dell'ottimizzazione degli algoritmi.
-- 
Living in Barbaropoli
http://www.barbaropoli.com
 

 
https://groups.google.com/forum/#!msg/it.comp.software.emulatori/mzGuainstog/8wZEkwXlIhcJ
 
 
Ennesima Gioia & Delusione: il trionfo della logica & la
constatazione che gli idioti-per-scelta peggiorano
esponenzialmente.
 
 
-- 
++stralix++

triplo del dovuto!
 
Ti dir�, secondo me invece � "accettabile" anche il 300%.
La soglia dell'accettabilit� secondo me sono i 60fps, perch� non credo
che qualcuno giochi a Tempest (che gi� � veloce di suo) a 180fps.
 
Il tuo computer, molto simile al mio, avr� i suoi 4-5 anni
(confermi?). Che un gioco vada a 60fps su un computer di 4-5 anni per
me � pi� che accettabile. Se poi proprio lo trovi "inaccettabile",
puoi sempre usare la versione precedente di MAME, che lo fa andare a
400fps, ma sinceramente non ne vedo l'utilit�.
 
friol

su console (e quindi non far sfigurare quest'ultime).
 
No (vedi il mio post precedente).
 
I sorgenti del MAME sono a disposizione di tutti, a differenza dei
videogiochi closed source, quindi chiunque si accorgerebbe del fatto
che un mamedev ha messo una "sleep()" volutamente nel codice.
 
friol


https://groups.google.com/forum/#!msg/it.comp.software.emulatori/mzGuainstog/8wZEkwXlIhcJ
 
 
S� s�, � sicuramente un complotto.
 
friol

 friol
 
rotfl
 
io avrei aggiunto un "pat pat"
 

 400fps, ma sinceramente non ne vedo l'utilit�.
 
 
chiss� cosa ne � delle restanti CENTINAIA di giochi che vengono 
costantemente migliorati nel tempo invece, di quelli non se ne parla mai
 
 
 

 costantemente migliorati nel tempo invece, di quelli non se ne parla mai
 
Nessuno parla mai nemmeno di unicorni rosa invisibili e gnomi che 
dipingono gli arcobaleni, chiss� come mai.
 

 friol
 
A parte il fatto che "accorgersi" non implica automaticamente
"correggere" (o "volere correggere"), magari una "sleep()" non
è proprio il metodo migliore per «implementare» una negazione
plausibile, IMO.
 
 
-- 
++stralix++
 

 dall'SVN e ricompilandolo).
 
Concludendo, il MAME Team vi ha trollato per bene, come si confà al
popolino che deve continuare a pagare, dandovi una goccia di contentino
per volta. Evviva!
 
 
-- 
++stralix++ 

plausibile, IMO.
 
in effetti pu� darsi che ci sia un accordo segreto tra i mamedev ed i
produttori di PC per rendere impercettibilmente pi� lento il MAME ad
ogni release....... costringendo cos� noi poveri utenti a comprare PC
sempre pi� veloci, ed arricchendo le varie DELL, Lenovo, ecc.
 
chiaramente i dev che hanno corretto il degrado di Tempest e quelli
che hanno introdotto il multithreaded rendering sono stati cacciati
all'istante!
 
friol

 dipingono gli arcobaleni, chiss� come mai.
 
http://www.youtube.com/watch?v=9UPxSj7RlO0
 
 
non ti ringrazier� mai abbastanza, ancora ci rido

 friol
 
http://www.youtube.com/watch?v=oaacQ6glfAU&list=UU3IDIT0oZQ5zUamCiLRLYsw
 
 
AHAHAHAHAHAAHAHAHAHAAHAAHAHAHAHAHAAHAHAHAHAHAHAHAAHAHAHAHAHAHAHAAHAHAHAHAHAA
AHAHAHAHAHAAHAHAHAHAAHAAHAHAHAHAHAAHAHAHAHAHAHAHAAHAHAHAHAHAHAHAAHAHAHAHAHAA
AHAHAHAHAHAAHAHAHAHAAHAAHAHAHAHAHAAHAHAHAHAHAHAHAAHAHAHAHAHAHAHAAHAHAHAHAHAA
 
hai capito si?

 all'istante!
 
Non vengono cacciati, semmai ricevono un bonus cash per la disponibilità
operativa nella missione segreta :) Sciocchino :D
 
 
-- 
++stralix++

 M'importa che quelli come te stanno portando tutto al ribasso.
 
ROTFL
 
un progetto di queste dimensioni portato avanti da contributi di 
volenterosi senza alcun lucro, è già un miracolo che ancora esista
 
ma no dai, impuntiamoci sul fatto che Tempest va solo al 300% anziché al 
600%
 

 anziché al 600%
 
Semmai, m'impunto sul fatto che vi abituate a lasciar perdere,
e trasmettete a chiunque il medesimo fatalismo.
 
Sicuramente, m'impunto sul fatto che ancòra credete di essere
liberi di fare/scegliere ciò che il mondo «civilizzato» e
«democratico» vi offre.
 
Rotolatevi quanto vi pare, ma se prima non pulite il pavimento
le cose non miglioreranno mai.
 
Long Live the MAME.
Goodbye.
 
 
-- 
++stralix++ 
 


 
Ciao friolzo, effettivamente a me non cambia la vita se Tempest gira al 
300% piuttosto che al 600%. In effetti basta avere 60 fps stabili (100%) 
per giocare alla grande. Volevo solo rimarcare il fatto, inequivocabile, 
che la velocit� di esecuzione di Tempest � scesa vertiginosamente. 
Probabilmente se dovessi giocare a Tempest con il MAME 0.153 su 
un'onesto pc di fascia media con CPU Celeron G1820 (che puoi trovare in 
pc recenti da supermercato, comunque un dual core), potresti non 
riuscire ad avere 60 fps, contando che il Celeron G1820 ha un punteggio 
PassMark - CPU Mark di 2729, mentre il Core i5 2500K raggiunge i 6495, 
ma non overcloccato. Il mio dovrebbe arrivare circa a 8856. Se dividi 
per tre questo punteggio, ottieni 2952: questo � il punteggio Passmark 
per fare andare a 60 fps Tempest. Come vedi, anche con un pc moderno 
potresti non usufruire di un'emulazione corretta. Non voglio giudicare 
il MAME Team per questo, anzi gli sono grato perch� posso giocare a 
migliaia di giochi gratis, per� ognuno pu� trarre le proprie conclusioni.
 
Scorpion77

 non ti ringrazier� mai abbastanza, ancora ci rido
 
Grazie, alla fine vedo che mi hai dato ragione.

 le cose non miglioreranno mai.
 
A seguito di quanto t'ho illustrato sopra, dovrei anche lamentarmi di 
qualcosa? lol
 

 hai capito si?
 
Ti ringrazio per fare pubblicit� ai miei video. Gi� che ci sei, 
pubblicizza anche l'ultimo che ho messo, cio� questo 
https://www.youtube.com/watch?v=dDvPoWGzX-Q
 che sicuramente risulter� 
molto gradito ai fans di Arthur C. Clarke.
 
E ADESSO TUTTI CON IL DITO MEDIO ALZATO CONTRO IL MAME!