ANDROID: Nexus 7 2012 graphics glitch with Larry 6

[ebbi2017]

Hallo,

I saw a graphics bug w/ Larry 6 CD version, both lo-res and hi-res on a specific Android tablet in ScummVM 2.9.0 and older new versions as well as both daily apk.
Asus/Google Nexus 7 2012 (grouper), LOS 14.1 Android 7.1.2.
ScummVM 2.5.1 and 2.0.0 don't have this bug on the same device.

I started a new game of Larry 6 and made two screenshots of hi-res and lo-res version showing the same bug.
The Sierra Logo is fine. Clicking mouse to skip intro (which also is glitched), then play button and the very 1st screen (and all others) have some yellow/green pixels here and there.
It looks like a color palette issue or sth. like this and happens on all screens while playing.
Not even loading a savestate.

Any other Android device I have don't show this bug in the same game and ScummVM 2.9.0 stable.
Samsung S2 from 2011 works fine, S3 from 2012 works fine as well as newer 32 and 64 bit devices.

Nexus 7 2012:

Both daily apk glitch
2.9.0 glitch
2.8.1 glitch
2.8.0 crashes completely
2.7.1 crashes completely
2.7.0 crashes completely
2.6.1 glitch
2.6.0 glitch
2.5.1 works
(in between versions not tested)
2.0.0 works

Sierra Logo looks fine.
Intro and any screens are glitched (palette / pixel issues).
Leisure Suit Larry 6: Shape Up or Slip Out! (Hi-res/DOS/English).
Android 7.1.2 (LineageOS 14.1-20210704-unofficial-grouper).
Asus/Google Nexus 7 2012 grouper.

kind regards, Sebastian

[sluicebox]

Attached a normal screenshot of LSL6-HIRES for reference, from 2.9.0 Windows

[antoniou79]

Hello,

Are you aware of any other games that display similar graphical glitches on ScummVM for this device, or is it only LSL6 (as far as you have tested)?

Would it be possible to attach for us some additional info?

• Set the ScummVM debug level to 6 (from Global Options -> Misc -> Debug Level -> Apply) then launch the game, reach the first playable scene and exit. Then, share with us the scummvm.log file.
• Share with us the scummvm.ini file.

Please, test with a recent daily 2.10.0git (for your device I think you should go with the v7a architecture one ie. the "Android (ARM)", not the 64bit one) for the above. Just to clarify, the daily dev builds are under the first column labeled "ScummVM latest Branch master" on the ScummVM buildbot page (​https://buildbot.scummvm.org/#/dailybuilds).

I think the most reliable way to remotely access these files (scummvm.log and scummvm.ini) on your smartphone and download them to your PC is to set up the ScummVM LAN, and set the "/root/ Path" folder to be the "ScummVM data (Internal)" folder. Let me know if you need more help on how to do this.
​https://docs.scummvm.org/en/latest/use_scummvm/LAN.html

[ebbi2017]

Hallo,

Thx for the reply.
I've tried the latest git version, still the same glitch on the Nexus 7 2012 grouper device.

Next I tried different games, same glitch with Indy4CD; Indy 4 Amiga and Goblins Quest 3 Floppy DOS.
Some pixels have wrong colors there, too.
It's not a Larry 6 related glitch, but Nexus 7 2012 related or Tegra 3 GPU related one.
I didn't see the glitch in Indy4cd when I tested it earlier, the amount of wrong pixels are much less than in Larry 6 CD.

In the log file it reads "TAINTED Vorbis FLAC MP3 RGB zLib MPEG2 FluidLite EAS MikMod Theora VPX AAC A/52 FreeType2 FriBiDi JPEG PNG GIF cloud (servers, local) ENet TinyGL OpenGL (with shaders) OpenGL ES 2 only".

It works on the Samsung S2 i9100 (2011) w/ Mali-400 MP4 GPU (also LineageOS 14.1 Android 7.1.2) and all my other non Nexus 7 2012 devices. Tho both devices use OpenGL ES 2.0 on paper.

ScummVM 2.5.1 was the latest version which didn't have this glitch on the Nexus 7 2012 grouper.
In this version it looks like the screenshot which user sluicebox added.

[lephilousophe]

I have issued a PR which may fix it (or not...).
This is ​PR 6559.

I will try to create a test build for you in the next days.

[lephilousophe]

Here is a ​build (which can be installed alongside the other ones) with SCI32 only.

SHA256 of the file: ecee08837dd6c1a57ca25f164181175b728d576455f2e45a93e07c734ed631ae

Could you test it and tell us if it works better?

Thank you.

[Le Philousophe <lephilousophe@…>]

In 3112fad5:

BACKENDS: OPENGL: Fix CLUT shader lookup

This should fix Trac#15860.

The current code only uses a linear scaling to look at the palette
texture.
This means that lookup coordinate is on the form (when stretched to
texture size):
0.0, 1.00196, 2.00392 ... 253.49607, 254.49803, 255.5

With the newer code it will be on the form:
0.5, 1.5, 2.5, ... 253.5, 254.5, 255.5

[ebbi2017]

Thx for the test build.

It nearly fixed it, looks much better now.
Not yet perfect, tho.

lores_test_build.png
hires_test_build.png

Replying to lephilousophe:

Here is a ​build (which can be installed alongside the other ones) with SCI32 only.

SHA256 of the file: ecee08837dd6c1a57ca25f164181175b728d576455f2e45a93e07c734ed631ae

Could you test it and tell us if it works better?

Thank you.

[Le Philousophe <lephilousophe@…>]

In 84a31481:

BACKENDS: OPENGL: Improve precision of CLUT lookup

This is a followup of 3112fad5fa9d9676e18a894494f05bf20957d51a and tries
to definitely fix Trac#15860.

Use a medium precision when looking up the pixel palette index.
Using a low precision (the default) may loose precision on normalized
values.

[lephilousophe]

Thank you for the test.
I have tried to look at it again and issued another fix.
It seems that Tegra hasn't much of precision for low precision values.

Could you test tomorrow evening (UTC) with the daily build available at ​https://buildbot.scummvm.org/#/dailybuilds

Thank you.

[ebbi2017]

Tested with Android (ARM) 454e8af1 (29.04.2025)

Same result as last time.

Replying to lephilousophe:

Thank you for the test.
I have tried to look at it again and issued another fix.
It seems that Tegra hasn't much of precision for low precision values.

Could you test tomorrow evening (UTC) with the daily build available at ​https://buildbot.scummvm.org/#/dailybuilds

Thank you.

[lephilousophe]

Thank you for the test.

To sum it up, the main difference between 2.5.x and now is that we switch from OpenGL ES 1.1 to OpenGL ES 2.0.
This change brought a new GPU accelerated way to render the 256-color games like LSL6.

After looking at it more, it seems that the Tegra GPU can't work properly with this accelerated rendering as It doesn't provide enough precision when accessing the textures.

I see no other option than disabling this acceleration of such platforms.
It's a shame as it seems that only one color was wrong.

Could you test this ​new build which should switch you back on CPU based rendering for the image?
I don't expect a measurable performance drawback.

[ebbi2017]

Thx for the new testbuild. It crashes sadly.

I also tried this new one, 2.5.1 and 2.9.0 w/ Android developer options and forced GPU rendering on and off on each of those, but there's no difference whether switching forced GPU on or off.

Setting "Updates with GPU" (Flash screen when GPU is being used) shows that there's no GPU being used in ScummVM on the Nexus 7 2012. Looks like it's always rendering in software.
Only when clicking the 3 stripes top right, the mouse icon left of that one has this flash overlay showing it's rendering with GPU when using this in Android developer options.
All other content in ScummVM is CPU rendered it seems. I didn't even set CPU rendering in the options. I don't understand it.
When I switch to other apps like Total Commander the screen flashes way more often showing it's GPU rendering when using this developer option setting.

On my Samsung Note 3 (where the games look fine), f.e., ScummVM 2.9.0 and developer option to show GPU being used shows a flashing screen in ScummVM. When I set software rendering in ScummVM on this device, it keeps flashing the screen (GPU rendering). I don't get it.

These are the specs for Tegra 3:
​https://www.nvidia.com/de-de/drivers/tegra-3/

OpenGL ES 2.0
OpenVG 1.1
EGL 1.4

Further I found on wikipedia:
​https://en.wikipedia.org/wiki/Nexus_7_(2012)

"The Tegra 3 processor, besides the four primary cores, features "Variable Symmetric Multiprocessing" that uses a fifth "stealth" core designed to take over during periods of low processor demand, helping to preserve battery life."

The Nexus 7 2012 uses the Tegra 3 T30L variant (1 out of 5 different Tegra 3 variants).
​https://en.wikipedia.org/wiki/Tegra#Tegra_3

So those T30L and maybe other Tegra 3 devices should show pretty the same results I guess.
I don't have any of those, only the Nexus 7 2012 16 GB and another one with 32 GB, which shows the same result.

"T30L Asus Transformer Pad TF300T, Microsoft Surface, Nexus 7 (2012),[43] Sony Xperia Tablet S, Acer Iconia Tab A210, Toshiba AT300 (Excite 10),[44][unreliable source?] BLU Quattro 4.5,[45] Coolpad 9070"

Could we somehow force OpenGL ES 1.1 for those older ARMHF devices or is it too much code for newer ScummVM versions going back to old standards?

Replying to lephilousophe:

Thank you for the test.

To sum it up, the main difference between 2.5.x and now is that we switch from OpenGL ES 1.1 to OpenGL ES 2.0.
This change brought a new GPU accelerated way to render the 256-color games like LSL6.

After looking at it more, it seems that the Tegra GPU can't work properly with this accelerated rendering as It doesn't provide enough precision when accessing the textures.

I see no other option than disabling this acceleration of such platforms.
It's a shame as it seems that only one color was wrong.

Could you test this ​new build which should switch you back on CPU based rendering for the image?
I don't expect a measurable performance drawback.

[lephilousophe]

Thank you for testing.
I am completely puzzled about why it would crash.
I have double checked and it should not.
EDIT: I reproduced the bug.

Did you already use ​adb? If so, it would be a great help if you could capture the ScummVM, DEBUG and AndroidRuntime tags.
That is, you can run:

adb logcat -c
adb logcat ScummVM:* DEBUG:* AndroidRuntime:* *:S

I hope this can bring us better explanations about why it crashes.

If you are not comfortable putting this log here, you can send it to me on Discord instead.

About your other tests:

• The "updates with GPU" setting you enabled is only relevant for the Android GUI (which is used to display the overlay icons). The ScummVM screen rendering bypasses all of this and that's expected.

Using GLES2 means you are using GPU for rendering on screen.

• If you get different results on Galaxy Note 3, it's because they must have hooked differently the flashing and you get our updates.
• The software rendering setting is also specific to Android UI, which we are using only for the overlay (the icons in the corner).

About switching back to OpenGL ES 1.1, it's something too complex because it means supporting both versions and switch dynamically.
There is not much Android devices not supporting OpenGL ES 2 and your tablet does support it.

[lephilousophe]

Indeed, I didn't test my build correctly: sorry about that.
Here is a new ​test build

[ebbi2017]

Thx for the new test build.

Yes, it's running perfect now, looks like on PC.
Thx very much!!!

Attaching normal log+ini files, maybe it's giving some more hints.

I used adb and fastboot to flash LOS, but haven't tried logcat yet.
Do you use it via USB+PC or directly on Android?
I read there's also logcat reader apps on Android.
I have full root access on this device.

Thx again!
Passe un bon week-end!

Replying to lephilousophe:

Indeed, I didn't test my build correctly: sorry about that.
Here is a new ​test build

[lephilousophe]

I'm glad it works! Thanks for your patience.

This goes to master branch immediately.
I have a fix for 2.9 which is a bit different to avoid taking much risks for other platforms but it should behave the same.

For adb logcat, I only use it from my PC.

[Le Philousophe <lephilousophe@…>]

In d8a6d8cf:

BACKENDS: OPENGL: Don't use HW CLUT8 lookup on low precision devices

This also reverts commit 84a31481fa70b56140ca5e62edf9cb287a7d3e7b.
This will hopefully fix Trac#15860 for good.
I also hope that nothing else will get broken because of this.

[Le Philousophe <lephilousophe@…>]

In 587eb1f0:

BACKENDS: OPENGL: Don't use HW CLUT8 lookup on low precision devices

This will hopefully fix Trac#15860 for good.
I also hope that nothing else will get broken because of this.

[lephilousophe]

The fix is now integrated and will be available in tomorrow daily build.

[ebbi2017]

Thx very much!!!

Android (ARM) 55c2973c now works w/o graphics glitches on the Nexus 7 2012 with all games I tested prior:
Goblins 3 (Floppy DOS), Indy 4 CD, Indy 4 Amiga, Larry 6 hi-res+lo-res.

Replying to lephilousophe:

The fix is now integrated and will be available in tomorrow daily build.