MouseX and MouseY issue...

BlitzMax Forums/BlitzMax Programming/MouseX and MouseY issue...

Arcadenut

(Posted 2005) [#1]

Ok, here is a small little app to demo the issue in question...

Graphics 1024,768
While Not KeyHit(KEY_ESCAPE)
	Plot MouseX(), MouseY()
	Flip()
Wend

If you move the Mouse very slowly, it plots each X and Y, however, if you move the mouse FASTER then you miss a lot of X and Y values. This makes it challenging to deal with Dragging things around on the screen as I miss several X and Y values.

Is there a way to increase the Sampling Rate for the Mouse or is this another issue? Maybe a problem with the code being tied to a VSYNC?

Is there a work around for this?

Rob Farley

(Posted 2005) [#2]

This is the case in ALL languages as far as I'm aware.

Not having BlitzMax it's difficult to suggest the solution, however, are there not mousexspeed and mouseyspeed commands?

Personally I do everything for the X and Y speeds so you can scale the mouse speed if necessary, and drag beyond the limits of the screen.

Robert

(Posted 2005) [#3]

Hi Arcadenut,

If you have the old X value and the old Y value, you can work out the gradient of the line from the old to the new, and generate all of the points in between.

This happens in all other languages as well as far as I am aware.

LarsG

(Posted 2005) [#4]

no, there are no mouse speed commands.. there is, however, an example of a mousespeed routine in the help file under "commands -> system -> movemouse"

regarding the "missing" plots... this is how it just is..
you can work around it by storing the mouse coords when plotting, and then do a line between the old an new coords..
like this:

Graphics 1024,768
Global mx,my
While Not KeyHit(KEY_ESCAPE)
	DrawLine(mx,my, MouseX(), MouseY())
	mx = MouseX(); my = MouseY()
	Flip()
Wend

Sarge

(Posted 2005) [#5]

I think rob is right because most languages i have seen act the same but you may be able to tweak it. The reason for this is when you move the mouse fast it dosent capture the bit it just went over it captures the last one.

Example without mouse

Graphics 1024,768

y=25

While Not KeyHit(KEY_ESCAPE)

	Plot x,y
	
	If x=GraphicsWidth() Then
	x=0
	y=y+20
	Else
	SetColor Rand(0,255), Rand(0,255), Rand (0,255)
	x:+4
	EndIf
	
Flip
Wend

FlameDuck

(Posted 2005) [#6]

Is there a way to increase the Sampling Rate for the Mouse or is this another issue? Maybe a problem with the code being tied to a VSYNC?

A combination. The sampling rate of MouseX() / MouseY() is tied to how often it is called. Thus if your code is tied to the vertical sync, your sample rate would be whatever the vertical sync frequency is.

However, I don't really see the issue here. Since you're only updating the screen x times, what good would it do you to sample the mouse speeds >x times, when you won't be able to create a visual reference to the pointers location? This isn't the Amiga unfortunately. :o>

ImaginaryHuman

(Posted 2005) [#7]

I am thinking it is more likely that the hardware of the mouse updates a given piece of memory with the changes in its movement and this probably happens at a fixed rate. It is then up to the application to poll that memory at however many intervals to get the result. I think that if you were to poll more often you would start to see repeated values rather than inbetween values, but I could be wrong.

Like someone else said, this is normal. If you move the mouse you are moving it more than one pixel every frame, so your loop is going to skip over some pixels. You would have to interpolate between the old position and the new position. Some people even go so far as to identify each plot as a point on a spline, so that the curvature is pretty smooth, otherwise drawing lines from dot to dot (even without plotting the last pixel) usually produces some unwanted artifacts. For example, when a line begins to be drawn it is likely that the first `ramp` (ie the y coordinate changes by 1 or something) will appear either at the start of the line, or the algorithm might center the ramping .. either way you won't get a totally straight looking line even if the start and end coords are lined up.

You could look into using a simple bresenham's line algorithm, it uses simple integer math, and just carry over the values from the previous piece of line to the next line with new values.