Why normalized space with desktop stuff?

So I will complain about multiple things here regarding how vvvv officially deals with mouse input and desktop coordinates systems because I got fed up this day after dealing with/avoiding them for at least a year or so (or even more when did that observer pattern got implemented), and why I duplicated most of these nodes which might be simpler but do the job so much better.

normalized desktop sizes: why use normalized space on desktop/windows related positions? what’s the problem with pixels (top-left: 0, bottom-right: screen resolution) (this btw haunts me even since I’ve started looking at vvvv 10 years ago)

I have 3 monitors with extended desktop with this setup: LEFT, PRIMARY, RIGHT (no eye-finity or surround because that makes windows go crazy with GUI element sizes)

problem 1:
mouse (desktop) vs cursor pixel position (where 0 is top-left of PRIMARY)
X = -1 is left of primary as seen here:

and 1 is umm… errr… hmmm it’s not even reachable??? (cursor is on right edge of the RIGHT monitor)

alright where’s the center then? it looks like on the center of my RIGHT monitor (not the primary one) interesting…

after this I’m not surprised about the left edge of the LEFT monitor

and my display arrangement is plain simple horizontal, imagine the horrors of this coordinate system when using displays which has minus vertical offsets too!

problem 1.1:
to make things worse some old delphi window/cursor manipulation nodes operate on a completely different “normalized” coordinate system. In official Window (Windows) and Cursor (System) only the primary monitor has the -1 to 1 range and anything else is outside of that range (which tbph makes slightly more sense than the coordinate system of the new mouse desktop node, still worse than pixel space). “Thank god” newer sink nodes use the above stupid coordinate system.

problem 2:
raw mode doesn’t help in anything.
It would be useful if it would behave like DirectInput or RawInput mickies. so where’ever my cursor is on my desktop it would output the distance traveled by my physical mouse since the last frame. But since it’s incremented and multiplied internally which then is clamped between -1 and 1 it’s useless! that range doesn’t even follow the stupid normalized system (the actual range travels around) because probably the whole thing is still based on mickies. If I can know that my mouse’s device name is “@msmouse.inf,%hid.mousedevice%;HID-compliant mouse” why can’t I have the raw mickies? :P that would make my old and crappy DirectInput node finally obsolete…

problem 3:
… oh yeah which btw breaks both Mouse (Desktop) + Keyboard (Desktop) node without throwing any exceptions (I only discovered this lately and I was always puzzled why Mouse/Keyboard (Desktop) nodes wouldn’t work “random” times, well that’s why). It won’t even recover after I reinitialize the those nodes. on the contrary: my plain simple DirectInput node doesn’t break when creating multiple of them OR creating a Mouse/Keyboard (Desktop) node, in the rare occasions when it does break you can reinitialize them.

Because of this camera modules behave clunky and unexpected sometimes with the cursor, can’t do infinite FPS game like rotations (with official nodes) (unless they set cursor to cycle but boy that’s so hacky), after interaction cursor is miles away at a random position and so on. first world problems, but causes much much confusion for the less savvy and even for the involved ones can cause brain cancer.
Pixels it is! Use pixels :P just makes life so much easier and less confusing.

(also sidenote: Observer based DeviceEvents split nodes enqueue mode why can’t it behave like UDP/TCP spread mode? popping only one event/frame can cause huge latency on slower framerates (like below 40 FPS))


But pixels can be tricky if you go from one setup to another, unless you map your coordinates back to normalised?
Part of it at least is that multi monitors aere broken in windows and always have been. The numnber of times Ive used identify monitor only to discover that the numbers are incorrect, and will be differently incorrect if you the system prefs rather than the manufacturer prefs. Use Eyefinity and its even worse, I;ve seen the numbers change on reboot, layout stays correct, but the windows prefs and eyefinity report different numbers.


well I’ve never experienced that yet, that might be vga wise problem though but you can rely on ScreenInfo node which is damn powerful. If you need a normalized system for some weird reason make yours which makes sense for your situation. it’s like 2 divisions and additions 2nd grader math not rocketsience. but if done under the hood inconsistently that can make a developer butthurt


hei microdee,

the unconvenient truth about the troubles you’re seeing is that we haven’t implemented the mouse-nodes with multimonitor support in mind.

the simplest solution probably indeed would be to at least offer an optional PixelXY output (as we already have it in VL!)… will put that on the list…

otherwise you do realise that the mousenodes are opensource, right? sou…


yeah probably will look that up and expose lower level stuff


forgot to mention: Mouse (Devices Window) and Mouse (Devices Desktop) now have additional Position in PixelXY and Client AreaXY outputs in latest alphas.