Opened 2 weeks ago

Last modified 6 days ago

#13561 new defect

Sanitarium: Random audio glitch and savegame thumbnails flickering

Reported by: autistinenhomokissa Owned by:
Priority: normal Component: Engine: Asylum
Version: Keywords:
Cc: Game: Sanitarium


Chapter 2:

  • Crow sound randomly plays as distorted and at max volume while idling, going in or out of building, interacting with object or people
  • (Was able to recreate by repeatedly clicking tictactoe girl and spamming ESC)
  • Girl skipping rope humming sound start playing again on top first one before first one ends.

Chapter 6 and 8:

  • Rarely one of the background sound effect is randomly played very loud and distorted like crow in chapter 2.
  • (Happened during playthrought: four times in chapter 6 and twice in chapter 8 maze section, was not able to recreate)

Save game thumbnail flickers on slots 1-6, 13-18 etc.
Save slots 7-12, 19-24 etc. are shown normally.

ScummVM versions tested on:
ScummVM 2.6.0pre1-gd1ccb3b4cbb (Jun 6 2022 04:44:10)
ScummVM 2.6.0pre26-gdac4ba3e1d9 (Jun 10 2022 06:36:01)

Language: English
Game version: GOG distribution
OS: Windows 7 ultimate sp1 64-bit

Change History (13)

comment:1 by alxpnv, 11 days ago

Distorted sounds should now be fixed. As of the thumbnails, can you provide some details on your graphics settings (graphics mode, scaler, etc.)?

comment:2 by antoniou79, 11 days ago

Some observations for the flickering issue on my setup:

  • This is with Graphics mode: OpenGL, Stretch Mode: Fit to Window, Render Mode: Default, Scaler: Normal 4x. No aspect ratio correction, No Full Screen mode, No filter graphics, V-Synch On.
  • I'm testing on Windows 10 Pro x64, on a screen 1920x1200.
  • The thumbnails will not always flicker for me. In fact it seems to depend on where the cursor is over the name of the saved game. If it's over the number of the saved game or the start of the text for the saved game's name, then it will not flicker. If it's towards the last part of the saved game's name then it will flicker.
  • When flickering, the saved game's name is also rapidly changing color like it's being selected and unselected quickly.

I may be able to upload a quick video to demonstrate this, if required.

Last edited 11 days ago by antoniou79 (previous) (diff)

comment:3 by antoniou79, 11 days ago

Uploaded video here:

comment:4 by antoniou79, 10 days ago

Ammendment, it's not always towards the end of the saved game name text that causes the flickering. For example if I select a saved game from the right column the behavior is a bit different -- still connected to where the cursor is but also seems that when selected the hotspot area for the save game name is lengthened (?)

comment:5 by alxpnv, 10 days ago

@antoniou79: Unfortunately, I couldn't reproduce this issue with your settings.
Changing scale factor doesn't seem to make any effect with OpenGL backend on my system. Does this still occur when scaler set to default?

in reply to:  5 comment:6 by antoniou79, 10 days ago

Replying to alxpnv:

@antoniou79: Unfortunately, I couldn't reproduce this issue with your settings.
Changing scale factor doesn't seem to make any effect with OpenGL backend on my system. Does this still occur when scaler set to default?

In SDL Surface mode I get no flickering. The thumbnails are larger too and the hotspot area over the selected saved game seems more tightly calculated.
In OpenGL mode, even with defaults for scalers (and also tested with default for Stretch mode too and the rest of the fields) I seem to always get the flickering.

comment:7 by antoniou79, 10 days ago

Here's what I found to be the culprit:
In "engines\asylum\views\menu.cpp", in Menu::adjustCoordinates() the g_system->getOverlayWidth() and g_system->getOverlayWidth() are 640 and 480 respectively on SurfaceSDL mode. These values result on the x, y for cursor remaining unchanged after a call to adjustCoordinates().

On OpenGL mode on my screen they are: 1920 and 1137. These values result on cursor x and y being radically changed after a call to adjustCoordinates().

Now it seems also that adjustCoordinates() (in either SurfaceSDL or OpenGL mode) does not always adjust the cursor x and y. Sometimes it returns because apparently !g_system->isOverlayVisible() is true. I am not sure what this checks and why it fluctuates. Is the thumbnail the overlay?

Also, just by commenting out the adjustCoordinates(cursor) in Menu::updateLoadGame() stabilizes somewhat the behavior (if cursor is not moved the thumbnail does not flicker). Still if the cursor moves along the saved game name the cursor coordinates do change radically (OpenGL mode) and the thumbnail flickers (only if cursor is moving).

So adjustCoordinates is needed, but something else must be considered in its calculations.

Last edited 10 days ago by antoniou79 (previous) (diff)

comment:8 by alxpnv, 10 days ago

@antoniou79: Thumbnails are drawn on the overlay, since they are 4bpp and the game screen is 1bpp (probably not the best approach). IIRC with SDL, the overlay is always 640x480, while with OpenGL its size may be different. The coordinates returned by EventManager::getMousePos() seem to be relative to the overlay size, hence flickering.

comment:9 by antoniou79, 10 days ago

There are two issues that affect the flickering on OpenGL.

  1. The main issue is that the overlay's dimensions are set to the monitor's or the game's window's actual resolution, but the game (which natively is 640x480) can be drawn in a number of ways on that surface ("stretch mode" is more of a factor here). This means that the adjustCoordinates() assuming a stretched scale of the game's width and height (640x480) to the window/monitor's (overlay) surface is not always right -- but in theory it should be for example if Stretch Mode is set to "Stretch to Window" and FullScreen is enabled.
  2. The other issue is that it seems that the cursor coordinates are only updated if the mouse actually moves. But for the case of the transition to the overlay (showThumbnail()), the code assumes that in the next updateLoadGame() call, with the overlay enabled, the coordinates will need adjustment -- but if the mouse did not move, it will adjust the old coordinates to some bad x,y. It will then proceed to disable the overlay (removing the thumbnail), and in the next iteration it will draw the thumbnail again, and so on. Thus the flickering with the cursor not moving.

If possible I would suggest to not use the overlay at all to draw the thumbnail.

Last edited 10 days ago by antoniou79 (previous) (diff)

comment:10 by alxpnv, 9 days ago

@antoniou79: Since this feature isn't present in the original, I'm tending towards its removal. My final guess is since the flickering occurs only when the cursor is towards the end of the saved game name, the text width (lines 852 and 875) should be multiplied by some factor (scale_factor?)

comment:11 by antoniou79, 9 days ago

I am tinkering a bit with the code. I agree that if it's too much of a headache to implement maybe it can be removed (or removed from the OpenGL mode if that's possible, since SDL does not have the issue).

After testing more it's not just at the start of the text; this sort of is true in the first column but in the second it is different and that's due to the inaccurate "translation" of the coordinates between overlay and no-overlay.

Ideally it would be possible to be able to somehow get the mouse co-ordinates on the game screen rather than the overlay -- maybe there's some method for that in the backend API?

Edit: I've asked for help in the development channel on Discord around here:

Last edited 9 days ago by antoniou79 (previous) (diff)

in reply to:  11 comment:12 by alxpnv, 6 days ago

Replying to antoniou79:

Edit: I've asked for help in the development channel on Discord around here:

So this feature seems to be impossible to implement properly with the current code. Are you ok with removing it?

comment:13 by antoniou79, 6 days ago

It's up to you. I do like the feature. Maybe the relevant code can be commented out until we get a proper way to translate the mouse coordinates from overlay to game screen, which --my understanding is-- could be implemented in the future.

Note: See TracTickets for help on using tickets.