h-a-l-9000 wrote:

Wonder if the turbo button could speed it up...
..

yes, it is useful thanks!

wd wrote:

.....But iirc it only happened after long in-game time so savestates would not work to reproduce it,
but maybe it works out differently for you.
Thanks for offering your help!

saving the game doesn't help to reproduce the bug..
I just tried HAL9000's tip and yes it works!!!
now I tell you how exactly to reproduce the bug in a relatively short time!
start the first of the OLD MAPS. then press V to accelerate the game. then press and hold ALT+F12 for as long as you can (sometimes break it scrolling around the map looking at enemy expansion...).
I reproduced the bug and saved the game. the game has been saved after 1h59m but I believe it is game time, because I made it in a 10-20 minutes, not more...
let me know if it works for you!
ciao

h-a-l-9000 wrote:

Wonder if the turbo button could speed it up...

have your game so the opponent can't do anything, set cycles rather low, frameskip 10 then keep ALT-F12 pressed.

hi, i have just tried with cycles 5000, frameskip 20 and turbo on..
unfortunately im not able to repeat the issue 😢

i think the bug is related to the real time movement of the mouse, connected also to the scrolling mode and the opening and closing of the various in-game windows....

let me know how can i help u in some way!
may u give me something like a debugger??

wd wrote:

At the moment I don't remember exactly how saves work in S2gold,...
But iirc it only happened after long in-game time so savestates would not work to reproduce it,but maybe it works out differently for you.

today im trying to replicate the issue considering HAL9000's tips but with no luck 😵
to provide other information, once the bug is activated, it lasts till the game is quitted.
let me know how to be useful to eradicate this nasty bug!! 😲

is it possible no one who can may be interested to solve this (likely DosBox) bug??? i give my time and my efforts to provide the right informations to the right people!
come on, let me know how to proceed!

come on, let me know how to proceed!

Get a debugger.

wd wrote:

Get a debugger.

im a novice at all in programming, please provide a downloadable link and tell me briefly how to capture the requested info as the bug appears.

Happens on both settlers 2 and 2 gold.
Works even on title screen you can just:

move the mouse in any direction long enough and after some distance it will "stuck" to the boarder of the screen and you will have to move back to "unstuck" the mouse from the boarder. The further you stuck it the more you have to go back to unstuck.

You can stuck it to any boarder you want any time. If you move the mouse back to the center of that invisible large area everything will be ok till you move too much to one of boarders again.

When you play the game and scroll with right mouse key you got it the way people described it.

How long is "long enough"? I'm not seeing behavior where the mouse pointer becomes "stuck" at screen edges, no matter how much I attempt to move the pointer past the edges. This is with Settlers II Gold Edition, v1.51 English using all available screen resolutions. The v1.51 patch is on Patches-Scrolls.

the setttlers ii veni, vidi, vici blue byte 1995-96-english-v1.02
the settlers ii gold edition blue byte 1995-97-english-v1.51

title screen is only in 640x480 i think

com mouse - about 20 mousepad moves to right
ps/2 mouse - about 10 mousepad moves to right
usb mouse set to 1800 dpi - about 4 mousepad moves to right
usb mouse set to 450 dpi - about 12 mousepad moves to right

btw
doesn't happen on real computer with com mouse
doesn't happen in dosbox with directserial

Doesn't happen at all with my MS bluetrack mouse in WinXP.

Does poll rate have an effect?

doesn't happen in svn 😉
happens in 0.74 😀

hmm, it does happen for me in official 0.74, and also happens in one of my SVN builds but not another, possibly due to compile options. It may take some time to pin this jelly to the wall...

The issue occurs for me when compiling SVN source using "-O2 -march=i686" flags in GCC, but not if -msse is added. I don't know if -msse has an effect on floating point because I don't specify -mfpmath=sse.

It seems that the game fails to realize that the pointer has gone out of range, which fits with why the pointer behaves normally after moving back as far as you move past the edge. I guess coordinate rounding could be the issue, but loading a mouse driver doesn't help, so perhaps something at the SDL interface level.

I've been testing with the edges of the title screen, so can't say for sure if this is the same issue as the reported one that appears when right-click scrolling on the gameplay screen.

In my tests the attached patch is fixing the problem regardless of compile options. Maybe limiting min/max mickeys to what can fit in a signed int would make the conversion less open for compiler interpretation...

robertmo wrote:

Happens on both settlers 2 and 2 gold.
Works even on title screen you can just:
move the mouse in any direction long enough and after some distance it will "stuck" to the boarder of the screen and you will have to move back to "unstuck" the mouse from the boarder.

you are a great! 😁
you have found the very origin of this nasty bug!!!

I confirm this is a DOSBOX BUG: playing under XP's NTVDM, it doesn't occur.
I have easily replicated the issue during a play by simply holding down the right mouse button and by keeping scrolling to a side: after a while, the mouse pointer got stuck at the center of the screen, as described in my previous posts..
thank you very much! 😉

the attached patch is fixing the problem regardless of compile options

Does it work when first casting to signed 16bit and then to unsigned?

wd wrote:

the attached patch is fixing the problem regardless of compile options

Does it work when first casting to signed 16bit and then to unsigned?

Nope. I guess there is an implicit cast to unsigned by storing the signed value in an unsigned var, but in any case there is no difference when adding an explicit cast to unsigned.

The additional change in the attached patch fixes the problem when loading a mouse driver. I used static_cast because my understanding is that it is preferred for float-to-int conversions.

There is one more mouse bug, but it happens on real computer too.
In case anyone saw it and wonders what is wrong:
While dragging any ingame window, right-click or esc to close it. Next time you open any ingame window it will be escaping from you if you try to move it.

Are values getting that large then ? Or is it a side effect from going negative ?