How to get a fully working ScummVM with gamepad Support on 1.3.0 (Android)

RetroArch Android devices
#1

edit: One other user is reporting that the current build of ScummVM works fine one his android device - so I have to preface – the following is describing a workaround if in your case also - launching the ScummVM Core in RetroArch 1.3.0 crashes the app.

The devs botched the ScummVM support in the current 1.3.0 version again - but with some ingenuity I got it working.

I will not open any tickets on the bug tracker - as I had a very bad experience with this in the past - I will list the problems, causes and steps that are necessary to get this working in here and in here only. So if you are a dev and want to do something about this - this is as much input as you will get from me.

Ok - lets start.

Older versions of Retroarch had an issue where on the ScummVM menu (once the core was loaded) the mouse speed for left stick mouse emulation was so freakishly high - that you couldnt select any settings or import a game into ScummVM and then start it - without spending half an hour trying to position the cursor - thousands of times.

1.3.0 has fixed this.

BUT - and there is a big but here.

On 1.3.0:

  • The current downloadable scummvm core (Android build) crashes the app entirely.
  • When you use an older version of the core, the core starts up and works perfectly - but none of the settings of ScummVM itself (I’m talking about data stored in the scummvm.ini) get stored. Rendering this entirely useless again - because ScummVM is a very setup intensive core. When it doesnt even remember the games you have imported into Scumm VM this again becomes a 5 minute process - every time you want to launch a game (import game, set savepath, set game settings…)

It is possible though - to install an older version of Retroarch, with the old version of the Scumm VM core integrated into the package - then launch Retroarch once - immediately start Retroachs “second menu level” by highlighting the first menu item (“start Retroarch” or something along those lines) and confirming (the old Android Versions differentiated between a first menu level (“App look”) and a second menu level (“Text only”)). From there selecting load core, loading the prepackaged ScummVM core.

If you are lucky - the insane mouse speed for the stick emulation doesnt trigger. (This by the way is the ONLY time and the only way you have a chance of it not triggering. Usually - if you dont start the core from the first menu level the core crashes within seconds, and if you start it from the first menu level it has the mouse speed problem. But for some reason - on the first start, and if you dont select a game with it the core does not crash Retroarch if you start it from the second menu level.)

edit: If it crashes for you at that point - reload and try again by using the “load game, detect core” option in the second Retroarch Menu level. Once you have the Scummvm Interface laoded and Retroarch doesnt crash immediately - you are through the rough part. :slight_smile:

Once in Scummvm and without insane mouse speed, setup the save path in the ScummVM options (to somewhere on your Android sdcard partition). Then select ok. Then quit ScummVM via its menue. Then quit Retroarchs second menu layer, then quit Retroarchs first menu layer. Each time by selecting the corresponding menu options. This is necessary to get Scummvm to save its settings.

Because older versions of Retroarch dont have a problem with setting up the ScummVM cores “save structure” (scummvm.ini stuff).

Once you have done this - you install the Retroarch 1.3.0 apk (again, prepackaged with the older version of the ScummVm core, because the current one just crashes) over the previous installation.

To do this both apk packages have to have been signed “the same way” (after being packaged with the older version of the ScummVM core). I used the Android app “Zip Signer” to do that. The official 1.3.0 apk is signed with a different key and therefore wont install “over” a package you had to sign yourself.

Once Retroarch 1.3.0 successfully installs over the previous installation - you launch it again.

The “setting up for the first time” screen has a few graphical glitches (always displaying 2% complete) - but just give it 30 seconds, it does its job, and then (still with 2% displaying), launch the ScummVM Core once more.

This time you can import the first game you want to play, launch it - play it for a bit, then exit Scummvm (the Android Back Button is mapped to the Scummvm In Game menu), then exit Retroarch - again through the corresponding menu items.

On the next launch of Retroarch - Retroarch itself will behave entirely like it should - the ScummVM Core (I am using an archived version that shows version number 1.8.0 git) will still be launchable, mouse speed in the ScummVm menu will be normal, and the ScummVM setting (even new ones you make) will finally stick.

So essentially you are golden, and can move to finish setting up Retroarch (use force 3:2 or 16:10 edit: or 19:12 :slight_smile: aspect ratio for early Lucas Arts games for example - see: http://www.gamasutra.com/blogs/FelipePepe/20150423/241730/No_MSDOS_games_werent_widescreen_Tips_on_correcting_aspect_ratio.php ).

If there is interest, and I have the confirmation from a mod in here that I can do so - I can upload both Retroarch packages I have used (older version of the ScummVM Core prepackaged) for this process and link them in here - which makes finally getting ScummVM to work on Android devices with proper Gamepad Support a pretty painless process. But then again - I will do this only if I get the go ahead from the project management.

This is a working workarround - until the devs get along to fixing all those issues themselves.

(For 1.3.0 they are: Current ScummVM Core for Android crashes the app and older versions of the ScummVM Core dont get set up properly (scummvm.ini file (location?)). Game Pad Mouse Emulation Speed is fixed already.)

edit: Here are the two .apks (already signed) you need for this to work:

Follow the steps mentioned above exactly to end up with the intended end result. :slight_smile:

#2

Proof of concept:

[Album] Imgur

(Ingame menu images show strange artefacting - this got introduced through the adb screen capturing process, on screen they look exactly like they should. :slight_smile: )

#3

Thanks for the tut.

#4

I’m all for fixing this but honestly, the attitude you showed towards me and fellow co-developers was nothing short of horrible. Instead of responding to the negativity I just ignored it since it is better for my stress levels honestly.

I invite everybody to go look at how you approached us here -

and here -

So by all means, point out issues. But don’t go acting like you are the victim or anything or that you got ‘wronged’ when it was actually the other way around.

That I am even willing to fix these bugs now that RA development is slowly winding down again instead of just leaving them like this just purely out of spite must tell you I can’t be that bad of a guy.Honestly, fix your attitude. This isn’t the way you go about reaching out to a project. We don’t work for you. You are not our boss. There are tenthousand different ways you could have gotten your message across which would have been far more effective.

#5

That’s certainly an inconvenient issue. You’re welcome to post your modified apk in the meantime until we can get the issue resolved.

#6

I’ve uploaded the files and edited them into the opening post.

Regarding the atitude issue.

ScummVMs own Android port has controller issues to this day > devs commented that they would implement a fix, once Retroarch had fixed it independently from them.

Retroarch innitially ignored the issue for a few weeks after it had been reported and then closed it down, when it was still posted as a ticket for Retroarch, because it would be an issue with the Core (turned out it wasnt, the core was just fine) > suggesting to me that I should reopen it again in another libretro tracker sub category - where it never was picked up again.

The “correct subcategory” was one that had 2 tickets, including mine at that time - totally - and never gets visited or worked on.

I subsequently went apex mad person in addressing the project maintainers and the way they were managing their project.

But spilled milk at this point - it has never been easier for you to get this core finally working in Retroarch - on Android - with controller support. And thats a good thing.

#7

Oh, and I looked into the aspect ratio of “Indiana Jones and the Fate of Atlantis” again -

Some in game assets are clearly designed for an Aspect ratio of 4:3 (=1,33), such as this gorgeous face - :slight_smile:

bQBdLY9.png949×685

But then the ingame cursor and the font certainly is not - and also some backgrounds appear condensed.

The cursor is designed for 16:10 (= 1.6), but that makes characters noticeably a bit too “widescreen”.

I played around with a few alternatives and found 1,4 to be a good compromize.

In terms of Retroarch Settings at 1080p its the following configuration:

Aspect Ratio Index: Custom Custom Viewport X: 204 Custom Viewport Y: 0 Custom Viewport Width: 1512 Custom Viewport Height: 1080

It especially works quite well with the games font imho. if you don’t mind not sticking to 4:3 - give it a try. :slight_smile:

#8

What hardware are you running the ScummVM core on, Harlekin? Which controller and which Android device? I haven’t experienced the sensitive controller problem in the menus that you are describing in the versions that date at least a year back on the devices I’ve been using (Shield units and Huawei and HTC phones), so I’d be interested to know what hardware you are experiencing this on. Are you experiencing the fast mouse movements both with the analog stick and the DPAD on your controller? The DPAD should be quite slow compared to the Analog stick accelerated modes.

This is how it should be (and has been for me the last year):

The crashes you are experiencing with the ScummVM core for 1.3 might be caused by your Android unit not having Zlib and/or Vorbis. Which version of Android are you running Retroarch on? Please try the latest nightly build and test if you still get crashes.

About the loss of saved settings: Scummvm.ini is saved in the directory you have configured as the “System/BIOS” directory in Retroarch. What directory do you have it set to on your Android unit, and have you verified that you have write access to this folder?

About the aspect ratio: All Scumm games from the 80’s and 90’s were developed for 4:3 monitors, so you need to set this aspect ratio in Retroarch to make it look correct. What do you mean by the font and backgrounds appearing condensed?

This is how the fonts, cursor and game looks for me in 4:3. This is also how the games looked like back when they were released:

Could you please point out the parts you say are condensed?

#9

Games are displayed like they should be. “Condensed” is just me nitpicking over minor details in the art of Fate of Atlantis in this case. :slight_smile: (Pearl in the intro scene of FOA for example, also the first scene the game drops you in (in front of the theatre) - tire on the back of the car, font on top of the main entrance - an aspect ratio of 1,4 to 1,44 imho is more fitting than 1,33 (which is recommended, and also the ScummVm default “canon”) - but this is entirely separate from Retroarch. Retroarchs defaults are correct. Even better than that - its the first time I have this granularity in aspect ratio settings that are actually possible in a ScummVM game - to obsess about. :slight_smile:

I am using the method described above on a Fire TV Stick (1st generation) with an official Fire TV Controller (first generation as well) - to which I provided the controller mappings myself as well - around 8 months ago. Back then, the Stick/Mouse emulation speed problem was present as well (it also was the last time I tested it before today) – BUT it always was only an issue in the ScummVM menu, NOT in games. So its hard to think of it as a compatibility problem or a hardware issue.

Back then it struck me to probably be an issue with scaling maybe - probably the ScummVM menu being drawn in 1080p and mouse speed emulation being optimized for 240p. Or something along those lines.

Regardless - the problem is gone with 1.3.0 - and f.e. mouse sensitivity (on an analog stick) in game is just about perfect for me - much more so than with the official ScummVM port -f.e.

Regarding the zlib or vorbis compatibilities - give me a few minutes and I post a screencap of the information menu.

Performance on the Fire TV Stick is great by the way.

dottcd, and bass run full speed without a hitch and in the next five minutes I can test Broken Sword 1 as well. :slight_smile:

edit: monkey2 is unplayable as of now afaik, as the Core has no option to enable ScummVMs Software keyboard - and has no numbers mapped to the controller - so you cant bypass the “copy protection” screen. At least on the older core I am using.

edit2: Broken Sword 1 just gave me an error Message that DXA cutscenes arent available, because the core I am using was build without zlib support. Performence on Broken Sword 1 shows some very, very minor sound stutters that could be performance related. So thats where the Fire TV Stick finally capitulates. :slight_smile:

edit3: Just went to the Retroarchs Informations screen and it shows, that the Fire TV stick has zlib support. Vorbis is not listed by Retroarch at all

Those are the capabilities shown for the FIre TV Stick:

Build date Jan 17 2016 (Thats for RetraArch) Compiler: GCC (4.8.0) 32-bit Internal SD card status: read-write CPU Features: Port #0 device name: Amazon Fire Controller (#1) Port #0 device VID/PID: 0/0 Frontend identifier: android Frontend name: AFTM Frontend OS: Android 4.2 RetroRating level: -1 Power Source: N/A (its wired, just fyi :wink: ) Video context driver: android Display metric DPI: 320.00 (eh how would it be able to tell… :wink: ) LibretroDB support: Yes Overlay support: Yes Command interface support: No Network Command interface support: No Network gamepad support: No (might be patched in with the next FW, Amazons Gamecontroller (first gen) is bluetooth though) Cocoa support: No PNG support (RPNG): Yes SDL1.2 support: No SDL2 support:No OpenGL support: Yes OpenGL ES support: Yes Threading support: Yes KMS/EGL support: No Udev support: No OpenVG Support: No EGL support: Yes X11 support: No Waylanf support: No XVideo support: No ALSA support: No OSS support: No OpenAL support: No OpenSL support: Yes RSound support: Yes RoarAudio support: No JACK support: No PulseAudio support: No Direct Sound support: No YAudio2 support: No Zlib support: Yes 7zip support: Yes Dynamic library support: Yes Cg support: No GLSL support: Yes HLSL support: No libxml2 XML parsing support: No SDL image support: No OpenGL/Direct3D render-to-texture (multi-pass shaders) support: Yes FFmpeg support: No CoreText support: No FreeType support: No Netplay (peer-to-peer) support: Yes Python (script support in shaders) support: No VIdeo4Linux2 support: No Libusb support: No

edit: Just found out that what I described as “perfect muse emulation speed on the analog stick” comes from User 1 Analog to Digital Type being set to Left Analog, which probably doubles mouse speed (because - logic). If this is disabled, mouse speed right now on this core is much slower and much less preferable.

So things to implement in the future (if devs are reading along):

  1. Scummvm Virtual Keyboard support
  2. User accessable sensitivity setting for the mouse emulation speed

And if they already are in the most recent core - figure out what makes it crash for some people out there (fragmentation of devices in the Android ecosystem is a tough problem).

#10

Adb shell commands to input numbers work in the monkey2 copy protection screen. :slight_smile: Jup. Thought of that. :slight_smile: (in fact I wrote a script a while back that remaps my entire keyboard to send out the adb shell commands, came in handy today… :wink: )

adb shell input keyevent 8

inputs a 1 for example - and thats all thats needed (For monkey2. Indy3 needs more number keys for the fighting mini game afair).

Also - my bluetooth controller quite frequently disconnects - and when it reconnects (yellow text in Retroarch) it still is unusable in Retroarch. Switching to the launcher and then back to Retroarch again solves the problem. And Retroarch doesnt even relaunch - the in game state is still present. But it needs this “kick” to reinitialize the Controller. Should be fixed as well. If possible. (Currently its a minor inconvenience.)

#11

Could you try the latest nightly build of the ScummVM core and see if you still experience crashes?

Also, physical keyboard support (in game) has recently been implemented in the Android version of Retroarch, so if you can connect a keyboard to your Android device somehow - then you should be able to get by the copy protection screen of Monkey Island 2…or you can use the Fm-towns version of Monkey Island 2, which does not have the copy protection screen.

#12

Most recent core still crashes Retroarch for me. (zip date: 22. 01. 16 07:13)

Here is the behavior.

When I load the old version of the core (Load core) it launches instantly. All new versions of the core dont. They just bring me back to the main menu - and the bracket in the title “row” of Retroarch, where it usually shows the core currently selected stays empty ( “()” ).

When I launch an .exe (Load Content / Select File and detect core) on the old core it still brings up the ScummVM menu (so that function works) - on the new cores, it crashes Retroarch entirely (back to the launcher).

I havent found a way to access logs yet, so I could provide you with one (Fire TV Stick is unrootable, and I dont even have read access to the /data/data/ top folder - so if the log gets created there…). If there is a way to provide you with one - I’d be happy to.

Regarding controller mappings, I remember that the Xbox v1 build of ScummVM pretty much had perfect controller mappings (with number keys being maped to the digipad afair.) as I have resurrected my Xbox v1 to move over ScummVM saves - I’ll take a look if I still have a readme at hand that lays out the Controller mappings.

On the current Scummvm Cores they are pretty “sparse”… :wink:

edit: Finding the old Controller mappings went faster than I thought - because the internet remmbers everything… :wink:

Controls~~~~~~~~

LEFT ANALOG/DPAD         move cursor
A/LTRIGGER               LEFT MOUSE CLICK
X/RTRIGGER               RIGHT MOUSE CLICK
Y                        ESC (skip cutscene's, close dialogs)
B                        . (period) (skip subtitles)
WHITE BUTTON             F5 (save dialog)
BLACK BUTTON/START       PAUSE GAME


HOLD LTRIGGER+DPAD       DPAD will act as keypad to type numbers.
                         Handy for MI2 protection and indy3 fighting.


LTRIGGER+RTRIGGER+BACK   restart ScummVMx (back to launcher)
LTRIGGER+RTRIGGER+START  exit ScummVMx (back to dashboard)


LTRIGGER+RTRIGGER+WHITE     switch to previous gfx_mode (= filters)
LTRIGGER+RTRIGGER+BLACK     switch to next gfx_mode (= filters)


LTRIGGER+RTRIGGER+RTHUMB Calibrate the screen
LTHUMB                   Take PNG screenshot, saved in "screenshots" dir

White/Black nowadays can be mapped to L1/R1 (Xbox v1 only had triggers, no bumpers).

edit: Dpad number layout was

123 4 6 789

with 5 missing - if I remember correctly.

#13

Ok, I need you to test some things in order to zero in on the crash problem.

Please update the “core_updater_buildbot_url” in your retroarch.cfg to this: core_updater_buildbot_url = “http://www.lindqvist.it/scummvm/”

Then go into Core Updater and download the different ScummVM versions I’ve made available there. Please test each version and let me know which ones that don’t crash for you (if any).

#14

None of them even load as a Core (in the Title bar “(No Core)” is all I get). Now - with the old “New Core” I could force it to attempt a load and crash, by replacing the Core directory and having the core file sporting the same filename as some of my “recently loaded” games already expected.

This is FAR more complicated than it should be - because, Retroarch on Android chooses to still store cores in the data/data subfolder - so as a non root user once a core is in there you are sticking with it - short of clearing all program data (which for me in this case means, going through the whole install process again) – and of course - why should Retroarch sport a “delete core” function? At all. Also why should Retroarch store anything other then its config file on a user accessible partition on Android?

And how about moving the scummvm.ini location to userland, while we are at it? It would prevent me from having to go through this whole entire process - again - after I am done testing…

Also - when RetroArch fails to detect a core when a recent game tries to launch it simply defaults the corepath. Fun stuff. Setting it up again each time to one that is accessible (in userland) on the sdcard partition.

So while I work around those oversights (copying files over WLAN takes time) - I decided to write this text in the meantime… Useful information should begin right around the next paragraph or so.

So - as expected (because none of the cores load into the ScummVM menu on “Load Core” (but instead they exit to the main menu with (“No Core”) being displayed in Retroarchs header) - also all three of them crash Retroarch (blackscreen, then back to the launcher), once i rename them (one at a time) to the default core name, change the core directory, and force a launch via “recent games”.

The old core still works though. It even loads into the ScummVM Interface directly after “Load Core”.

So I’m afraid, the cause of the problem lies elsewhere.

Now back to reinstalling both RetroArch Versions, and all the Cores I am using, because I now have 30MB of unneeded testcores in my data/data partition, that cant be deleted any other way. Also - there is no log feature that outputs a log file to anywhere in userland on an Android device I recon?

To end on a more positive note - I like the new interface. And I will look into this thread more frequently from now on if you need further testing on my part.

edit: Reinstalling everything took 3 minutes and really wasnt that bad. Save your retroarch.cfg file though. :wink:

#15

Installed Retroarch on a random 4.1.1 tablet I had laying around. Same problem. So its not an isolated issue that only occurs on the Fire TV Sick.

#16

Ok, that’s sort of good news for me, because it means that the crashes you’re experiencing are not related to the recent adding of Vorbis and Zlib support. The root cause must be something buried deeper in the build system or similar.

As I posted earlier in the thread, the scummvm.ini file is placed in the directory you define as the “System / Bios” directory in your settings. On Android you really should set this to a folder you’ve created yourself as this leaves the system folder untouched (and your scummvm.ini file) when you uninstall the app.

#17

Thank you for you (re)mentioning where the scummvm.ini is located and that it can be relocated.

Regarding the overall issue - we then say it might be Android 4.x.x related and wait until it “grows away” through the gradual adoption shift? :wink: Or might it be the 1.3.0 final release?

Oh - and by the way - tough thing to ask for me at this point, because I actually wont be profiting from it for quite some time - but could you port a SVN of ScummVM some time in the future - not regularly - or to be supported - but the amount of games ScummVMs SVNs unofficially support has become quite staggering - and therefore quite interesting.

Not sure if this is possible or even an easy affair - but as a one off thing - maybe worth compiling. :slight_smile:

And thank you for your work on the project - allthough Retroarch is a clusterfudge of all kinds of different concepts and elements - when it gets some of them right, its a damn near homerun.:slight_smile: Configurability, filters, gamepad support, the amount of cores… If only the devs would focus away from solutions that are aimed at taking over a Raspberry Pi entirely - because its not what people in the future will focus on buying. (Selfmade home automation isnt the growth market you are looking for… :wink: )

Microsoft lost an entire multi year wager on getting devices under peoples televisions, and now that they are here - Retroarch much rather would ignore them than think about making them a lead plattform. Thats life I guess. And social commentary. Two in one! Cant go wrong with that… :wink:

#18

I just set up and Amazon Fire TV 2 running their Fire OS 5.0.5 which is based on Android 5.1 and the current version of the Scumm VM core installs and runs on it without any problem.

So I can isolate the crash this tutorial is meant to circumvent to be either only a problem on Fire OS 3 (based on Android 4.2) - or Android 4.2 in general, or the Fire TV Stick. :slight_smile:

#19

Clean install of the most current ScummVM core on Android 5.1 shows the same issue of not being able to store ScummVM settings (the scummvm.ini). I replicated this on Android 4 (older core) and Android 5 by now. It worked flawlessly on Android 5 - once I copied over retroarchs .cfg files from an old config.

In short: ScummVM on a clean Retroarch install on Android (Amazon Fire devices sigh) has a problem with creating the scummvm.ini in the default state - that might be overlooked by people copying over older .cfg files. I could reproduce it, maybe the maintainers can as well.

The workaround still works though.