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)
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!
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.
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…
… 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))