#6567 closed defect (fixed)
WME: 1 1/2 Ritter - Graphical slider issues in sound options menu
| Reported by: | raziel- | Owned by: | lolbot-iichan |
|---|---|---|---|
| Priority: | normal | Component: | Engine: Wintermute |
| Version: | Keywords: | original | |
| Cc: | Game: | Wintermute |
Description
ScummVM 1.7.0git (Apr 3 2014 09:25:57) Features compiled in: Vorbis FLAC MP3 RGB zLib MPEG2 Theora AAC FreeType2 JPEG PNG
On the very first screen go to "Optionen" and try to change any of the settings. The cursor will change color when over a lever and pressing it will give the ability to move the lever, but... ...now the cursor will be stuck at the lever and won't let go nop matter what. Neither clicking right or left will help, the only solution is to press ESC to retract and reach the main options page which in turn will cease all changes you have done to the sound/music/speech settings.
The original engine lets you only change/move the lever while you left click and move the mouse cursor. Letting go of the left mouse button will set the lever.
This is with the german full version of the game, yet it also happens in the german demo.
1 1/2 Ritter (fangame) (Windows)
AmigaOS4 - PPC - SDL - BE gcc (GCC) 4.2.4 (adtools build 20090118)
Ticket imported from: bugs/6567.
Attachments (1)
Change History (27)
comment:1 by , 10 years ago
| Component: | → Engine: Wintermute |
|---|---|
| Game: | → Wintermute |
| Owner: | set to |
comment:2 by , 5 years ago
comment:3 by , 5 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → pending |
comment:4 by , 5 years ago
| Owner: | changed from to |
|---|---|
| Status: | pending → closed |
comment:5 by , 5 years ago
The stuck case is fixed, but now clicking on one of the option arrows makes the mouse pointer move to the right pixel by pixel even if the mouse is not moved at all. One need to keep the mouse button pressed to make this happen.
Makes it hard to set any of the options
comment:6 by , 5 years ago
| Resolution: | fixed |
|---|---|
| Status: | closed → new |
Not sure if i need to address this to a new bug, but it seems the fix introduced a new wrong behaviour or at least didn't fix it completely?
comment:7 by , 5 years ago
The same issue (stuck in sound menu) happens in Five Lethal Demons (Windows/English)
.
Press ESC to reach the main menu, choose "Settings" and try to move the slider of the main sound.
Mouse cursor is stuck to the slider, one can only move it far right or far left, but not set it.
Clicking ESC makes one get thrown back to the main menu, but the former setting is not saved.
comment:8 by , 5 years ago
The same issue (stuck in sound menu) happens in Five Lethal Demons
Yes, it should be fixed once i put exact Wintermute engine version instead of LATEST_VERSION for Five Lethal Demons.
I'm currently working on collecting at least one version of every detectable game and already got most of them, except for some Carol Reed games and just several more: conspiracao, julia, lifein3minutes, projectjoe, securanote, shaban, war, zilm.
now clicking on one of the option arrows makes the mouse pointer move to the right pixel by pixel even if the mouse is not moved at all. One need to keep the mouse button pressed to make this happen
This... Is... Very... Strange...
I can't reproduce it with both my branch and dayly build.
Also, your side effects are not something expected for engine's or game's code.
Mouse should be teleported to arrow center once, on LeftClick event. Maybe your mouse somehow generates several LeftClick in a row? I'll think of adding some more logs to debug this better.
Meanwhile, could you please describe some details:
Does this reproduce with fresh dayly build?
Does this occur both in Ritter and Oknytt?
Just how fast the mouse is moving? Like, a pixel per second slow, or from-zero-to-full in blink of an eye?
Which OS are you using?
Does this happen both in windowed and fulscreen mode?
Does this happen with different types of scaling (no scaling, bigger then 100%, smaller then 100%)?
Are you using a normal PC with a normal mouse and a normal screen or there are any details worth noting (like, some retina-screen tablet with a touchscreen and several external bluetooth trackballs or something...)?
Have you ever had any mouse-specific issues in other programs on this hardware? Have you ever had any mouse-related issues with Wintermute (except for slider issues)?
Not sure if i need to address this to a new bug, but it seems the fix introduced a new wrong behaviour or at least didn't fix it completely?
I guess we should discuss it here since issue isn't fixed completely.
comment:9 by , 5 years ago
I'll get back to all your questions once I'm back home.
Thank you for taking the time.
What i can answer already:
Just how fast the mouse is moving? Like, a pixel per second slow, or from-zero-to-full in blink of an eye?
I'll have to measure it, but yes, a pixel per second sounds about right.
Which OS are you using?
This is part of the original report: AmigaOS4
Are you using a normal PC with a normal mouse and a normal screen or there are any details worth noting (like, some retina-screen tablet with a touchscreen and several external bluetooth trackballs or something...)?
Nope, normal mouse, normal monitor
Have you ever had any mouse-specific issues in other programs on this hardware?
Nope, albeit I was blaming my SDL2 implementation first, since its still in the process of being ported, but as there doesn't seem to be other mouse related problems I doubt its the culprit.
Waiting for your enhanced logging...
Have you ever had any mouse-related issues with Wintermute (except for slider issues)?
Nope, never, worked pretty good from day one.
P.S. cant wait for you to tackle the Ghost in the Sheet and Rhiannon bugs ;-)
comment:10 by , 5 years ago
@lolbot-iichan
Here is the rest of the questions:
Does this reproduce with fresh dayly build?
Yes, build from yesterday evening, same behaviour
Does this occur both in Ritter and Oknytt?
No, only in Ritter (Oknytt v1.13 is fine)
Just how fast the mouse is moving? Like, a pixel per second slow, or from-zero-to-full in blink of an eye?
Well, if i click and hold the slider, then it's roughly a pixel per second, slowly wandering to the right (but not to the left), starting from the position it was saved at.
Does this happen both in windowed and fulscreen mode?
Yes, but
1) In fullscreen mode the slider icons "wanders" to the right, while
2) In window mode the slider icon skips to the far left (setting i.e. speech to Off, but this happens to all the settings according to what i click on) and stays there, no other settings possible, the mouse icon is stuck too.
If i click outside the window area and back into the window twice, the mouse cursor is free again.
Does this happen with different types of scaling (no scaling, bigger then 100%, smaller then 100%)?
Yes, it actually doesn't matter which scaling is active, the same 1) and 2) occurances appear.
comment:11 by , 5 years ago
In window mode the slider icon skips to the far left
This... Is... Even... More... Strange...
I really have no idea how this happens, so if you have some time to assist me, let's start with gathering information on which code is affected and how exactly mouse is moving.
No, only in Ritter (Oknytt v1.13 is fine)
This is a very promising point to start. "If it bleeds, we can kill it." If there are sliders that works fine, we can find out what's wrong with this one.
I have updated test game (https://github.com/lolbot-iichan/wme_testsuite/tree/master/slider_test/packages) today, now it contains 2 types of sliders.
The first slider has very simple code that is used at 5MA, 5LD, Helga, Oknytt. I believe it should work properly on your system.
The second slider has code similar to code that 1 1/2 Ritter and James Peris (Full version) are using. I believe it should work with issues on your system.
I also filed a PR (https://github.com/scummvm/scummvm/pull/1764) to ScummVM to add some special logs to debug this case - logs would contain timestamps of LMB pressed/released and also information on mouse's X coordinate changes made by you and by game script.
Could you please:
I) Check if I correctly identified the slider code that causes the issue.
- Download test game and verify that the first slider is working correctly and the second slider has issues similar to 1 1/2 Ritter game.
- Check if Full version of James Peris (https://jamesperis.itch.io/jamesperis) is affected as well.
II) Make your ScummVM more verbose:
- Wait until https://github.com/scummvm/scummvm/pull/1764/files gets into dayly build (by looking at git hashes or just waiting 2-3 days since PR is merged)
- Download this ScummVM dayly build
- Add "debug_cursor=true" line under "[scummvm]" section of "scummvm.ini"
III) Collect additional logs at windowed mode:
- Run "./scummvm --debuglevel=11 --debugflags=all" and choose either my test game or 1 1/2 Ritter game (if test game is not affected)
- Collect logs when mouse is teleporting to the left and does not move (open game, go to settings, click on slider, try to move mouse yourself once it is pressed to different directions, release mouse, press Ctrl+F5 and terminate ScummVM)
- Make sure those logs contain "CURSOR: onMouseLeftDown" line
IV) Collect additional logs at fullscreen mode:
- Run "./scummvm --debuglevel=11 --debugflags=all" and choose either my test game or 1 1/2 Ritter game (if test game is not affected)
- Collect separate logs when mouse is moving right (open game, go to settings, click on slider, try not to move mouse yourself once it is pressed, hold mouse pressed for some 10-30 seconds, release mouse, press Ctrl+F5 and terminate ScummVM)
- Make sure those logs contain "CURSOR: onMouseLeftDown" line
P.S. You can report results once you have enough time for such testing.
comment:12 by , 5 years ago
| Owner: | changed from to |
|---|
comment:13 by , 5 years ago
I had to manually add the test game details to the detection table, hope i didn't break anything...
Could you please:
I) Check if I correctly identified the slider code that causes the issue.
I'm afraid not, at least not completely.
Download test game and verify that the first slider is working correctly and the second slider has issues similar to 1 1/2 >Ritter game.
First slider works as it should, no skipping, no oddities, no nothing, everything's fine (if every slider would work that way i'd be happy) :-)
Second slider is working as well, but
1) I can drag it *over* the window border on the left side, just a few pixels, somethimes more (depending on how fast i move the mouse) before it will skip back inside the window border and from now on i can't drag it beyond anymore (the right border is correct, it stops when the window border is hit)
2) It displays a similar bahaviour to what i described with James Peris below, only that the pixels it moves is always "1" AND it will randomly move to the left aswell (James Peris does only move to the right)
Check if Full version of James Peris (https://jamesperis.itch.io/jamesperis) is affected as well.
Yeah, well, it is, kind of.
If i click on *any* of the sliders the mouse pointer moves some pixels to the right and then stops (chaning the slider setting in the process). If i release the mouse, do not move anywhere and click on the same spot again, nothing happens.
If i move the mouse around, move back to the very same slider and click on it again, it will be moved to the right again for some pixels.
The number of pixels is random in a way that it may be 2 upto 6 pixels.
I have to add that this test was done with the test build and your debug code already in place (not sure if this affects any of these issues.
P.S: with the latest code merge from today morning, i am not able to reproduce the ritter behaviour (also not sure if some fix is in the code already) of moving sliders by itself. I can reproduce the James Peris behaviour but to a much lesser extent, i.e. it will only happen ONCE on ONE of the sliders and then never again, unless i leave the Options page and return, then i can reproduce it again ONCE.
P.P.S: I know that the movement could be because i am not keeping my hand still when clicking on the pointer, but i doubt that's the reason since i'm trying to "freeze" my movement when clicking.
P.P.S: Since i'm using the SDL2 backend and since there was an update to SDL2 on my platform recently (no changes to any code near this, as far as i know, though) i think i should add this fact.
comment:14 by , 5 years ago
I'm afraid the debugging doesn't work (here).
I triple checked the debug changes i add and they are fine and in place (to what https://github.com/scummvm/scummvm/pull/1764/ suggests), but i don't get any
"CURSOR: onMouseLeftDown" in the whole log
just lots and lots of
Blit(160, 165, 0, [0, 0, 30, 30], ffffffff, 30, 30)
in all forms and colors.
Help?
P.S: I wrote that i can't make the ritter game behave like it was reported and that it might not exactly be the issue i'm getting, but further tests show that it does jump around (also to the left) with your test game's second slider, so you do seem to have the issue identified that i'm experiencing.
comment:15 by , 5 years ago
I had to manually add the test game details to the detection table, hope i didn't break anything...
That's fine. However note that when adding a game not listed in detection table you can just select the last option from ScummVM UI suggestions. It is an autogenerated entry that allow you to add the game without editing detection tables.
First slider works as it should, no skipping, no oddities, no nothing, everything's fine (if every slider would work that way i'd be happy) :-)
That's good. That means that if we won't find a good solution, I can just hack ScummVM to run some hand-written script for sliders instead of buggy one for those 2 games.
I can drag it *over* the window border on the left side
I guess that's result of me over-simplifying the script. I cared about reproducing the dragging similar to Ritter's and didn't cared much about border behaviur.
the pixels it moves is always "1" AND it will randomly move to the left aswell (James Peris does only move to the right)
Oh noes, it gets stranger and stranger with each test.
If i click on *any* of the sliders the mouse pointer moves some pixels to the right and then stops (chaning the slider setting in the process).
If i move the mouse around, move back to the very same slider and click on it again, it will be moved to the right again for some pixels.
Yes, Ritter and James Peris slider code is designed to have such effects - mouse if teleported to some "old" position that may be several pixels off. It's kind of strange that it is "only to the right". However, small movement at the very moment of Mouse Down event seems to be "original" bug. What is not expected from such code is cursor and/or slider movement when mouse button is pressed and your hand is not moving, which you reported earlier.
I have to add that this test was done with the test build and your debug code already in place (not sure if this affects any of these issues.
This is fine.
i am not able to reproduce the ritter behaviour (also not sure if some fix is in the code already) of moving sliders by itself
Does this mean that you can set the desired value on any slider in any game? I didn't fix anything.
i don't get any "CURSOR: onMouseLeftDown" in the whole log
Have you added "debug_cursor=true" line under "[scummvm]" section of "scummvm.ini"?
further tests show that it does jump around (also to the left) with your test game's second slider, so you do seem to have the issue identified that i'm experiencing
Does this jumping occur only at the moment when you start pressing the mouse button? Or it is some constant/shivering movement that happened by itself while mouse is pressed and hold still?
Let's sum up what we have. There are several games and several kinds of strange phenomena, I need to understand I get you correctly:
1a) Can you sometimes set the desired values on all the sliders at 1 1/2 Ritter without issues?
1b) Does teleporting to the 0% without ability to move mouse occur at 1 1/2 Ritter? If yes, is there a stable scenario to get it?
1c) Does mouse jumping a few pixels at the very moment you start clicking the mouse occur at 1 1/2 Ritter? If yes, is there a stable scenario to get it?
1d) Does slow, about several pixels per second, unintentional mouse movement to some constant direction occur at 1 1/2 Ritter while you keep the mouse pressed and not moving your hand at all? If yes, is there a stable scenario to get it?
2a) Can you sometimes set the desired values on all the sliders at James Peris without issues?
2b) Does teleporting to the 0% without ability to move mouse occur at James Peris? If yes, is there a stable scenario to get it?
2c) Does mouse jumping a few pixels at the very moment you start clicking the mouse occur at James Peris? If yes, is there a stable scenario to get it?
2d) Does slow, about several pixels per second, unintentional mouse movement to some constant direction occur at James Peris while you keep the mouse pressed and not moving your hand at all? If yes, is there a stable scenario to get it?
3a) Can you sometimes set the desired values on second slider of test game without issues?
3b) Does teleporting to the 0% without ability to move mouse occur at second slider of test game? If yes, is there a stable scenario to get it?
3c) Does mouse jumping a few pixels at the very moment you start clicking the mouse occur at second slider of test game? If yes, is there a stable scenario to get it?
3d) Does slow, about several pixels per second, unintentional mouse movement to some constant direction occur at second slider of test game while you keep the mouse pressed and not moving your hand at all? If yes, is there a stable scenario to get it?
comment:16 by , 5 years ago
Let me just gather the answers...i think i'm on to something, at least it looks promising...
Just a quick glance, it seems to differ greatly from fullscreen to window...
comment:17 by , 5 years ago
I want to draw your attention to, especially, 1b and 2a.
i don't get any "CURSOR: onMouseLeftDown" in the whole log
Have you added "debug_cursor=true" line under "[scummvm]" section of "scummvm.ini"?
Yes, of course, just like you noted in the PR
Further tests show that it does jump around (also to the left) with your test game's second slider, so you do seem to have the issue identified that i'm experiencing
Does this jumping occur only at the moment when you start pressing the mouse button? Or it is some constant/shivering movement that happened by itself while mouse is pressed and hold still?
It's just one jump or skip and yes, it does it the moment i click on the slider,
I guess it's because (as you mentioned) the engine moves the slider to a position that is more or less the center of the clicked slider image.
Let's sum up what we have. There are several games and several kinds of strange phenomena, I need to understand I get you correctly:
1a) Can you sometimes set the desired values on all the sliders at 1 1/2 Ritter without issues?
Yes, i can.
There is no problem (anymore) in setting every slider without issues on using fullscreen.
There are the explained problems (all of them) on using window mode, though. :-(
1b) Does teleporting to the 0% without ability to move mouse occur at 1 1/2 Ritter? If yes, is there a stable scenario to get it?
Not in fullscreen.
Yes in window mode.
Stable Scenario?
Well, it's 100% reproducable for me. Just load the game, go to options and click on the sliders.
The stuck mouse pointer only occurs stuck if i keep the mouse button pressed and move it around (sometimes the slider even moves to 50% and 100%, but no leveling is possible.
If i click on the slider and release it after it has skipped to 0% i have a good chance to be able to move the mouse around again.
A workaround to this behaviour is to open the launcher menu (CTRL+F5) as this will release the mouse pointer again (most of the time).
And another thing i found while testing the "center click is off by some pixels" bug.
If i click left of the slider image center, it will skip to 0%, but if i click right it will send me to 100% or max.
So, it's not a problem of the left skip but again one of those "click in the image center is off by some pixels" bug.
1c) Does mouse jumping a few pixels at the very moment you start clicking the mouse occur at 1 1/2 Ritter? If yes, is there a stable scenario to get it?
Not in fullscreen.
I can't test that in window mode as it immediatly skips to 0% and stays there, but i'd guess yes.
1d) Does slow, about several pixels per second, unintentional mouse movement to some constant direction occur at 1 1/2 Ritter while you keep the mouse pressed and not moving your hand at all? If yes, is there a stable scenario to get it?
Not in fullscreen.
I can't test that either in window mode anymore (see 1c), but since it was there before, i'd guess yes.
2a) Can you sometimes set the desired values on all the sliders at James Peris without issues?
With issues in fullscreen.
The skipping is there in James Peris, i now understand why it sometimes skips to the left and why it "randomly" skips a different amount of pixels.
It's because of the position of the mouse pointer.
Lets say i happen to click in the exact center of the slider image, then nothing will happen. The value will stay the same and i can move the slider aorund to set the desired value.
Now, if i'm one pixel off to the left or right, the slider will move that pixel to the left or right, changing the value in the process.
If i'm not mistaken i can move the mouse pointer up to six (or was it seven) pixels max off the center of those images making the slider skip as many pixels and change the value.
I "believe" this is the same bahaviour as in ritter, but there (for some some reason) the *mouse pointer* is moved to the exact center of the slider image, while James Peris does it the other way round (which is wrong imho).
Not in window.
Window is as bad as in ritter window, see 1a.
2b) Does teleporting to the 0% without ability to move mouse occur at James Peris? If yes, is there a stable scenario to get it?
Yes in window.
With one exception, when it skips to 0% (and the stuck mouse pointer occurs in ritter) in James Peris my mouse pointer is warped to a random position (can't quite get a reproducable way where it sends it to the same position, but will try further) but the mouse pointer will nearly everytime be sent OUTSIDE the window border, making it impossible to play along, unless i click into the window again.
Maybe that is (was) the reason it was stuck in ritter and is still stuck in your test game? (see below)
2c) Does mouse jumping a few pixels at the very moment you start clicking the mouse occur at James Peris? If yes, is there a stable scenario to get it?
Not in fullscreen.
Yes in window.
2d) Does slow, about several pixels per second, unintentional mouse movement to some constant direction occur at James Peris while you keep the mouse pressed and not moving your hand at all? If yes, is there a stable scenario to get it?
Not in fullscreen.
I can't test that either in window mode anymore (see 1c), but since it was there before, i'd guess yes.
3a) Can you sometimes set the desired values on second slider of test game without issues?
I hate to say it, but it gets even stranger.
I built a new version today and for some reason your test game is now as bad as it can get.
To answer this question, no i can not (anymore), not in fullscreen, not in window.
3b) Does teleporting to the 0% without ability to move mouse occur at second slider of test game? If yes, is there a stable scenario to get it?
Nope, this skipping on first slider click is not there, at least i can't reproduce it.
3c) Does mouse jumping a few pixels at the very moment you start clicking the mouse occur at second slider of test game? If yes, is there a stable scenario to get it?
Yes in fullscreen.
Yes in window.
Stable scenario for me is simply to start the game, click left or right of the sliders image center and the slider will move, see 2a
3d) Does slow, about several pixels per second, unintentional mouse movement to some constant direction occur at second slider of test game while you keep the mouse pressed and not moving your hand at all? If yes, is there a stable scenario to get it?
No, not really that behaviour, but something similar.
Since the mouse pointer is stuck indefinitely to any of the sliders once i clicked it, i can click and hold the mouse button and slowly move the mouse to the left or right and the slider will start moving by itself, even if i release the mouse button.
I can speed it up by moving the mouse faster, but i cannot set anything anymore, because of the stuck mouse pointer.
The workaround (CTRL+F5) doesn't work here either. I have to quit the game or close ScummVM.
Stable scenario for me is again to simply start the game.
Sorry for all the strange problems, but thank you for not simply skipping this problem.
comment:18 by , 5 years ago
| Keywords: | original added |
|---|
Finally, I have a breakthrough on understanding the low-level mechanics behind all the kinds of issues with second type of sliders!
The code of those sliders is something like this:
on "LeftClick" {
mouseLocked = 1;
while(mouseLocked) {
<disallow moving mouse outside of slider area>;
<adjust slider position to mouse position>;
<adjust mouse position to previous mouse position>;
}
}
on "LeftRelease" {
mouseLocked = 0;
}
Maybe it is a mistake, maybe it was made intentionally to make sliders felt more "heavy", but mouse position is adjusted not to exact center of slider, but to SOME VALUE calculated on mouse movement data and slider position. This actually means that mouse MAY NOT HOVER slider button on the moment when left button is RELEASED. Which means that "LeftRelease" event may not be recieved by slider button. Which means that loop inside "LeftClick" handler may act like endless loop, if you move your mouse right way.
However, there is a workaround - if you click&release mouse one more time, the loop will be stopped. But this is where things begin to act really weird, because you can actually move your mouse during this click&release, and as we know, release event can be lost. Which mean that it is possible to get TWO endless loops running, adjusting slider and cursor position! Since those loops are working with the same global variables, but still have some local variables, they see each other as user input that should be adjusted. Which causes several types of funny effects, including slider&cursor that moves by itself while mouse is not pressed at all!
If you click mouse second time without releasing, you'll get behaviour that was experienced by raziel- Which finally leads us to stable scenario to reproduce the issue.
Scenario:
(Bug A) Step 1. While performing very fast horisontal movement, leftclick&release any slider of second type (Sliders at James Peris, Ritter, second slider of test game). Cursor should then stuck to the slider, making you move the slider while the mouse button is actually released. This requires some practice, but in my test game it's the behaviour that I can reproduce with 1-3 tries.
(Bug B) Step 2. Leftclick on slider again without releasing the mouse. Try moving mouse slightly to the left, slightly to the right. Cursor and slider would both move by itself! Sometimes this movement is very slow, sometimes it's move like instant jump to the side, sometimes it's steady movement, sometimes it's bouncy movement (2 pixels to the right, 1 pixel to the left, 2 pixels to the right, ...).
(Bug C) Step 3. If you are lucky enough to release mouse button while cursor is somehow not hovering the slider, you'll get even more buggy behaviour, when cursor and slider would both move by itself while you remove your hand from the mouse!
Now I'm finally able to quite easily reproduce bugs A, B, C with original Wintermute and my test game.
I was also able to several times reproduce bugs A, B, C with porn slider of James Peris (the difference is that in this case porn settings WINDOW is moving around by itself, not porn settings SLIDER moving around by itself, but whatever).
I guess this makes this "original" bug, repruducable both with original game and with ScummVM.
However, for some reasons, this is a hard-but-possible-to-reproduce bug for me on Windows SDL2, and impossibe-to-avoid bug for raziel- on Amiga SDL2.
To get more info on it I still need some logs.
Could you please run some tests again with "lolbot-iichan/wme_slider_debug" branch's latest commit a6d7866252e067dd75b242c60721985fcd265688 (https://github.com/lolbot-iichan/scummvm/commits/wme_slider_debug)?
I need you to:
- Start ScummVM with ./scummvm --debugflags=enginelog
- Run 1 1/2 Ritter in window mode.
- Reproduce stable scenario of teleporting to 0%
- Stop the engine with Crtl+F5, close ScummVM
- Check logs, there should be lines like [2019-08-05 01:54:22] WARNING: CURSOR: onMouseLeftDown!
Please, if possible, try to make as few mouse clicks as needed to complete the scenario "load the game, go to options and click on the sliders" (use Esc to skip intro, restart ./scummvm if issue is not repruduced correctly) and provide a list of what you clicked/released and what happened.
Bonus test:
- Start ScummVM
- Run updated test game (dwonload fresh version from https://github.com/lolbot-iichan/wme_testsuite/tree/master/slider_test/packages)
- Right-click on the second slider (test game is hacked so that this action would produce 2 left-clicks events on the second slider and 0 left-release events)
- I believe you should experience the same issues you were talking about during those thread, but this case is 100% reproducable and should not depend on screen resolution, mouse speed, etc
comment:19 by , 5 years ago
Am i glad to hear you found a way to reproduce them.
I'll get those logs for you as soon as I'm back home.
Thank you
by , 5 years ago
| Attachment: | WME_Slider_Issue.txt added |
|---|
comment:20 by , 5 years ago
First test done:
Steps taken:
1) Start scummvm with -F --debugflags=enginelog
2) "1 1/2 Ritter" chosen
3) Load a saved game from after the intro
4) Pressed ESC to reach the menu
5) "Optione" chosen
6) First slider clicked once on the left side of it's center
Jumped immediately and reproducably to 0% or "Aus"
Log attached.
Bonus test log coming next
comment:21 by , 5 years ago
I can confirm the 100% reproducability in the test game.
Both window and fullscreen have the issues, though it looks like the fullscreen issues are a little different, but i guess that is because in window mode my mouse pointer is pretty much everytime warped outside the window area and on AmigaOS4 that means i loose focus on the window and the ability to do anything within it.
I then need to click in the OS area to make my mouse pointer appear again to be able to move it into the window area again.
Pretty annyoing, but nothing to do with this bug report :-)
comment:22 by , 5 years ago
| Summary: | WME: 1 1/2 Ritter - Stuck in the Sound Options Menu → WME: 1 1/2 Ritter - Graphical slider issues in sound options menu |
|---|
comment:23 by , 4 years ago
@lolbot-iichan
I'm going to close this report while revising my bug items.
a) The main issue from this report in "1 1/2 Ritter" is fixed, as far as i can see and test. I'm not able to trigger anything as bad as it was when i wrote this report.
b) The similar issue in "Five Magical Amulets" is mostly fixed.
I can still trigger the "mouse cursor stuck on slider graphic" but not in a reproducable manner. And it's not a persistent issue anymore, since another left click releases the mouse pointer again. I can live with that.
c) The "issue" in "James Peris" is still there (moving and changing slider, when i click just a few pixels off of the center of the slider graphic), but as you described in comment:15 this is how the slider was coded for the game and since it's easy to set to anything i want, without other issues interfering, i'm fine with how it works now.
d) Fullscreen and window behaviour now match exactly without differing results.
If you want to keep this open, just shout, otherwise i'll simply open a new item for the more persistent issues.
In that case, just shout.
And thanks a lot for the fixes :-)
comment:24 by , 4 years ago
| Owner: | changed from to |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
comment:25 by , 4 years ago
I can very easily trigger "mouse getting stuck inside sound bar region" bug at "1 1/2 Ritter" and "Five Magical Amulets":
- Open Options menu
- Do a single left mouse button click on the slider and hold mouse button
- HEAVILY shake mouse in all directions
- Release left mouse button it when it's at the edge of the bar
However, the mouse unstuck if I press Esc or do a left click.
And yes, that's original bug that I am able to reproduce with original game.
I guess it's fine to mark it fixed since there really was a much worse non-original behaviour at the beginning which was actually fixed.
Feel free to file a new bug or reopen this one if it will reproduce again in stable or annoying manner.
comment:26 by , 4 years ago
I just tried that and yes, it's a fairly easy way to trigger it SOMETIMES :-)
I was also able to trigger it in Five Lethal Demons aswell (once in five tries).
But as i wrote above, the issue itself is not consistent for me and it goes away when i click once again on the left mouse button while stuck on the slider, no need for ESC here.
That doesn't mean that the issue shouldn't be taken care of eventually, but i guess i'll leave that for someone else who'll be more annoyed about it than me :-)
I can reproduce it with ScummVM dayly.
Seems to be a bug introduced in WME Lite branch: http://forum.dead-code.org/index.php?topic=5143.0
Another affected game: #9861.