You may also have to set DIPROP_AXISMODE to DIPROPAXISMODE_ABS. It's been a while, and I've misplaced the code I was working on.
But DIPROPAXISMODE_ABS definitely produces nothing but garbage on it's own.
D.
It's not
exactly garbage, and needs "decoding".
IIRC, DIPROPAXISMODE_ABS outputs a 32 bit value with no "real" zero point (unless the mouse driver is absolute in win9x with non-system USB mice devices, aka lightguns). The funny thing is the absolute value is the total from the time
windows (and mouse) was installed, and the system mouse is the sum of all mouse devices. (Err, that's my guess, and it seems that way for at least new USB mice in win9x, and the one winXP I got to see the DIPROPAXISMODE_ABS values right after installing and then a month later.) So most of the time you aren't going to be even close to zero, but in the
billions.
Now, If you take the value at enum, and call that is the "zero point" (subtract it from subsequent "current" values), you can get valid readings for a while. Until the mouse pointer goes of the edge and you can't see how far off, or the exact direction unless exactly above/below/left/right. Then you need to re-set the "zero point". (That's basically one of the two directInput ways "lightguns" were handled in analog+.)
It is possible to write code to move the "zero point" to cover the inevitable move off screen instead of the way I did it, but that's just re-undoing what the OS and directX is doing to put it into DIPROPAXISMODE_ABS.
But the hack that messed me the most was the mode needed to be set, IIRC, after the enum function, but while not acquired. I hacked it into the pause acquire/unacquire code to get it to work.
These observations are from (system & individual USB mice) win98, winME, & (system mouse only) winXP systems back when analog+ was still active.