ScummVM ver: 1.5.0 and latest nightly build
Game ver: FM-TOWNS English
The mouse cursor for the game is encased in a blue box! Makes it difficult to see where you're clicking.
Assigning to Wii porter for visibility.
Abram: Thank you for the bug report. Please can you confirm the following:
1. Please confirm if this bug is present when playing Beneath a Steel Sky or Flight of the Amazon Queen?
Both these games are freely downloadable from our website and different engines from ZAK.
This is to confirm if this is an engine/game specific issue or occurs with all games on the Wii.
2. Please confirm if this bug was present in ealier versions of ScummVM on the Wii i.e. v1.4.1, 1.3.1 etc.
This helps us to work out if this is a recent regression and approximately when this issue was introduced.
dhewg: This sounds like an issue with the mouse overlay. Can you replicate?
I tested both of the games you requested and found that the mouse cursor in each is displaying normally. Might this be a bug with FM-TOWNS games? I didn't find 1.4.1 or 1.4.0 Wii builds here on SourceForge, but I tested the 1.3.1 build and saw that the mouse cursor has no blue box in that version.
You seem to have CSS turned off.
Please don't fill out this field.
LoI have the same problem with Monkey Island 1 (FMTOWNS) on the Android port (v1.5.0). The same game on my debian desktop works fine using scummvm 1.4.1.
Samr problem indiana jones ñast crusade fmtowns on android
Also occurrs in Blues Clues Art Time now.
Also occurs in Android (4.2.1) version of ScummVM (1.5.0) when playing Loom FMTOWNS on a Nexus 7.
I have the same problem with the FM Towns versions of Zak McKracken on Samsung Galaxy S3.
Same problem with:
Indiana last crusade FM-TOWNS and NEXUS 10, we need a fix :´(
Confirm the blue box bug (=BBB) in all FM- Towns Versions:
Monkey Island I + II, Indiana Jones III, Look, Zak
Device: Nexus 10
Stell Sky + Amazon Queen work perfectly.
Would be great to See it fixed... Thanks!
@exitido: You may need a fix, but we are not able to provide one unless we can track down the cause of the bug. For that, debugging information is needed...
I have tried replicating this with the latest master on x86_64 with Blues Art Activities with no success. I don't own any FM-Towns versions. They are very rare and expensive to buy and thus only a handful of the developers own copies and can look at this bug.
There has been some discussion on this today and I am posting the following notes at the request of fuzzie and LordHoto:
Well, the Android backend has a similar bug report:
Android's color key code seems a bit odd. lines 758 - 763 seems to set the alpha component based on whether the source color doesn't equal the key color. I would somehow expect that crossBlit does set the alpha bit when the source doesn't have any alpha channel.
And thus, that code should probably reset the alpha bit whenever the source color matches the key color.
The Wii code seems to carefully mimic that behavior, so that might be the cause.
What might be worth notice that, I think, SCUMM FM-Towns games might supply 16bit cursor data.
This is likely to be associated with the merging of the USE_RGB_COLOR (16-bit) truecolor for surfaces support merged between v1.4.1 and v1.5.0
Lordhoto said "that the OpenGL backend carefully does the inverse logic and that doesn't have any blue blox around the Loom FM-Towns cursor at least."
Unfortunately I don't think he has a Wii or Android phone to test with...
We would normally be able to use a demo to test this, but all the FM-TOWNS demos listed are non-interactive and thus have no cursors :/
Overall, this bug is a pain.
But to progress..
Can someone replicate this bug and take a screenshot or photo of the screen and attach it to this bug as a png or jpg file please? The exact color may give the developers a clue as to how the surface logic is failing.
Can someone with an Android device replicate the bug following the steps given here to get an Android Debug Log and see if there are any warnings, errors or other information messages associated with this problem: http://wiki.scummvm.org/index.php/Debugging_ScummVM#Android
Can someone test with the latest development v1.7.0git Android build from here and see if the problem is still occuring: http://buildbot.scummvm.org/builds.html
Instructions on installing daily builds are given here:
Can someone do the same i.e. 3, but for the Wii v1.7.0git nightly build and see if the problem is still occurring there.
If someone with a Wii, an FM-Towns game and good C++ skills could set up the compiler toolchain as per: http://wiki.scummvm.org/index.php/Compiling_ScummVM/Wii and then try building v1.4.1 and v1.5.0 and confirm that the error was introduced between these two revisions (as we only currently have it localised between v1.3.1 and v1.5.0).
If they could then try doing a Git bisection and test and locate the regression commit... or at least reduce the range to a much smaller range of commits.
AHA... Had a brainwave and found a likely solution, by reversing the debugging problem.
If I can't fix the Android/Wii backend code... I'll break the OpenGL one instead!!! :)
To prove if Lordhoto's theory that the cause is the Android/Wii colorKey handling in setMouseCursor() function of OSystem, I have transplanted the core logic of the colorkey handling from backends/platform/android/gfx.cpp lines 758 to 763 as indicated to the relevant code in backends/graphics/opengl/opengl-graphics.cpp.
The resulting code can be found in a branch of my github repo:
This should then provoke the same bug when using the OpenGL Graphics Mode when running Blue's Art Time Activities which I have a copy of, which it DOES!
I attach a screenshot to show the observed behaviour.
I have also asked Kirben who owns Zak FM-Towns to test with this and he has observed the Blue Box around the Cursor as described.
Hopefully, LordHoto can reverse my fix and apply the correct code from the OpenGL backend to the Android and Wii backend for testing.
Screenshot as indicated...
Should be fixed with 4ca33e264802ec4c679c8b129ca461bb1e9c7f8d in master.