Ultimate Amiga
Network Boards => AMOS Language Discussion => AMOS Factory => AMOS Forum => Topic started by: Mia on July 13, 2016, 04:01:53 PM
-
Hi,
I'm having a problem with X Screen(Xmouse) in Hires - it will always give 2 pixels, I cannot make the mouse move 1 pixel - I think this is because the mouse is Lowres on my Hires screen - I've checked but I can't find a way to make the mouse Hires, is it possible?
Thanks,
-
This is a quirk of running Amos with WINUAE you will have to experiment with screen sizes on WINUAE and Workbench
-
This is a quirk of running Amos with WINUAE you will have to experiment with screen sizes on WINUAE and Workbench
Thank you for quick reply, I was hoping it was a problem with UAE and not AMOS - I won't worry about it for now 8)
-
Actually, the Amiga chipsets before AGA couldn't move sprites such as the mouse pointer in anything but low-resolution coordinates on a high-resolution screen. Since Amos only supports OCS and ECS features, getting high resolution coordinates will require you to use some sort of extension that adds either AGA or graphics card support.
-
You could change the default mouse pointer for a custom sprite that may force it to display in hires
-
No. OCS doesn't have a high resolution mode for sprites and ECS only has high resolution sprites in the super high resolution mode which is not supported by Amos.
-
Sam is correct. This is not a WinUAE issue, it is an OCS/ECS quirk. If you need a hires pointer you'll need to roll your own using a BOB. Hide the mouse pointer and each frame read the mouse x and y coords before resetting the mouse position to the center of the screen. Subtract the x and y coordinate of the center of the screen from the x and y coords returned by the mouse functions and you'll get the change in x and y: dx,dy.
You can then move the BOB image "pointer" by dx,dy. This will move the pointer in sync with the mouse, and since the BOB image is the same resolution as the screen it will be hires.
One drawback though is that mouse movement will be half speed in the naive implementation of this. You could do your own mouse acceleration routine, say if dx is less than 10 pixels, use the above routine so exact pixel position is maintained, but if dx > 10 then dx = dx * 2 or some other factor. Do the same for dy.
-
Hi all, thanks,
Sam is correct. This is not a WinUAE issue, it is an OCS/ECS quirk. If you need a hires pointer you'll need to roll your own using a BOB. Hide the mouse pointer and each frame read the mouse x and y coords before resetting the mouse position to the center of the screen. Subtract the x and y coordinate of the center of the screen from the x and y coords returned by the mouse functions and you'll get the change in x and y: dx,dy.
You can then move the BOB image "pointer" by dx,dy. This will move the pointer in sync with the mouse, and since the BOB image is the same resolution as the screen it will be hires.
One drawback though is that mouse movement will be half speed in the naive implementation of this. You could do your own mouse acceleration routine, say if dx is less than 10 pixels, use the above routine so exact pixel position is maintained, but if dx > 10 then dx = dx * 2 or some other factor. Do the same for dy.
Cool, I tried a Bob already, but not the centering idea, thanks I will try this.
I did do some more testing - I got the Gui Extension 2.10 installed but it is also the same if windowed or fullscreen. I have tried with AGA and OCS and ECS machines in FS-UAE, and when trying the RTG screen the mouse is still 2px even at 1440x900 resolution. The pointer is hires but moves 2px. I'm thinking of temporarily ignoring the issue and using the cursor keys to nudge things left or right... ;) and until it's tested on a real Amiga I can't really confirm if it will be a problem.
-
Just for more clarification, further testing shows that ( lowres sprite withstanding ) this is specificaly an AMOS issue as other software like AudioMasterIV do not suffer from it, even though the lowres mouse on top will move 2 pixels you can see the range underneath being selected with 1 pixel with mouse sensitivity moving when the sprite does not. I already confirmed I get 2 pixels even using RTG screens with AMOS so to get around it I ended up using the cursor keys to make it more precise, which is working better than expected.