#6108 WII: Zak FM-TOWNS mouse cursor encased in blue box

Graphics (902)

ScummVM ver: 1.5.0 and latest nightly build
Game ver: FM-TOWNS English
Platform: Wii

The mouse cursor for the game is encased in a blue box! Makes it difficult to see where you're clicking.


  • digitall

    digitall - 2012-07-29

    Assigning to Wii porter for visibility.

  • digitall

    digitall - 2012-07-29
    • assigned_to: nobody --> dhewg
  • digitall

    digitall - 2012-07-29

    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?

  • Comment has been marked as spam. 

    You can see all pending comments posted by this user  here

    Anonymous - 2012-07-29

    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.

    Last edit: Anonymous 2014-07-11
  • Comment has been marked as spam. 

    You can see all pending comments posted by this user  here

    Anonymous - 2012-09-04

    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

    Last edit: Anonymous 2013-12-13
  • CheatFreak47

    CheatFreak47 - 2012-09-24

    Also occurrs in Blues Clues Art Time now.

  • Comment has been marked as spam. 

    You can see all pending comments posted by this user  here

    Anonymous - 2012-12-08

    Also occurs in Android (4.2.1) version of ScummVM (1.5.0) when playing Loom FMTOWNS on a Nexus 7.

    Last edit: Anonymous 2015-11-29
  • slx

    slx - 2013-04-23

    I have the same problem with the FM Towns versions of Zak McKracken on Samsung Galaxy S3.

  • exitido

    exitido - 2014-01-01

    Same problem with:
    Indiana last crusade FM-TOWNS and NEXUS 10, we need a fix :´(

  • Eingang

    Eingang - 2014-01-29

    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!

  • digitall

    digitall - 2014-03-20

    @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

  • digitall

    digitall - 2014-03-21

    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...

  • digitall

    digitall - 2014-03-21

    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..

    1. 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.

    2. 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

    3. 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:

    1. 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.

    2. 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).

    3. 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.

  • digitall

    digitall - 2014-03-21

    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.

  • digitall

    digitall - 2014-03-21

    Screenshot as indicated...

  • Johannes Schickel

    • status: open --> pending-fixed
    • assigned_to: Andre Heider --> Johannes Schickel
  • Johannes Schickel

    Should be fixed with 4ca33e264802ec4c679c8b129ca461bb1e9c7f8d in master.

  • digitall

    digitall - 2014-04-23
    • status: pending-fixed --> closed-fixed

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks