launching games via a front end

[Weestuarty]

Hi there I am part of a team working on an android front end and we are trying to launch some retro systems on this app but are having difficulty. We can launch and play the games (gamate in this example) but we cannot seem to get them to launch. currently our command is %EMULATOR_MAME4DROID-2024% %ACTION%=android.intent.action.VIEW %DATA%=%ROMPROVIDER% but we cannot figure out how to pass additional commands like -cart in windows/linux. could you help.

[seleuco]

That's currently not implemented. Only arcade Roms can be launched with an intent. I will look into when I have some time.

[Weestuarty]

Thanks for the quick reply it saves hours of trail and error

[leonstyhre]

Hi @seleuco

Adding to this, it would open up incredible possibilities on Android to emulate systems that have previously never been emulated. Take a look at the systems for the Linux port of ES-DE for instance:

https://gitlab.com/es-de/emulationstation-de/-/blob/master/resources/systems/linux/es_systems.xml?ref_type=heads

There are a lot of systems that depend on MAME (RetroArch core or standalone) and that require passing of options. For example the apple2, archimedes, electron, fmtowns, gamate, odyssey2, pv1000, ti99 and trs80 systems just to name a few.

For Android a lot of systems are currently placeholders due to lack of emulator support on this operating system:

https://gitlab.com/es-de/emulationstation-de/-/blob/master/resources/systems/android/es_systems.xml?ref_type=heads

Assuming you have included MESS systems in your emulator (you have that in there, right?) and could find a way to pass these options as Intent extras, then it would make it possible to add support for so many more systems. It would be great to be able to emulate more 8-bit computers on Android for example.

Please consider this request, and if you decide to implement it I'll gladly help with testing it in ES-DE and with providing feedback etc.

[seleuco]

Hi @leonstyhre,

as I said before I’ll take a look :). I want people to enjoy using all the systems that Mame devs have emulated and I really like the work that is done by the android frontends developers.

Said that, yes, this build include all mess systems.

Anyway, you can already enjoy them using MAME4droid from the MAME UI itself. Put your cartridge on a software folder under the roms folder on your external storage, select the system from the main system list, launch the system empty option and then use the MAME UI to load the cartridge from the software folder. Also. You can use the software list aproach, putting the software in the correct folder as is done in MAME desktop.

[leonstyhre]

Thanks for considering this request! Yes sure you can run some things from inside MAME but I'm a frontend developer you know ;)

Anyway, it's also not always this simple, consider the following configuration for the bbcmicro, electron and ti99 systems as examples:

<command label="MAME (Standalone)">%STARTDIR%=~/.mame %EMULATOR_MAME% -rompath %GAMEDIR%\;%ROMPATH%/bbcmicro bbcb -autoboot_delay "2" -autoboot_command "*cat\n\n*exec !boot\n" -flop1 %ROM%</command>

<command label="MAME [Diskette ADFS] (Standalone)">%STARTDIR%=~/.mame %EMULATOR_MAME% -rompath %GAMEDIR%\;%ROMPATH%/electron electron64 -exp plus3 -exp:plus3:fdc:1 35dd -autoboot_delay "2" -autoboot_command "*CAT\n\n\n\n\n\n*RUN !BOOT\n" -flop1 %ROM%</command>

<command label="MAME (Standalone)">%STARTDIR%=~/.mame %EMULATOR_MAME% -rompath %GAMEDIR%\;%ROMPATH%/ti99 ti99_4a -ioport peb -ioport:peb:slot3 speech -cart %BASENAME%</command>

You really need to be able to pass very specific configuration strings or it will not work.

[seleuco]

@leonstyhre

So, giving it a quick thought, what occurs to me is you to pass a correctly escaped string on a putExtra with all the commands to pass them directly to MAME core as args[n] CLI parameters. I will need to tokenizer parameters with '-' token.

Do you think it could work for you?

intent.putExtra("whatever", "bbcb -autoboot_delay \"2\" -autoboot_command \"cat\\n\\nexec !boot\n\" -flop1 GAME");

[leonstyhre]

Yes that could work, or we could use the putExtra() function that takes a String array as an argument, i.e:

https://developer.android.com/reference/android/content/Intent#putExtra(java.lang.String,%20java.lang.String[])

I have an %EXTRAARRAY% variable in ES-DE today which takes a comma-separated list of arguments and places those into a String array which it passes to the putExtra() call.

I use this for the Vita3K emulator already, like this:

<command label="Vita3K (Standalone)">%EMULATOR_VITA3K% %EXTRAARRAY_AppStartParameters%=-r,%INJECT%=%BASENAME%.psvita</command>

This will inject the content of the .psvita file for the game (which is a PlayStation Vita game ID) and passes the extra named AppStartParameters with an array that contains these two elements (although it could be N amount of elements if I had more comma-separated values). Let's assume that the game ID is PCSE01116, in this case the array elements will be "-r" and "PCSE01116" (excluding the quotation marks of course).

That may make it simpler for you I suppose as you don't need to tokenize the string, or at least I don't think you would need to?

You would just need to decide on what to name the extra, for example "cliParams" or "options" or "arguments" or whatnot, I don't know what makes most sense for MAME :)

Here's my Java code that generates the putExtra() call to clarify further:

for (HashMap.Entry<String, String> extra : extrasStringArray.entrySet()) {
    // Split by commas, unless they are escaped.
    String[] values = extra.getValue().split("(?<!\\\\),");

    // Replace escaped commas with literal commas.
    for (int i = 0; i < values.length; i++)
        values[i] = values[i].replace("\\,", ",");

    launchIntent.putExtra(extra.getKey(), values);
}

So the method would split up the following string: -r,PCSE01116

And then make two array elements, and if I wanted to pass a literal comma, I'd just escape it using a backslash.

[seleuco]

I prefer a single string since my java jni layer has already a bridge to pass string from java to c++ Code. So i prefer to tokenize on c++ size. But I will think about it.

El lun, 12 feb 2024, 17:21, Leon Styhre @.***> escribió:

Yes that could work, or we could use the putExtra() function that takes a String array as an argument, i.e:

https://developer.android.com/reference/android/content/Intent#putExtra(java.lang.String,%20java.lang.String[]) https://developer.android.com/reference/android/content/Intent#putExtra(java.lang.String,%20java.lang.String%5B%5D)

I have an %EXTRAARRAY% variable in ES-DE today which takes a comma-separated list of arguments and places those into a String array which it passes to the putExtra() call.

I use this for the Vita3K emulator already, like this:

%EMULATOR_VITA3K% %EXTRAARRAY_AppStartParameters%=-r,%INJECT%=%BASENAME%.psvita

This will inject the content of the .psvita file for the game (which is a PlayStation Vita game ID) and passes the extra named AppStartParameters with an array that contains these two elements (although it could be N amount of elements if I had more comma-separated values). Let's assume that the game ID is PCSE01116, in this case the array elements will be "-r" and "PCSE01116" (excluding the quotation marks of course).

That may make it simpler for you I suppose as you don't need to tokenize the string, or at least I don't think you would need to?

You would just need to decide on what to name the extra, for example "cliParams" or "options" or "arguments" or whatnot, I don't know what makes most sense for MAME :)

Here's my Java code that generates the putExtra() call to clarify further:

for (HashMap.Entry<String, String> extra : extrasStringArray.entrySet()) { // Split by commas, unless they are escaped. String[] values = extra.getValue().split("(?<!\\),");

// Replace escaped commas with literal commas.
for (int i = 0; i < values.length; i++)
    values[i] = values[i].replace("\\,", ",");

launchIntent.putExtra(extra.getKey(), values);

}

So the method would split up the following string: -r,PCSE01116

And then make two array elements, and if I wanted to pass a literal comma, I'd just escape it using a backslash.

— Reply to this email directly, view it on GitHub https://github.com/seleuco/MAME4droid-2024/issues/24#issuecomment-1939069817, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABQGONGKWVCQWZ53LLXXFM3YTI6RTAVCNFSM6AAAAABC7YK23OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZZGA3DSOBRG4 . You are receiving this because you were mentioned.Message ID: @.***>

[leonstyhre]

Let me know the best approach for your code, I should be able to support either of them! I probably just need to add support for escaping quotation marks if it's a single string, unless I have already added that in (can't remember).

[seleuco]

@leonstyhre

Hi i have added the reading of "cli_params" key to the ACTION_VIEW intent extra to receive additional parameters to pass to MAME core as qargs properly tokenized. You don't have to pass the system name in cli_params because it is obtained from the uri.

To test i have been harcoding this use case to load a c64 cass and it has worked as it should

cliParams = "-skip_gameinfo -cass gng -autoboot_delay 2 -autoboot_command 'load\\n'";

Pay attention to the single quote I put so that you can send commands that have spaces between them. If you think that it can cause problems, I will change it for the one you tell me.

Do you think it's okay or do you need something else?

[leonstyhre]

Thanks, I will try to look into testing this tomorrow! Where can I install a version of your emulator where this code is included? Or have you already made this part of the official/published app?

[seleuco]

I have published a 1.9.3 version that is under review that includes this change. However, tomorrow I will update the repository and publish a release here...

[leonstyhre]

Perfect, then I should have something to test tomorrow. Thanks again for looking into this, if we can make this work it really opens up a lot of opportunities for emulating more systems!

[leonstyhre]

Initial testing looks really promising! I passed the "-skip_gameinfo" option and it worked perfectly :)

I'll continue with some more advanced configuration and let you know how it goes!

[seleuco]

That's good 😊👍

El vie, 16 feb 2024, 17:33, Leon Styhre @.***> escribió:

Initial testing looks really promising! I passed the "-skip_gameinfo" option and it worked perfectly :)

I'll continue with some more advanced configuration and let you know how it goes!

— Reply to this email directly, view it on GitHub https://github.com/seleuco/MAME4droid-2024/issues/24#issuecomment-1948829668, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABQGONHQPHKDXROPW2NIAO3YT6C6XAVCNFSM6AAAAABC7YK23OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNBYHAZDSNRWHA . You are receiving this because you were mentioned.Message ID: @.***>

[leonstyhre]

So I tried a slightly more involved setup and I can't get it to work, I'm not sure exactly what the approach would be to be honest. It's for the Bally Astrocade system. It looks like the following in Linux:

<command label="MAME - Current">%EMULATOR_RETROARCH% -L %CORE_RETROARCH%/mame_libretro.so "astrocde -rompath \"%GAMEDIRRAW%;%ROMPATH%/astrocde\" -cart \"%ROMRAW%\""</command>

But on Android I'm not sure how this would work, you would normally want to pass the ROM path as an argument for the -cart flag, but how could this work when you're passing the URI to the ROM using setData() ?

I mean this is what I do, but that could of course never work:

<command label="MAME4droid 2024 (Standalone)">%EMULATOR_MAME4DROID-2024% %ACTION%=android.intent.action.VIEW %EXTRA_cli_params%="astrocde -cart " %DATA%=%ROMPROVIDER%</command>

Any ideas?

[seleuco]

For this to work it first has to work within android MAME virtual file system. You cannot change or use multiple ROMs o software paths since there is a scoped storage limitation and MAME4droid would not have permissions to read from wherever you want.

Everything has to be realitive to the virtual file system that MAME4droid sets up by reading all the files at startup.

That is, everything has to be structured according to how MAME structures it by default. The systems are in the root of the ROMS folder and the system software in a subfolder named according to the device type used to read it.

That is, assuming a commodore 64 system, the c64.zip file (BIOS) has to be in the root of the authorized directory for MAME4droid. Below, there must be the subdirectories with the media from software list, for example a folder: c64_cass\gng.zip where gng.zip is the software media.

Then,the way to invoke the c64 system to read the gng.zip cassette would be:

"-cass gng -autoboot_delay 2 -autoboot_command 'load\n'"

An the intent URI will be the c64.zip file.

MAME4droid has only one authorized ROM path. All cli parameters and system and media files has to be relative to that's rom path. that's why you don't have to pass the rom path to read the media.

So, your cli should be:

"astrocde -cart 'whatever'"

and astrocde.zip (system) should be in the MAME4droid roms root folder and the media in roms (root) subfolder astrocde_cart\whatever.zip (you can look the software list in the MAME hash folder to figure the media folders you need)

Android retroarch (i think) works in a different way since they do not target to a modern SDK, that is why they do not have the limitations of scoped storage but, as a counterpart, they cannot update or publish it in Google Play newer version since google don't allow legacy apps....

[leonstyhre]

Yes this is a nightmare on Android, I use manage storage permissions and although Google has previously approved that it seems like they have revoked it now that I moved the application to closed testing. This means that I may never make a release of ES-DE as it must have those permissions to function.

When porting ES-DE to Android I did a lot of research on this and it seems like many applications and emulators only function because they target an older API level and since Google now requires Android 12 or later for anything to be updated on the Play store this is likely to lead to a lot of emulators and other applications being in limbo, never getting a new release. Sooner or later they will cease to function altogether I guess. In the end everything possibly has to be sideloaded. The RetroArch release on the Play store is not really usable, you'll need to sideload the manually downloaded APK. In my opinion Google has managed to completely destroy their own platform, they are scaring away a lot of developers. Why would someone spend months or years developing an application and then you don't even know if it will get the necessary permissions to even function. That's exactly where I am now with my project and it's truly horrible, such a developer-hostile platform. API stability is also a nightmare on Android, they just keep deprecating everything basically without any respect for developers or their applications. I'm developing ES-DE for Linux, BSD Unix, macOS, Windows, and now Android and no other operating system is nearly as hellish as Android to develop for, for the reasons just mentioned.

Anyway, assuming ES-DE does get approved I actually give MAME4droid access to the current ROM directory using the FileProvider API (that's the %ROMPROVIDER% variable in the launch command) so it should work if you had an option to insert the ROM path after the -cart flag. well at least I think so.

The way that ES-DE works is that all systems are separated into different directories and this works perfectly fine today even if I don't give access to those individual directories from inside MAME4droid.

[leonstyhre]

And btw, you need the MANAGE_EXTERNAL_STORAGE permissions to be able to use the FileProvider API to share files from the external/shared storage which is another piece of insanity as it means this API can't be used at all by the overwhelming amount of applications that could benefit from it.

[seleuco]

Yeah. You are right about all this. I started making homebrew for fun on the gp32 console almost 15 years ago, then I realized the potential and was one of the first developers to develop / port emulators for mobile devices.

I started on iOS and Android but I left iOS because I didn't like the closed environment and that people couldn't easily enjoy the work I was doing. So I focused on Android and it's true that it looks more and more like Apple this days.

When the store was growing it was all love for the developers but that doesn't happen anymore.

I dislike all this about scoped storage and how it forces the developer, also currently you have to have your applications only two years out of date otherwise they disappear from google play for new devices.

Regarding the deprecation of the apis, you are absolutely right. At least it seems to still work. The core of this application was developed over almost 15 years and continues to work. Someday I will remove all deprecated code like when I had to go through the scoped storage hoop.

In any case, I do this for fun and mainly for me. The only way to have something that you like is to do it yourself and since I have the ability and I love MAME and I greatly respect the people who work on the MAME project, I have made this version for Android the way I like it and that it be as respectful as possible with the original.

[seleuco]

“Anyway, assuming ES-DE does get approved I actually give MAME4droid access to the current ROM directory using the FileProvider API (that's the %ROMPROVIDER% variable in the launch command) so it should work if you had an option to insert the ROM path after the -cart flag. well at least I think so.

The way that ES-DE works is that all systems are separated into different directories and this works perfectly fine today even if I don't give access to those individual directories from inside MAME4droid.“

I will think into this, although in principle I don't see any sense as you can already prepend a filepath (media path) in the cli parameter.

You can test it with a hardcoded path to see if it’s works.

I mean -cart ‘/a/b/whatever’

In any case, have you tested with a neogeo game which requieres bios. I mean, with files that depend on other files such as bios?

I do a little trick with roms that do not come from my authorized directory and is to copy them to an authorized directory to me on the internal storage since the intent let me access to read the uri file, but this only works with merged rom sets. So this will not work with mess media.

To correctly test it the bios has not to be on my authorized folder, of course.

[leonstyhre]

Thanks a lot for your comments, sometimes it feels like I'm all alone in my issues with getting my app published on the Play store, it really is so hard. I actually don't know what to do right now, my app is in a weird state where the last uploaded version has been published and works correctly with the necessary permissions but where the Play Console says it's noncompliant and can't be published. I'm trying to drive this as a bug report towards Google because I can't understand how this is not a bug that an app is both published and can't be published (i.e. the exact same version). But so far it's been like talking to a wall.

I'm currently considering releasing on the Amazon Appstore instead which seems much more reasonable, but I'm not sure what the reach for my application would be. Do you have any experience with this appstore?

As for the systems requiring BIOS files you're right, they don't actually work when I test them from ES-DE. For example the Neo Geo system. But since I provide access to the directory using the FileProvider API, couldn't you just load the necessary files (like neogeo.zip) from the same directory as the game file?

I haven't tested adding the absolute path to the -cart flag yet, I'll try to do that soon.

[leonstyhre]

Actually, I did some further testing and the additional BIOS files are picked up, now I think I understand what you mean.

So in ES-DE there's a general ROMs directory with subdirectories per system, for example /storage/emulated/0/ROMs/arcade and /storage/emulated/0/ROMs/neogeo and so on. And if I for example give access specifically to /storage/emulated/0/ROMs/arcade in MAME4droid then it works perfect, and I can run games from this directory even if they are not merged.

But if I do the above, then neogeo games don't work. However if I go into MAME4droid and change the ROMs directory to /storage/emulated/0/ROMs/neogeo instead then Neo Geo games run fine from ES-DE (the neogeo.zip file is picked up correctly) but the arcade games no longer work.

This is similar to how some other emulators do it actually, but you can normally define multiple ROMs directory permissions for those, which works around this problem. This also leads me to suspect that you are actually not using the FileProvider URI that I pass to you to gain permissions to the directory? Or maybe it's related to how you place BIOS files and such into the temporary directory you mentioned?

Regardless I think this could be solved somehow so that MAME4droid would work with multiple separate game system directories as just explained above. Or what are your thoughts on this? :)

[seleuco]

sorry for the delay. I've been really busy 😥

yes you are right with your findings. Remember that I’m on scoped storage mode and I don’t use your file provider to grant anything.

Is the user who grants me to read one external storage directory.

As an exception, i read your file URI which is granted to me via intent from anywhere in the device and I copy it to a internal app granted folder if is not in my granted folders.

I’m working with my own virtual file system build on app start using android documents provider api which expose posix authorized file descriptors from Java side which are passed to posix native code. This VFS is bidirectional from java to native. Yes. It is a super complication necessary for the native IO code to work transparently thanks to the bullshit of scoped storage

Maybe this issue help you understand how I deal with scoped storage and why I don't want multiple directory authorizations. it would complicate my life a lot since I have a VFS:

https://github.com/seleuco/MAME4droid-2024/issues/2

A possible approach would be to define those folders in the mame ini and have the user authorize the root of them to me. As the user in the issue has done.

Or maybe you could give me the ROM folders in the intent so I passed them as cli to mame core (as long as they are children of my authorized parent directory) and have the user authorize the root of them. but I don't know if this is very complicated and not very flexible.

There would also be the problem that my virtual file system would contain the files of all the systems not only those of mame/mess and that could be very slow…

[leonstyhre]

Thanks for your detailed explanation! I attempted to build a similar solution to be able to use scoped storage, i.e. translate native file operations to the SAF/MediaStore. But this required so much extra logic and UTF8 translations and whatnot from C++ and with the additional restrictions introduced in Android 13 it just wasn't possible in the end. I almost got it working, but never 100%, and performance would have been horrible anyway as ES-DE easily handles tens of thousands or even hundreds of thousands of files if you have a large collection (up to 11 media files per game and at some points a lot of files need to be inventoried and such).

Btw, I did manage to publish my application on the Amazon Appstore, that works around the limitations because they don't have the crazy storage restrictions that Google has on their Play store. Maybe worth considering an alternative release of MAME4droid which is not crippled (sorry but it's true) due to the Google limitations? It was a very nice experience to publish on Amazon, fast and simple and no issues with any of the permissions required: https://www.amazon.com/dp/B0CVXRHWTT/

Anyway, back to the problem at hand, I can for sure set MAME4droid to the root of the ROMs directory and it works to launch games from ES-DE that only need a single file. But anything that is not merged, like the neogeo games for instance no longer work. I didn't fully understand your comment on this, do you think there could be a way to work around this by setting the scoped storage in MAME4droid to the root of the ROMs folder, as long as I pass you some extra information to you? What precisely do you need in this case? Modifying mame.ini does however not sound like a feasible solution, most people would have no idea how to do that.

[seleuco]

I'm glad you finally published it in the Amazon store. I hope that the problems with Google are solved and finally it can also be on Google Play :)

respect to the problem, theres is a CLI mame parameter you can pass to me to set customs roms paths:

-rompath / -rp <path>

Specifies one or more paths within which to find ROM or disk images. Multiple paths can be specified by separating them with semicolons.

Yo also need to enable in MAME4droid options -> Settings -> Advanced -> Use mame.ini for paths (This is a temporary thing. If this worked I could detect that specific cli and not put my defaults)

That way,

lets say, ES-DE has /storage/6631-6132/Games as the main folder which has all ROMs for different emulators. Then you have to autohorize as ROM's folder in MAME4droid settings the same folder /storage/6631-6132/Games, so i can read all files under that folder.

Now comes the matter. Obviously not all the subdirectories are of interest to MAME and you also have to tell it which of them are the correct ones where it has to read the ROMS, BIOS or media.

Therefore you have to pass those subdirectories via CLI in the following way:

-rp '/storage/6631-6132/Games/MAME;/storage/6631-6132/Games/NeoGeo;./roms'

where "MAME" has your main mame folder roms and "neogeo" has your neogeo roms. (the last one is the roms default)

If there was another directory with BIOS, then it would look like this

-rp '/storage/6631-6132/Games/MAME;/storage/6631-6132/Games/NeoGeo;/storage/6631-6132/Games/bios;./roms'

Obviously now the MAME4droid SAF code scans all the subdirectories from /storage/6631-6132/Games not just those passed through the CLI and it will be slow. But if this works,the directories could be passed to the SAF code so that it only scans the ones that you pass through the CLI, that way it would work faster. But for now, it may be worth trying.

The same for mess software media (if you dont want to use the default SW list default structure in ROMs folders) so you can pass -cart parameter directly with the media file instead cass_whatever\mediafile and so the user has not to physically set the files as the SW list indicates neither)

In this case, the cli will be:

-swpath <path>

Specifies the default path from which to load loose software image files.

The default is sofware (that is, a directory software in the current working directory).

But first try with not merged roms.... ;)

[leonstyhre]

Thanks :) And yes I hope that Google will allow the permissions but I doubt it to be honest.

And thanks for the explanation, I'll try it out as soon as I can, I've been dealing with some urgent fixes and changes for the release in the past few days so haven't had time to look into this yet!

[seleuco]

No hurries. The users first. the fun and challenge afterwards 🤣👍

[leonstyhre]

Hey man I'm really sorry for the very, very long delay in responding! I have had a totally crazy time during the past few months, but I hope things are finally starting to return more to normal again.

I have finally done quite thorough testing and I'm very happy to say that it works great and that the changes you made to your emulator will open up support for a lot more systems on Android for the first time! Code changes were needed in ES-DE to make it work but I'll include those in the upcoming 3.0.3 release which will also include support for a lot of more systems due to MAME4droid 2024 now supporting them!

There is one thing I found though that I'm not sure is intentional or not, and that is that for MESS systems the machine type can only be set using setData() for the Intent rather than being passed in the cli_params Extra.

To clarify, this is the configuration for Bally Astrocade: <command label="MAME4droid 2024 (Standalone)">%EMULATOR_MAME4DROID-2024% %ACTION%=android.intent.action.VIEW %EXTRA_cli_params%="-rompath '%GAMEDIRRAW%;%ROMPATHRAW%/astrocde' -cart '%ROMRAW%'" %DATA%=astrocde</command>

As you can see "astrocde" is set via the %DATA% variable. This is perfectly fine for me and it works, I just don't want to add this config for all systems if it's indeed unintentional and you'll change the logic in a future release.

To clarify further, doing the following does not work: %EXTRA_cli_params%="-rompath '%GAMEDIRRAW%;%ROMPATHRAW%/astrocde' astrocde -cart '%ROMRAW%'"

For reference, this is how MAME is setup in ES-DE for Linux for the astrocde system: <command label="MAME (Standalone)">%STARTDIR%=~/.mame %EMULATOR_MAME% -rompath %GAMEDIR%\;%ROMPATH%/astrocde astrocde -cart %BASENAME%</command>

Again not a problem at all, as long as the functionality is intended like this and won't be changed in the future.

Btw, I did not need to change the mame.ini setting under the Advanced settings menu so I guess you already fixed that? :)

The proposal you made in an earlier comment to only scan the directories set via the -rompath or -rp command line option would be a very good improvement though as it would speed up startup times considerably.

Anyway, many thanks for all your work on this stellar emulator! It really will open up support for so many new systems on Android.

Even harder-to-run systems like the BBC Micro now work perfectly, this setup even autostarts the game as intended (exactly as it does on desktop operating systems with MAME standalone): <command label="MAME4droid 2024 (Standalone)">%EMULATOR_MAME4DROID-2024% %ACTION%=android.intent.action.VIEW %EXTRA_cli_params%="-rompath '%GAMEDIRRAW%;%ROMPATHRAW%/bbcmicro' -autoboot_delay '2' -autoboot_command '*cat\n\n*exec !boot\n' -flop1 '%ROMRAW%'" %DATA%=bbcb</command>

[seleuco]

Hey man I'm really sorry for the very, very long delay in responding! I have had a totally crazy time during the past few months, but I hope things are finally starting to return more to normal again.

I'm glad to hear from you and that you're less busy these days 😄

I have finally done quite thorough testing and I'm very happy to say that it works great and that the changes you made to your emulator will open up support for a lot more systems on Android for the first time! Code changes were needed in ES-DE to make it work but I'll include those in the upcoming 3.0.3 release which will also include support for a lot of more systems due to MAME4droid 2024 now supporting them!

That's great 👍

There is one thing I found though that I'm not sure is intentional or not, and that is that for MESS systems the machine type can only be set using setData() for the Intent rather than being passed in the cli_params Extra.

That is done that way on purpose. For consistency, as I have always received roms arcade names (using data), the machine names works the same.

Btw, I did not need to change the mame.ini setting under the Advanced settings menu so I guess you already fixed that? :)

I haven't touched anything about that. I think that basically it was not necessary if you set the root directory correctly.

The proposal you made in an earlier comment to only scan the directories set via the -rompath or -rp command line option would be a very good improvement though as it would speed up startup times considerably.

Yes that would improve a lot. I'll see if I can add it in a future update...

Anyway, many thanks for all your work on this stellar emulator! It really will open up support for so many new systems on Android.

Even harder-to-run systems like the BBC Micro now work perfectly, this setup even autostarts the game as intended (exactly as it does on desktop operating systems with MAME standalone): <command label="MAME4droid 2024 (Standalone)">%EMULATOR_MAME4DROID-2024% %ACTION%=android.intent.action.VIEW %EXTRA_cli_params%="-rompath '%GAMEDIRRAW%;%ROMPATHRAW%/bbcmicro' -autoboot_delay '2' -autoboot_command '*cat\n\n*exec !boot\n' -flop1 '%ROMRAW%'" %DATA%=bbcb</command>

I would like to try all this great work you have done. Is there an evaluation version available so I can play around with it?

Cheers!

[Weestuarty]

Do you use discord at all? If you do join us and we can arrange for you to get the full version sent via our email updates and get the current link. If not then we just need an email to send it too. ALthough it would be great to have you with us on the server.

https://discord.gg/HmBZkmTd

[seleuco]

No. I don't use discord personally. I try to stay disconnected as much as possible because otherwise I end up getting quite stressed and I already have enough with real work 🤣 My email is seleuco.nicator@gmail.com

[Weestuarty]

no problem ill forward you the email with the current release and then you will recieve all future updates (MAME4droid isnt on current yet for these systems)

[Weestuarty]

sent

[seleuco]

sent

Thanks mate 👍

[Weestuarty]

No thank you you have helped us fill in so many game systems to bring to our android version. https://gitlab.com/es-de/emulationstation-de/-/blob/master/ANDROID.md?ref_type=heads have a look at the supported list and see how many that show as placeholder that your app will run.

No doubt Leon will reply with more dev talk but i jumped in just to get you sorted with the app so you can enjoy what you are helping others enjoy

[leonstyhre]

@seleuco Thanks a lot for your fast response! And also thanks for clarifying the way the machine name is passed, it makes perfect sense to have it work like this as it's consistent :)

And good that @Weestuarty already got you the download link to the latest ES-DE APK. I've also added you to the distribution list so that you will get future updates whenever I release them.

I will also provide you with a test build once I've added in support for all the MESS systems. I need to fix some other minor things first, but hopefully it's ready within a few days or so. I normally just share it via Google Drive so I'll send you an email with the URL once it's ready.

I have already tested a number of systems that were previously not supported and it's so great to see systems like Apple II, Apple IIGS, Acorn Archimedes and the BBC Micro finally running on Android!

However I have run into some issues with controller input, I guess some work could be needed in the emulator to support some of these systems fully? For example I've not been able to get mouse buttons to work for systems like Apple IIGS although it works if I plug in a physical/external keyboard. Mouse touch support doesn't work either on my Odin 2 for example, but the thumbstick works to move the mouse cursor around.

Maybe when I've added in support for all systems and provided you with a test build of ES-DE we could start looking into whether these issues are possible to solve via configuration or if code changes would be required?

[seleuco]

I have already tested a number of systems that were previously not supported and it's so great to see systems like Apple II, Apple IIGS, Acorn Archimedes and the BBC Micro finally running on Android!

Nice 👍

However I have run into some issues with controller input, I guess some work could be needed in the emulator to support some of these systems fully? For example I've not been able to get mouse buttons to work for systems like Apple IIGS although it works if I plug in a physical/external keyboard. Mouse touch support doesn't work either on my Odin 2 for example, but the thumbstick works to move the mouse cursor around.

The touch control is designed primarily for arcade machines. Supporting so many types of combinations for MESS systems is really complicated since for it to work well you need almost one combination for each one.

A while ago I developed a spectrum emulator and the control worked great but I had to have specific keys assigments to the virtual stick and buttons. That's really impossible for as many systems as there are in MAME.

That's why I wanted it to at least work correctly with physical devices like keyboard and mouse. Also, if you are an advanced user (and I think most of those interested in mess are) you can do things using MAME's own configuration but it requires some time and work.

Running a mouse completely by touch is really complicated and frustrating. Look at all those remote desktop apps and you will see the solutions they offer for the 2nd and 3rd buttons. In the end there are more and more buttons and if you have to combine the stick and keyboard with that, everything becomes super complicated with so many systems and combinations. and very few users will take advantage of it since they do not even distinguish that difference between a 0.139 ROM and a 0.266 one :) The best thing is to plug in a physical mouse and/or keyboard and stop inventing for those really interested in messing around with mess systems.

Maybe when I've added in support for all systems and provided you with a test build of ES-DE we could start looking into whether these issues are possible to solve via configuration or if code changes would be required?

When you have it ready we can see things and if something simple can be done we will see it. ;)

[leonstyhre]

Yes I can imagine it's very difficult to support everything due to the huge amount of systems that can be emulated via MAME. I think it's perfectly fine to use the thumbstick for mouse input when on a handheld device for instance, but how would you handle it on a mobile phone? Maybe the touch overlays could be used for this purpose somehow?

Anyway, my finding so far is that the most important thing is to be able to use the mouse buttons somehow, as it's really essential when emulating computer systems. Some only have a single button though, like most older Apple systems...

But let's see when we start more thorough testing of these systems. I need a couple of more days before I'll be able to provide a test build, but it's coming. In the meanwhile you can take a look at the ES-DE changelog, most of the new systems that are enabled in the upcoming 3.0.3 release are due to MAME4droid 2024!

https://gitlab.com/es-de/emulationstation-de/-/blob/master/CHANGELOG.md

[leonstyhre]

@seleuco You can go ahead and close this issue, support for it has been included in the recent ES-DE 3.0.3 release and many people are now very happily using MAME4droid 2024 for all the new systems these changes enabled.

Thanks a lot for adding this in, it's much appreciated by a lot of folks :)

[Weestuarty]

Hey i think i can close it!

Leons is right though awesome work.