Mon Jun 8 09:26:38 +0200 1998 R. Reucher <[EMAIL PROTECTED]> wrote:
> Sorry for my late answer, but i'm using my company's e-mail system (and most
> of the time i'm not working at the weekend :)...
Well, see how long it took for me to follow-up ;)
>
> Ok, why not writing many different UIs for MAME; but we should consider using
> a common 'database' format as Peter Daum suggested, so that anyone can use his
> favorite launcher (see below). BTW: Also MAMECAT is written in C !
Yes...
> > available in one zip file since I have written some routines which reads
> > the directory part of the zipfile and also code that can extract single
> > files from it.
> > This code could be used in many unix mame loaders with different UI:s.
>
> I would be interested in this code !
I'll have to find the code somewhere... It is a bit different that was used
in xmames before John Butler's unzipper code replaced it (now in main mame
tree).
>
> > Another thing is to use a common routine, which launches xmame with
> > -listfull option and parses the available game names, sorts them...
> > then one routine checks what roms are available so that mame is not tried
> > to start if game does not exists etc.
>
> MAMECAT uses 'xmame -listfull' to determine available games and their
> descriptions. What's currentliy missing is to check if the ROM-images are
> available (this will be implemented before i release it the forst time).
So this could the first common code used in our implementations...
> Now back to the 'common database format':
>
> I am currently using the following catalog-format (an ASCII text file); so
> that's my proposal :)
>
> One entry per line (for each game), fields separated with a '�' (may be a
> different separator, of course, but i thought '�' wouldn't be used too often).
> A '#' in the first column means 'comment' and the whole line will be ignored.
>
> <romname>�<rating>�<remarks>
>
> <romname> The name of the (zipped) rom-image, without suffix ('.zip');
> for example: 'galaga'
> <rating> A value >= 0 describing your personal opinion about this game;
> the way you interprete this is up to you.
> <remarks> A freeform text for remarks; i. e. 'DIP for extra life doesn't
> work'
>
> The game description is determined by 'xmame -listfull', so it is not needed
> here (same holds for an optional preview image: its name should be the
> same as the <romname> i think !).
Yes. with it's graphics format extension (like .png). I've been thinking
what should be the supported graphics format, and being thinking between
.xpm (some support in gtk) and .png. With .xpm the pictures would be
compressed in zipfile (and zlib would be needed). If the format is .png,
libpng would be needed (i think, don't know libpng interface and what it
does). In this case the png pictures in zipfile would be saved as STORED
format. i.e. not compressed at all and therefore there would not be need
for code to access zlib (libpng would do that internally).
Now that we should think most general implementation, my proposal is to
use png format. Does anyone know how easy it is to decode png images?
> The <rating> is used to be able to sort the list by your personal favorites
> (also mentioned by Peter Daum) and 'sort out' boring/slow/etc. games...
Either of you described that the rating would be a value >= 0. I think 0
sould be the default (just plain ok ;). and negative values would inform it
is worse than ok, and positive as `exellent'. The program would the scale
this to suitable interval if desired. (like 1 - 5, 4-10, F - A, etc).
>
> Does anyone see any need for enhancements or a totally different format ? If
> so, please answer...
Yes. It looks like xmame-grok uses the following db format:
($name,$rating,$opts,$vgaopts,$xopts,$comment,$style)= ...
That seems to be supreset of your format. If I figured the xmbase-grok
correctly out, the info will be written on the disk as follows:
<gamename>:<rating>:<opts>:<vgaopts>:<xopts>:<comment>:<style>
(so there can't be `:':s in comment string ?
My proposal is to make the information available on the database as a
name - value pairs, like the following:
<gamename>:RATING=3:COMMENT=foobar:...
The order of the name-value pairs can be anything...
This way, all options is not needed to be known by all frontends... and
new options can be easily added. If a frontend will encounter a
option it doesn't know, It will keep it intact and when options are
changed, will save it back as it was.
In addition to this there would be an entry
DEFAULT:RATING=0:...
Which gives defaults to the games that doesn't have entries -- or
doesn't have some options set up. If the frontend knows some options
that is not set in this DEFAULT entry, It will use it's own default.
This is my proposition number 1 :).
>
> Rene
Tomi
---------------------------------------------------------------------------
Send administrative requests to [EMAIL PROTECTED]
