Originally Posted by
MattRage
We have been looking in to this but there are some tricky issues relating to the range of input standards required to run on a variety of Windows devices at the moment. ArtRage supports Wintab (the older standard used by the majority of machines in the fairly recent past and machines that do not have a screen input device), and Realtime Stylus (the Microsoft standard that they adopted after abandoning their previous half completed Ink Services standard). It looks like the Realtime Stylus standard, which was also partially completed, is basically being abandoned again however.
As a small company that has as wide a range of users as we do it's hard to maintain support for the various standards that are being invented, half finished, abandoned, and replaced at the rate it's happening on Windows. Wacom's drivers theoretically support Realtime Stylus so we'll be told we can abandon Wintab but that's simply not feasible because a) Many of the devices running ArtRage don't work well with RTS, and b) The Wacom 'Windows Ink' option on Win7 causes Microsoft's 'pulse at input point' to trigger unless you registry hack and prevents correct functionality of right clicks in some cases. The two standards also compete with each other when running Windows Ink from the Wacom driver and that confuses input in ArtRage.
Reliable touch rejection on the Surface is mainly possible right now thanks to some changes MS have made in the Windows Ink standard (the other new one I mentioned) and at the moment we're not working with that directly because it's a Windows 10 standard (possibly Windows 10 Anniversary only, I need to confirm this) and as such is used by a minority of the machines we're working with, there are also some issues with drivers for this standard currently, especially when you're also working with other standards. Before Windows Ink was implemented it was possible to fake touch rejection by rejecting 0 pressure strokes, but we work with 0 pressure strokes for mouse input (something a larger company who is writing software to showcase a touch screen may not care about) and we've also seen plenty of cases where a tablet sends data with 0 pressure due to driver oddities, so we've not gone down that road. We've also been talking to some driver developers who have suggested that the driver may start handling this kind of thing internally, which would immediately invalidate any time we spent on it anyway so we're waiting for more info on that.
So, to summarise: A larger company can cope with the standards rollercoaster more easily, they just write another input system for the new standard, but that's a lot of work for a relatively small percentage of users so it's harder for us to adapt in the same way. We want to do touch rejection because it makes sense for users with touch input PCs, but our development efforts are currently focused on features for all users so we don't have the bandwidth right now to completely rewrite the input system. It's not a pleasant thing for me to have to say, because I don't want to give the impression that we don't care (we do!), it's just a practical reality of being a small company in an environment where the OS vendor keeps deciding to change things under you and expects you to keep up. As soon as we get some time to look in to it further we will, we just have to prioritise development time in other areas right now.