Opened 2 years ago

Closed 2 years ago

#13561 closed defect (fixed)

Sanitarium: Random audio glitch and savegame thumbnails flickering

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

Description

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 (17)

comment:1 by alxpnv, 2 years 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, 2 years 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 2 years ago by antoniou79 (previous) (diff)

comment:3 by antoniou79, 2 years ago

Uploaded video here:
https://youtu.be/mfEJOmbmgrQ

comment:4 by antoniou79, 2 years 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, 2 years 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, 2 years 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, 2 years 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 2 years ago by antoniou79 (previous) (diff)

comment:8 by alxpnv, 2 years 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, 2 years 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 2 years ago by antoniou79 (previous) (diff)

comment:10 by alxpnv, 2 years 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, 2 years 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:
https://discord.com/channels/581224060529148060/711242520415174666/987291715301945374

Last edited 2 years ago by antoniou79 (previous) (diff)

in reply to:  11 comment:12 by alxpnv, 2 years ago

Replying to antoniou79:

Edit: I've asked for help in the development channel on Discord around here:
https://discord.com/channels/581224060529148060/711242520415174666/987291715301945374

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

comment:13 by antoniou79, 2 years 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.

in reply to:  13 comment:14 by alxpnv, 2 years ago

Replying to antoniou79:

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.

I've reimplemented this feature using Graphics::PaletteLookup. Can you please check if it now works properly with your settings?

comment:15 by antoniou79, 2 years ago

Seems to be working perfectly.

Thank you for the fix, well done!

(I should look into this PaletteLookup, it seems that it's doing some magic work!)

in reply to:  15 comment:16 by alxpnv, 2 years ago

Replying to antoniou79:

Seems to be working perfectly.

Thank you for the fix, well done!

(I should look into this PaletteLookup, it seems that it's doing some magic work!)

Thanks a lot for your help. Closing this

comment:17 by alxpnv, 2 years ago

Owner: set to alxpnv
Resolution: fixed
Status: newclosed

Thanks for the report

Note: See TracTickets for help on using tickets.