Author Topic: XMAME v1.0 release  (Read 106207 times)

slaanesh (OP)

  • *
  • Posts: 476
    • Slaanesh Dev
Re: XMAME v1.0 release
« Reply #40 on: January 01, 2015, 12:16:23 am »
Well I thought it would be better to be installed. My reasons were:

* Have the entire application and it's data files in the one spot. Personally I find it annoying having files distributed around the filesystem for applications.
* Easily share resources between versions of MAME. ie. roms/ and snap/ directories are prime candidates as well as the history, hiscore and optional cheat dat database files.
* No need to "launch" an OPK to have the application available. Whilst this isn't much benefit for most users, as a developer having the application ready to go without launching the OPK is very useful. And I reasoned that it there would be not much difference to the end user between using an OPK or running the executables.
* Configuration of file paths to XMAME directories. Having everything in the one spot means this was easily done through the XMAMEROOT environment variable.

I nice conceptual model for the XMAME setup is that the directory containing the main executable has all it's relevant resources underneath.

-XMAME69
  |---MAME.SDL.69
  |---history.dat    <-shared
  |---hiscore.dat    <-shared
  |---cheat.dat      <-shared
  |---roms/          <-could be shared
  |---snap/          <-could be shared
  |---cfg/
  |---frontend/
  |---memcard/



Wait a minute here. Why do you have to create an installer? Can you not run the MAME executable(s) from the OPK itself, and let the user put it where he/she wants (/media/something/apps)?

+1

I appreciate your hard work slaanesh but I avoided this software because I felt uneasy about "installing" something in this way. I'd much prefer this project to follow GCW's standard OPK distribution practice. It is easier for me as a user to manage the apps plus you get the benefit of squashfs compression. You would probably also avoid the filesystem problems and having to assume an incorrect path for sd cards.

Well you already can put it where you want - to a degree - if you have EXT2 FS on your SD card.
But I will fix this today so that it can be installed to either internal or external storage for any filesystem, FAT32 or EXT2 or whatever.

If enough people want to run it from OPK only then I can change it but i really don't see any advantage in this over the current system. Please convince me otherwise :)

One question:
Why is the SD card mounted to /media/<LABEL>? Why is there no alternative, static mount point to the SD card? Having it mounted to the SD card's label name isn't a good idea IMHO. The SD card should be mounted to the same point regardless of it's name/label.
« Last Edit: January 01, 2015, 12:45:03 am by slaanesh »

AtariHERO

  • *
  • Posts: 351
Re: XMAME v1.0 release
« Reply #41 on: January 01, 2015, 12:30:57 am »
any special neogeo.zip file needed ?
, the one i had does not work anymore  ???
« Last Edit: January 01, 2015, 12:32:39 am by AtariHERO »

Elaphe

  • *
  • Posts: 136
Re: XMAME v1.0 release
« Reply #42 on: January 01, 2015, 12:34:15 am »
Well, then let's see how it compares to upcoming version of MAME4All, which is supposed to be released very soon and support roms up to 0.74.

codingcampbell

  • *
  • Posts: 25
Re: XMAME v1.0 release
« Reply #43 on: January 01, 2015, 12:58:49 am »
Well I don't want to derail an otherwise enthusiastic thread but I'll share my point of view:

Well I thought it would be better to be installed. My reasons were:

* Have the entire application and it's data files in the one spot. Personally I find it annoying having files distributed around the filesystem for applications.

I disagree with this premise. Most (all?) of the GCW software ships its read-only storage as the OPK, stores userdata in a ~/.dotfolder/ and, in the case of emulators, you can load ROMs from wherever (I choose to store these in my home folder).

I think consistency is important and, while I don't fully understand the multi-version problem you're solving, I don't see why this emulator needs to deviate from the rest.

* Easily share resources between versions of MAME. ie. roms/ and snap/ directories are prime candidates as well as the history, hiscore and optional cheat dat database files.

I'll defer to you on this one, I'm not very aware of the multi-version setup. However, in other emulators, after I select a ROM the first time, it defaults to showing me the parent directory of that ROM the next time I need to select one.

* No need to "launch" an OPK to have the application available.

But OPK is a one-file distribution format and you get squashfs compression .. why not use it?

* Configuration of file paths to XMAME directories. Having everything in the one spot means this was easily done through the XMAMEROOT environment variable.

I don't have knowledge/opinion on this one.

Anyway, just my 0.2c. I think above all else you should be consistent with the platform you distribute to, unless there is a significant technical reason to deviate. And in your case you wouldn't have to worry about details like sd-card format etc. But again I don't want to derail this thread further. Congrats on shipping and thanks for giving to the community :)

One question:
Why is the SD card mounted to /media/<LABEL>?

+1 - /media/sdcard static mount would be great, like Android does.

slaanesh (OP)

  • *
  • Posts: 476
    • Slaanesh Dev
Re: XMAME v1.0 release
« Reply #44 on: January 01, 2015, 01:32:13 am »
Thanks for your feedback.

I have a confession to make - I'm not *that* interested in the installation/OPK side of the software; my interest is in porting and then optimizing the actual emulator and getting the games running as smoothly and as excellently as possible. I like solving problems when particular games don't work. I like making new games work. I like making things go faster.

However I do want to make it all work :)

The installation part of the project doesn't motivate me very highly. For this reason I tried solving the issue of the relatively complex file structure and various paths in easiest way possible from my point of view - which does deviate with the standard way other people have packaged their OPKs.

As for offering the user the exact ROMs directory location, this approach isn't really sufficient in this case - if you want to offer the user flexibility then it should be able to define exactly where everything goes.

For XMAME the following directories are used in each of the three versions of XMAME I've offered:

roms
snap
cfg
nvram
samples
memcard
inp
hi
sta
artwork
frontend
history.dat
hiscore.dat
cheat.dat

That's a lot to take care of and choose where everything goes, as that is multiplied by three.

Some of these contain content supplied by the user: roms, snap, samples, artwork
Some of these contain files which will be generated by XMAME: snap, cfg nvram, memcard, inp, hi, sta, frontend
Some may be a bit of both.
Some of these directories could be shared amonst versions of MAME: roms, snap
Whilst the remaining must be specific to the version of XMAME using it.

So how much user control do you offer?

Well be default, XMAME actually does offer full control - if you want. I haven't changed the way XMAME works - the user could in theory change where everything is.

However, and this is the big but, on a handheld console, lacking a keyboard, configuration of all these paths and files is difficult and tedious.

So, for simplicity, I decided on limiting the installation choice to either "internal" or "external" and XMAME taking care of the exact locations of all these paths/files I listed above. Whilst not consistent with the regular GCW approach, I felt that in this case this was an OK solution. After all, does it really matter exactly where the user content is placed on the storage? Do most users really care? I wouldn't think so in most cases, but there are of course always people who do.
That's why I created the XMAMEROOT environment variable concept so adopting the read-only OPK approach is feasible with not too much having to change.

I'll fix the current installer to work with FAT32 but after that for the next release I'll have to think about how things perhaps could be changed or if just kept as-is.



« Last Edit: January 01, 2015, 02:00:55 am by slaanesh »

AtariHERO

  • *
  • Posts: 351
Re: XMAME v1.0 release
« Reply #45 on: January 01, 2015, 02:17:35 am »
I for once.can't get the neogeo games to run.
Thay used to work with mame4all

slaanesh (OP)

  • *
  • Posts: 476
    • Slaanesh Dev
Re: XMAME v1.0 release
« Reply #46 on: January 01, 2015, 03:47:07 am »
For XMAME 84 and 69 neogeo.zip file needs to be updated.

Make sure it contains:

neogeo.zip
 Length   Method    Size  Cmpr    Date    Time   CRC-32   Name
--------  ------  ------- ---- ---------- ----- --------  ----
   65536  Defl:N     1398  98% 12-24-1996 23:32 e09e253c  000-lo.lo
  131072  Defl:N    27230  79% 12-24-1996 23:32 91b64be3  asia-s3.rom
  131072  Defl:N    15380  88% 12-24-1996 23:32 354029fc  sfix.sfx
  131072  Defl:N    11245  91% 12-24-1996 23:32 97cf998b  sm1.sm1
  131072  Defl:N    27498  79% 12-24-1996 23:32 2723a5b5  sp-e.sp1
  131072  Defl:N    28132  79% 12-24-1996 23:32 acede59c  sp-j2.rom
  131072  Defl:N    26856  80% 12-24-1996 23:32 c7f2fa45  sp-s.sp1
  131072  Defl:N    27395  79% 12-24-1996 23:32 9036d879  sp-s2.sp1
  131072  Defl:N    27338  79% 12-24-1996 23:32 e72943de  usa_2slt.bin
  131072  Defl:N    45133  66% 12-24-1996 23:32 f0e8f27d  vs-bios.rom
--------          -------  ---                            -------
 1245184           237605  81%                            10 files


The KOF series of games work for sure as well as many others that have been tested... ie. kof2000, kof98

If you have problems, please let me know what settings you used and what version of XMAME. ie xmame.SDL.69, etc.

Senor Quack

  • *
  • Posts: 214
Re: XMAME v1.0 release
« Reply #47 on: January 01, 2015, 04:34:43 am »
Thanks for this updated version, Slaanesh!  I was able to use Clrmamepro on a v154 MAME romset to generate a .37b16 and a .84 set of ROMs and it runs well.  I'm just running into troubles saving states. It will say "Select position to save to" and essentially freeze. So, for now, I'm not doing anything with save states.  Also, I had to map Player 1 buttons 5 & 6 manually, as they do not seem to come mapped, or at least not properly. I made START be the emulator's pause button and mapped buttons 5 & 6 to the triggers.

Since I have a FAT32-formatted SD, I took the option of installing XMAME to internal memory. I chose to place my MAME roms onto the external SD. I then telnet'ed in (one could also use ssh) and issued the following commands to make softlinks to the SD's ROM folders:
Code: [Select]
cd /media/data/local/share/xmame/xmame84
rm -rf roms
ln -s /media/sdcard/ROMS/MAME/84_conversion/ roms
cd /media/data/local/share/xmame/xmame69
rm -rf roms
ln -s /media/sdcard/ROMS/MAME/37b16_conversion/ roms
cd /media/data/local/share/xmame/xmame52
rm -rf roms
ln -s /media/sdcard/ROMS/MAME/37b16_conversion/ roms

Note above that I didn't bother making a .69 conversion set, as .84 and .37b16 is enough for me, and just made the .69 roms folder a symlink to the same set I'm using for .52.  I placed my converted romsets in folders 84_conversion and 37b16_conversion.. you guys can choose different names and places on the SD to put them, and adjust the above commands accordingly.
« Last Edit: January 01, 2015, 04:59:50 am by Senor Quack »

slaanesh (OP)

  • *
  • Posts: 476
    • Slaanesh Dev
Re: XMAME v1.0 release
« Reply #48 on: January 01, 2015, 05:42:56 am »
I find 69 is actually the best version - a little to a fair bit faster than 84 in manty cases.

Save states is tricky... Most games do not support save states, though as the versions increase so does save state compatibility.

As a general guide, Neo Geo and Taito have support. I tried xexex and that works from 52 onwards.

I also have a new version of the installer ready.
Will upload shortly.

Xaijiqq

  • *
  • Posts: 410
Re: XMAME v1.0 release
« Reply #49 on: January 01, 2015, 09:12:33 am »
I also have a new version of the installer ready.
Will upload shortly.
that would be much appreciated :)

Gab1975

  • ***
  • Posts: 1165
Re: XMAME v1.0 release
« Reply #50 on: January 01, 2015, 09:35:59 am »
I noticed that, when I add or I remove some games, the emulator ROMs lists aren't updated automatically... to refresh the lists I need to go into the connected "frontend" folder and delete xmame.lst file...
This is not a "big problem", but a good solution could be to add a function/button in the menu to refresh the list, e.g.: "X: Refresh"

Xaijiqq

  • *
  • Posts: 410
Re: XMAME v1.0 release
« Reply #51 on: January 01, 2015, 09:48:47 am »
I noticed that, when I add or I remove some games, the emulator ROMs lists aren't updated automatically... to refresh the lists I need to go into the connected "frontend" folder and delete xmame.lst file...
This is not a "big problem", but a good solution could be to add a function/button in the menu to refresh the list, e.g.: "X: Refresh"
you can press start when at the gamelist to check available roms which refreshes the list ;)

Gab1975

  • ***
  • Posts: 1165
Re: XMAME v1.0 release
« Reply #52 on: January 01, 2015, 10:16:43 am »
you can press start when at the gamelist to check available roms which refreshes the list ;)

Thanks for the tip! ;) ... sometimes I'm a bit "lamer" ! :P

pcercuei

  • ***
  • Posts: 1428
    • My devblog
Re: XMAME v1.0 release
« Reply #53 on: January 01, 2015, 11:03:04 am »
I don't really mind the installer if it's done properly - although I really don't get the point.

What I do mind, is that you hardcode the paths. This *will* break at some point, and makes your port really tight to OpenDingux. If you need to install data, the best is to install to $HOME/.local/share/mame or $HOME/.mame, and then it will work on every GNU/Linux OS.

About the mount-point of the external SD card: we could have decided to use a fixed mount-point but that's not how we want to do things in OpenDingux, for the same reason we don't want hardcoded paths: it makes the application really specific to OpenDingux. Then, it is becomes a pain to port it to something else, and/or breaks when we update the OS... and this is a big problem: if a lot of apps break everytime we update something in the OS, then we just discard the update to avoid problems. Having the applications more OS-agnostic give us the flexibility to tweak the OS and improve it as we go.

slaanesh (OP)

  • *
  • Posts: 476
    • Slaanesh Dev
Re: XMAME v1.0 release
« Reply #54 on: January 01, 2015, 11:55:53 am »
What I do mind, is that you hardcode the paths. This *will* break at some point, and makes your port really tight to OpenDingux. If you need to install data, the best is to install to $HOME/.local/share/mame or $HOME/.mame, and then it will work on every GNU/Linux OS.
I'll make the install point $HOME/.xmame for the next major release.

For now I've updated the installer so there is a v1.1 available. The main executables have not changed - just the installer.

It should now work with SD cards formatted as FAT32, even if it has a named label.

Check my webpage www.slaanesh.net for a new download link.

Gab1975

  • ***
  • Posts: 1165
Re: XMAME v1.0 release
« Reply #55 on: January 01, 2015, 01:31:11 pm »
I tried four SEGA System32 games (Air Rescue, Aliens 3 the Gun, Arabian Fight and Golden Axe 2) and all of them have the same issue: the emulation starts, there are graphic glitches (especially related to the zoom effects) and after few seconds the game crashes (come back to the Gmenu2X).

Xaijiqq

  • *
  • Posts: 410
Re: XMAME v1.0 release
« Reply #56 on: January 01, 2015, 01:57:26 pm »
copied v1.1 to the internal apps folder and chose to install to external SD card which initially seemed to have worked.  but after it completed when brought back to the gmenu2x i don't see the XMAME v1.1. icon?  the installer is still there of course.  tried rebooting and nothing

no directories, no icon, do i need to re-install v1.0 first?  because i did delete everything before trying v1.1

« Last Edit: January 01, 2015, 02:17:27 pm by Xaijiqq »

Xaijiqq

  • *
  • Posts: 410
Re: XMAME v1.0 release
« Reply #57 on: January 01, 2015, 03:11:35 pm »
"You may need to correct some symlinks ie. 'snap' directory and hiscore.dat and history.dat and adjust the icon path"

so how exactly is this done?  specifically the icon path
« Last Edit: January 01, 2015, 03:14:30 pm by Xaijiqq »

chevette

  • *
  • Posts: 191
Re: XMAME v1.0 release
« Reply #58 on: January 01, 2015, 03:41:27 pm »
Thanks Slaanesh. Just installed on my FAT32 32GB microSD card + it worked perfectly. Thanks for all the cool emulators on the Dingoo A320 and now the ZERO.....happy New Year!!

slaanesh (OP)

  • *
  • Posts: 476
    • Slaanesh Dev
Re: XMAME v1.0 release
« Reply #59 on: January 01, 2015, 08:10:52 pm »
copied v1.1 to the internal apps folder and chose to install to external SD card which initially seemed to have worked.  but after it completed when brought back to the gmenu2x i don't see the XMAME v1.1. icon?  the installer is still there of course.  tried rebooting and nothing

no directories, no icon, do i need to re-install v1.0 first?  because i did delete everything before trying v1.1

You won't need to fix anything now after the XMAME v1.1 installer finishes, it takes care of everything

The real problem is that I have found that the GCW-Zero doesn't mount the SD card sometimes! It's nothing to do with XMAME I'm afraid. The only thing you can do is use the "Settings=>Reboot" icon from within Gmenu2x.

I'll look into the Sega system32 games.

EDIT: Found it. Okay that will be fixed in the next release.
« Last Edit: January 01, 2015, 08:39:24 pm by slaanesh »

 

Post a new topic