VOGONS


Settlers II Gold mouse problem

Topic actions

Reply 40 of 46, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

The mickey x/y values can become infinitely (within the limits for a float) positive or negative, and that is also true for the coordinate x/y values when using the ps2 callback. The problem occurs when the floats keep increasing or decreasing, but the the casted ints don't increase or decrease past the upper or lower boundaries for a signed int. I guess that casting to unsigned simulates a sign flip that allows the casted ints to continue increasing or decreasing along with their source floats.

Reply 41 of 46, by Don Meu

User metadata
Rank Newbie
Rank
Newbie

it's always a pleasure to stop listening to "geniuses" at work! 😉

Home of the Good Old Games
http://www.gog.com/

Reply 42 of 46, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

In a previous comment I mentioned limiting the float counters, and here is a patch based on the idea that I've found to be effective in solving the problem. This approach preserves the current signedness of integers casted from the counters, and I like that it keeps the counters from becoming huge, but it has the drawback of more computation with floats that is slightly complicated because of the mickey rates.

Reply 43 of 46, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Didn't notice it before, but it finally dawned on me that there is no reason for the mickey counters to always be scaled by their rates. Getting rid of that simplifies things in the limits as well as a few other places. Even if casting to unsigned ints ends up being preferred for code simplicity (if not understandability), I think removing the scaled mickey counters is still a good idea.

Reply 44 of 46, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Interesting patch. I think that in a real mouse driver, there are no floats used for the mickeys/position, but there are fractional movement counters, so it boils down the same thing. The game is happy with a flipping mickey counter ? (when it becomes to large it will now flip).

The patch changes something in dosbox, that I didn't really like (mickeys being changes if you change the mickeys to pixel ratio), so that is a good thing. I recall that Iron Seed uses the mickeys a lot. Got to search my archives to see if it still works.

Water flows down the stream
How to ask questions the smart way!

Reply 45 of 46, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author
Qbix wrote:

The game is happy with a flipping mickey counter ? (when it becomes to large it will now flip).

Seems quite happy with it. An upper and lower limit is no good because if you hit the limit while the pointer is in the middle of the screen it can't go further, but when wrapping around in parallel with a 16-bit sign flip the pointer moves back and forth smoothly across the flip point. Wrapping around the float counters is easier to understand than casting to unsigned int, and has the benefit of keeping the counters from growing and growing, but the end result (i.e. the bitwise content of the return registers) is the same with either approach.

Qbix wrote:

(mickeys being changes if you change the mickeys to pixel ratio)

Indeed, that could happen as it is now, but games tend to change the rates coincident with a reset (which zeroes the counters), so under normal conditions it's probably not a problem.

Reply 46 of 46, by robertmo

User metadata
Rank l33t++
Rank
l33t++

Iron Seed works fine with float_counter_wraparound_2.diff (settlers 2 and 2 gold too)