Conversation
Simpler cursor algorithm uses integer arithmetic truncating ability to accomplish this in a simpler fashion.
Rather than hardcoded magic number, is derived from pound-define for joystick output range. SO thankfully dredged up C-spec section 6.10.3.4 as a reference for this being allowed.
| * The type of these are uint16_t in hopes that the struct will be small. | ||
| */ | ||
| struct spatial_pos { | ||
| uint16_t x; |
There was a problem hiding this comment.
If we want to save space these should all be uint8_t
Since it doesn't look like our display is going to be bigger than 100x100 and with 'uint8_t's we are able to save space while being able to represent all possible values, and not worry about overflowing when we compute the next position. Unless our joystick units per pixel conversion tends to give us incredibly large numbers.
There was a problem hiding this comment.
My reasoning was initially making them as large as possible while the struct could still plausibly fit in a register.
Another interesting thing is that everything in the tft lirbrary, thus rendering, which is just a hacky port, uses shorts for coordinates, which are guaranteed by our compiler docs to be 16 bits. This means from uint16_t to unsigned short is a type conversion but not a size one. I don't really know how to deal with this kind of numeric type shitshow cleanly, so maybe this size-coincidence is a non-factor, idk.
There was a problem hiding this comment.
So I guess this raises a few questions:
- Is it realistically possible to not use shorts, other for interactions with the tft library?
- If so, what exactly happens when we type convert from a uint8_t to a short
- And do we want to add this complexity to save space?
I'm fairly certain casting our uint8_t to a short would not be trivial, since the short is signed(?) and there may be overflows then. I'm not sure how much overall complexity that adds to our system though, and since each byte saved gives us another pixel, its tempting to switch.
I'm not certain either way, since I'm not sure realistically how many pixels this would actually save, and whether or not it is worth the time to change this further based on the amount of potentially saved pixels.
I'd like to see what @ipburbank thinks, but since I'm undecisive I'm going to approve this and leave the decision up to you.
There was a problem hiding this comment.
I'm not sure what the spec says, but I think I know what will happen on our platform. If the signed number is positive and the representation is the same size, it will convert successfully to unsigned. I think that the spec guarantees something like this, but again the details are tricky.
| * | ||
| * The type of these are uint16_t in hopes that the struct will be small. | ||
| */ | ||
| struct spatial_pos { |
There was a problem hiding this comment.
A cartesian point can be negative, these cannot
3 participants
Cursor movement, but not drawing lol. Replaces #17