screenwidth/height question

[sobeach]

The following script was posted for IL2 that moves the mouse when playing in 1024 x 768. I play in 1280 x 1024 so I would like to change the script but I do not understand the screenx and screeny lines as they do not seem to follow the manual.

Game Title: IL-2 1946
// Written By: Kevin Watts
// Date: 28/12/06
//


SEQUENCE //********MOUSE POINTER MOVE SCRIPT*********
WAIT( JS2.B2 OR JS4.B17 ); // Wait for button 2 to be pressed on the PT or button 18 on the MFP
DELAY( 3 ); // Wait approx an eighth of a second
SCREENX=(SCREENWIDTH*88)/100; // Move cursor to map pop up window
SCREENY=(SCREENHEIGHT*26)/100;
DELAY( 3 ); // Wait approx an eighth of a second
WAIT( JS2.B2 OR JS4.B17 ); // Wait for button 2 to be pressed again on the PT or button 18 on the MFP
SCREENX=SCREENWIDTH; // Move cursor out of view
SCREENY=SCREENHEIGHT;
DELAY( 3 ); // Wait approx an eighth of a second
ENDSEQUENCE
endScript

I am confused on the *88/100 and the *26/100.
thanks

[Bob Church]

Hi sobeach,

It calculates 88% of the current screen width in pixels from the left and 26% of the screen height in pixels from the top. It's oddly written to maintain accuracy, first the top of the fraction is multiplied to make the value bigger, then that is divided by the bottom. If you write it as:


SCREENX = SCREENWIDTH * 88 / 100

it's free to calculate in any order. The way the math processor works in the CM, it ends up processing the "88 / 100" first, that produces something less then "1", and the only thing less than one is "0". It's integer math, no fractions. The calculation would always produce "0" and the cursor would always go fully left (top/left is 0,0). Likewise the vertical calculation. With the parentheses it's forced to do the multiplication first, so you get something like 88 * 1024 on top, 88,000 and something, that's divided by 100. Revvin is just trying to let it modify itself to account for differences in screen sizes. So long as the screen is just a scaled version of the same picture and the point you're trying to hit isn't too critical, it works okay.

When there's any ambiguity, parenthesize. They don't cost you anything, they're only processed during the download, they're gone when the script runs, and without them you can get some strange results.

Hope this helps,

- Bob

The StickWorks
http://www.stickworks.com

[sobeach]

Thanks for the reply. I think I understand the explanation. Was this in the manual?

[Bob Church]

Hi sobeach,

I don't know. A quick check didn't turn up anything except for a brief mention in some (not really relevant) information in the section on the TrackBall. It's been discussed here before several times, mostly in conjunction with scaling axis values.

It's easy to see what happens, really. If you write it without the parentheses like I did above:


SCREENX = SCREENWIDTH * 88 / 100;

you've left the calculation order to the whim of the compiler. It's not really whim, it will always do it the same way, but it's difficult to know beforehand which way it will go. If it does the division first (and I think it will in this case), then the 88/100 returns 0 and the multiplication becomes:


SCREENX = 1024 * 0;

which is just plain "0" and always jams you fully left.

When you put the parentheses in, you force it to do the multiplication first. It makes the number bigger before it makes it smaller. "SCREENWIDTH * 88" gives you 90,112 so the division calculation is:


SCREENX = 90112 / 100;

That's truncated too, but only by 0.12 and the final SCREENX value ends up at 901.

The CM uses 32-bit signed integers internally, so intermediate values during calculation can take on values in the range +/- 2,147,483,647. That gets limited to the range 0..255 if you try to send the value to a CMS Controls axis, but right up to the point where it gets sent you've got plenty of "headroom" to hold on to the accuracy. That doesn't really apply here anyway since SCREENX isn't being passed through a CMS Axis and I don't recall limiting it otherwise. Windows itself will limit it to the screen size when it gets there of course, but that's nothing to do with the CM.

Best regards,

- Bob

The StickWorks
http://www.stickworks.com