Protocol says x, y, pressure are unsigned, but in implementation they are signed



  • Hi,
    I am writing a Windows 10 client for your server, to draw with a Surface Pro. It's all going quite well, but something I have noticed is that even though your protocol doc says x,y,pressure are in the range (0, 2^16], they are actually in the range (0, 2^15]. Is there any reason for this, or is it likely to be changed in the future? I've done a quick hack on the server code, and changing to unsigned short and USHRT_MAX has everything working beautifully. My gut response is that more precision is always good, but I can work with whatever. So, will the protocol ever use the full range as documented?
    Cheers
    Jarrad


  • developer

    Hello,

    I'm sure a Windows 10 client would be cool for many Windows users out there. Please let us know when you have something so that we can link at it!

    I have noticed is that even though your protocol doc says x,y,pressure are in the range (0, 2^16], they are actually in the range (0, 2^15].

    From doc/protocol.txt:

    1 word pressure (using full range 0..65535, 32768 == pressure 1.0f on Android device)

    So 32768 is used when Android returns a pressure of 1.0f. See MotionEvent.PointerCoords.html#pressure docs:

    The pressure generally ranges from 0 (no pressure at all) to 1 (normal pressure), although values higher than 1 may be generated depending on the calibration of the input device.

    Android may return values higher than 1 in some cases. This is why I have left the "reserve" > 32768.



  • Yep the reserve for pressure makes sense, but the coordinates are also interpreted as having a max value of 32768, not 65536. This is because the server code interprets these values as signed shorts, not unsigned shorts, and uses SHRT_MAX as the maximum to normalize with, not USHRT_MAX.
    I'll definitely share once it's completed. :)


  • developer

    @Akdor-1154 said:

    Yep the reserve for pressure makes sense, but the coordinates are also interpreted as having a max value of 32768, not 65536. This is because the server code interprets these values as signed shorts, not unsigned shorts, and uses SHRT_MAX as the maximum to normalize with, not USHRT_MAX.

    Indeed, it should interpret the values as an unsigned short and normalize to USHRT_MAX/2.


Log in to reply
 

Looks like your connection to Bitfire App Forums was lost, please wait while we try to reconnect.