Mame bezels cause Android retroarch to crash (neither lay file nor zip can be choosen as the video layout path)

[mickael28]

Description

• Mame bezels cause Android retroarch to crash (neither lay file nor zip can be choosen as the video layout path)

Expected behavior

• MAME layout should be displayed on the screen in the Android version
• Note that this works fine on the PC version.

Actual behavior

• Retroach android crashes in both cases, when trying to use the MAME bezel from:
  • the .lay file
  • the .zip file

Steps to reproduce the bug

1. Have some MAME bezels ready in either .zip format or folders with the .lay file inside. eg, attaching some examples to help reproducing the problem: Mame bezels not working in Android Retroarch.zip

2. Unzip the MAME bezels in the example above in your Android phone and note the path

3. Launch any arcade game in Retroarch android and bring up the Quick Menu

4. Scroll down the options to 'Video Layout'

5. Click it an enable it

6. Now on 'Video Layout Path', navigate to the folder where you extracted the zip above and select the default.lay file

7. Retroarch android app crashes as soon as you do that.

8. I've tried with very many different .lay files, and with .zip files for the MAME bezels too, but it crashes every time.

9. I've tried as well with 4 different Android devices and reproducible in all of them.

Bisect Results

• First time I've tried this weekend and not working
• Didn't see any other bug mentioning it

Version/Commit

• RetroArch: Android Retroarch from 12 Sep 2021, 3 Nov 2021, 25 Jan 2022

Environment information

• OS: Android 10, 7, 6 and 5

Video of the issue

https://user-images.githubusercontent.com/7086650/151676186-f082c7f9-c473-4d13-a502-59c06f3a8e42.mp4

[mahoneyt944]

You are using fbneo, not mame. @barbudreadmon might be able to help you.

[mickael28]

You are using fbneo, not mame. @barbudreadmon might be able to help you.

Thanks. Yes, I don't think the emulator should matter for the Video Layout Path option. The same works fine on the PC version as the difference around this area seemed to be how MAME (without Retroarch) used those Bezels and .lay files and how they could be used with Retroarch (independently of the emulator which is launched).

[barbudreadmon]

You are using fbneo, not mame. @barbudreadmon might be able to help you.

Nope, that's clearly not a core issue, and i know nothing about bezels or android.

Out of curiosity, does it happen with horizontal games too ? It looks like this bezel stuff might be meant for mame, so i'm wondering if it even works properly with vertical content (as explained at https://github.com/libretro/mame/issues/261, mame has a bug where it renders everything as being horizontal content)

[mickael28]

I don't think this is an issue with neither MAME nor FBNeo. It seems more an issue with Retroarch-Android version (it works fine on the PC version).

This was implemented a while ago:

• https://forums.libretro.com/t/how-to-use-mame-layout-files-as-overlay/23123
• https://github.com/libretro/RetroArch/issues/7419

but doesn't seem to work on the RetroArch-Android version.

I've tried with the following and all of them cause the app to crash:

• Vertical game + FBNeo
• Vertical game + MAME current
• Vertical game + MAME 2003-plus
• Horizontal game + FBNeo
• Horizontal game + MAME current
• Horizontal game + MAME 2003-plus

None of them allows you to enable the 'Video Layout Path' and select any of the .lay files used with MAME Bezels in Android.

I'll mention it as well on that closed Bounty in case the guys know about this.

Thanks.

[hizzlekizzle]

to be clear: have you tested the layouts on RetroArch on a PC to verify they work okay there? It sounds like you might have, but I wanted to make sure because MAME changed their layouts spec recently (few months ago) in a backward-incompatible (AFAIK) way, and all of the main artwork repositories updated to the new format, which won't work in RetroArch.

[mickael28]

@hizzlekizzle, yes, on PC all working fine.

It's really really good. I was trying to migrate the setup to my Android tablet and phones and it just fails in all of them, causing the Retroarch Android app to crash as soon as one chooses the .lay file.

On PC you can enable and disable it with no problem with exactly the same files I've already got:

https://user-images.githubusercontent.com/7086650/152618151-0805830a-5333-425f-8532-94675577c998.mp4

[huwpascoe]

Hi, I wrote the code fulfilling the bounty https://github.com/libretro/RetroArch/issues/7419

@hizzlekizzle After googling all I've found is that view elements like <bezel> are deprecated. Is there a comprehensive changelog of the differences in layout files?

@mickael28 I don't have access to android debugging. I have an idea though, try replacing the images with colored rectangles and see if it works?

Android with GLES2 only guarantees texture sizes up to 1024x1024 (I think?) so three 2560x images probably aren't going to be accepted by hardware. Or maybe they will. Lets see.

[mickael28]

@mickael28 I don't have access to android debugging. I have an idea though, try replacing the images with colored rectangles and see if it works?

Android with GLES2 only guarantees texture sizes up to 1024x1024 (I think?) so three 2560x images probably aren't going to be accepted by hardware. Or maybe they will. Lets see.

@huwpascoe I'm not sure if I did correctly the changes you mentioned (attached here: Mame.bezels.rectangles1024.zip), I resized the original files with a maximum length or width of 1024, then edited the .lay file to have that as the maximum too:

<!-- Bezel.lay -->

<mamelayout version="2">
 <element name="Glass">
    <image file="../DefaultBezelH.png"/>
  </element>
 <element name="Bezel">
    <image file="Bezel.png"/>
  </element>
 <element name="Bez">
    <image file="Bez.png"/>
  </element>
  <view name="Bezel">
    <screen index="0">
       <bounds x="280" y="770" width="880" height="1024"/>
    </screen>
    <bezel element="Glass">
       <bounds x="260" y="740" width="920" height="1024"/>
    </bezel>
    <bezel element="Bez">
      <bounds x="0" y="750" width="1024" height="1024"/>
    </bezel>
    <bezel element="Bezel">
      <bounds x="0" y="0" width="1024" height="1024"/>
    </bezel>
  </view>

</mamelayout>

Trying then to select the default.lay file from the Video Layout options, the RetroArch app crashes with:

Unfortunately, RetroArch has stopped.

If that's not the test you mentioned, could you let me know which files I should use and/or what config to enter pls?

[hizzlekizzle]

I don't know of any documentation about the changes, but surely they're somewhere. I'll poke around and see if I can find anything.

[mickael28]

I mainly saw this at the time, which seemed to suggest that it might/should work but I didn't manage with any of the many combinations I tried (even though I was in that GL video driver):

https://www.patreon.com/posts/retroarch-1-8-0-31055086?l=de

[huwpascoe]

could you let me know which files I should use and/or what config to enter pls?

give this a go, there should be a red, green and blue bar across the screen.

<?xml version="1.0"?>
<mamelayout version="2">
	<element name="test">
		<rect>
			<bounds left="0" top="0" right="5" bottom="1" />
			<color red="1" green="0" blue="0" />
		</rect>
		<rect>
			<bounds left="5" top="0" right="10" bottom="1" />
			<color red="0" green="1" blue="0" />
		</rect>
		<rect>
			<bounds left="10" top="0" right="15" bottom="1" />
			<color red="0" green="0" blue="1" />
		</rect>
	</element>

	<view name="Test View">
		<screen index="0">
			<bounds left="0" top="2" right="10" bottom="4" />
		</screen>
		<bezel element="test">
			<bounds left="0" top="2" right="10" bottom="4" />
		</bezel>
	</view>
</mamelayout>

[hizzlekizzle]

@huwpascoe I was able to find this spec document but no changelog to easily identify the differences: https://docs.mamedev.org/techspecs/layout_files.html

FAKEDIT: this commit message seems to have some useful details: https://github.com/mamedev/mame/commit/67ec5e5b43738128a696aea19b299ee0ed8a17a0

[huwpascoe]

FAKEDIT: this commit message seems to have some useful details: mamedev/mame@67ec5e5

Thanks, that does help.

The MAME devs have been quite bad in how they handled this. It's in the spec, <mamelayout version="2">. They should've set it to 3, and that's an easy if-statement to handle the new format. But no, instead we have special behavior to parse both that'll be removed...soon?

[mickael28]

give this a go, there should be a red, green and blue bar across the screen.

Just noticed the example above, thanks for that. I saved it as a .lay file and tried with the latest 2 nightly Android APK builds compatible with my devices (retroarch and retroarch 32-bit)

Even with that simple file, the app just crashes straight away. I've managed to get a log when it crashes, let me attach it, it ends abruptly with:

[GL]: Unable to create FBO for video_layout.

retroarch__2022_09_13.log

[huwpascoe]

Okay that's about the most precise error message that could be hoped for!

FBO, (Frame Buffer Object), is the canvas where the layout is drawn to. The gl driver has changed a lot since this feature was added, that part of the code could need updating. I'll look into it (any GL driver maintainers also feel free to do so!)

[mickael28]

If at some point you want me to try with a specific nightly build (temp APK) and/or .lay config to help troubleshooting anything, just tag me and I can give it a go and report back with results or logs.

Thanks @huwpascoe

[mickael28]

Hiya @huwpascoe , I tried with the 3 latest nightly Android APKs (where it seems the PR was already merged):

• 2022-09-18-RetroArch.apk 2022-09-18 15:16 192.1 MB
• 2022-09-18-RetroArch_aarch64.apk 2022-09-18 15:17 181.6 MB
• 2022-09-18-RetroArch_ra32.apk 2022-09-18 15:17 181.5 MB

I didn't get the FBO error above but all 3 versions in 2 different devices crash at the same point when trying to load the .lay file (I tried with the example above and with the original for a game) and the end of the log is one of the following 2 sections (depending on device and/or APK used):

Sometimes ends with:

• [Environ]: SET_GEOMETRY: 320x240, Aspect: 0.750.log

Others with:

• [Environ]: SET_INPUT_DESCRIPTORS.log

The .lay files I tried were:

• Bezel-ddonpach.zip
• basic-layout-huwpascoe.lay.txt

Do you know what could be happening? or do you want me to try something else to report results?

[wn2000]

@huwpascoe First of all thanks for implementing the "video layout" feature. I've been trying to get it to work on my GLES2 board in the last few days and I did come up with some findings.

The first happens to be the GL constant bug that you've already fixed in #14418.

Then I started to have instant crash issue as seen by @mickael28 . With an ASAN build of RetroArch, I discovered that it is because I was using threaded video. As it turns out, even when I set my video driver to gl, the "threaded video" is using a different driver video_thread_wrapper that is supposed to wrap the gl driver's functionality in a threaded environment. But, that wrapper does not wrap the "video layout" feature (having a NULL in its place). Consequently, it's causing a segfault by trying to dereference a null pointer.

That was a major disappointment, but I still wanted to see it in action so I disabled the threaded video. This time, no more crash, but I got a black screen. I've seen a few other reports of the black screen issue, some of them even with a desktop GPU. After a lot of digging, I've finally found the fix to that issue, at least for my GLES2 board:

In gl2_video_layout_fbo_init():

   ...
   glGenTextures(1, &gl->video_layout_fbo_texture);
   glBindTexture(GL_TEXTURE_2D, gl->video_layout_fbo_texture);

   // Add these two lines
   glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
   glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);

After that, I've finally been able to see it working. But, without threaded video it is SLOW. Even game like Asteroids becomes unbearably slow on my board.

So, here is my request: Is it possible to enable video layout in the threaded gl video driver? I'll be happy to help test and debug anything you come up with. Many thanks in advance!

[huwpascoe]

@huwpascoe First of all thanks for implementing the "video layout" feature. I've been trying to get it to work on my GLES2 board in the last few days and I did come up with some findings.

The first happens to be the GL constant bug that you've already fixed in #14418.

Then I started to have instant crash issue as seen by @mickael28 . With an ASAN build of RetroArch, I discovered that it is because I was using threaded video. As it turns out, even when I set my video driver to gl, the "threaded video" is using a different driver video_thread_wrapper that is supposed to wrap the gl driver's functionality in a threaded environment. But, that wrapper does not wrap the "video layout" feature (having a NULL in its place). Consequently, it's causing a segfault by trying to dereference a null pointer.

That was a major disappointment, but I still wanted to see it in action so I disabled the threaded video. This time, no more crash, but I got a black screen. I've seen a few other reports of the black screen issue, some of them even with a desktop GPU. After a lot of digging, I've finally found the fix to that issue, at least for my GLES2 board:

In gl2_video_layout_fbo_init():

   ...
   glGenTextures(1, &gl->video_layout_fbo_texture);
   glBindTexture(GL_TEXTURE_2D, gl->video_layout_fbo_texture);

   // Add these two lines
   glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);
   glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);

After that, I've finally been able to see it working. But, without threaded video it is SLOW. Even game like Asteroids becomes unbearably slow on my board.

So, here is my request: Is it possible to enable video layout in the threaded gl video driver? I'll be happy to help test and debug anything you come up with. Many thanks in advance!

Wow, thanks for all that work! Thinking about texture parameters, wrap mode should probably be CLAMP_TO_EDGE as well.

I'll have a proper look at these drivers some time this week and try to figure out what needs to be done.

[wn2000]

@huwpascoe sounds good! Let me know if you want me test anything. Thanks!

[mickael28]

Same here @huwpascoe, let me know if you want me to test anything. Although I think @wn2000 can help a lot more than me by reading his comment above :)

Thanks for looking as well in your end wn2000