Axis locking bugs

[Viza74]

• "Shifted" line: if you try to draw an axis locked line, but the cursor leaves the starting character position at the corner, the line shifts one character next to the starting pos. Hmm, I'm not sure if it is understandable with my english, heres a drawing:

starting pos> x xxxxxxxx

• If you move the cursor fast (not even needs to be too fast) there are gaps in the drawn line. That's actually a problem with the regular draw tool too. I would except a continuos line if I hold the mouse button down.

[Esshahn]

A typical issue found with drawing programs are the gaps. They come from mouse acceleration, meaning that the mouse actually never was on that spot. A solution is to always draw the vector from x1,y2 to x2/y2, which other apps do to solve that. It does consume more performance though.

[Viza74]

While technicaly true that it would require more cpu resources, I seriously doubt that calculating and drawing a 40 pixels long (at worst case) line every frame would make any noticable effect on performance, so it is more of a UX/useability question... :)

What is surpring to me with this issue is that it shows up at pretty moderate mouse speed - which would suggest very low sampling = very low update framerate in the app. Is the app already that slow? I don't see any reason why it should be, but if it is, than yeah, this could be a performance issue. :)

[Esshahn]

True. Canvas operations are usually handled at 60fps, not sure for Petmate, but true for Spritemate (http://spritemate.com/) at least. What happens when you reduce your mouse acceleration in the OS?

[Viza74]

My mouse acceleration settings are MacOS defaults, and I don't notice any changes in this gap-issue if I zero it with a util (except that I have hard time clicking accurately on things, because I so used to the default settings :) )

But IMHO this is not the question we should be asking here, because it suggests that the fix should be lying on the users side, which is - apart from rare corner-case users - is not a nice solution from a tool...

If I may suggest something (more work, sorry :) ) that fixes this issue, adds more functionality and simplifies the program at the same time:

If in any draw mode (character or colorize) and the mouse moves

• if the shift key is NOT held
  • draw a line between the previously stored and new coords
  • store the new coords to the previous ones
• else if the shift key IS held
  • draw a new line in preview mode between the previos and new coords ("preview mode" is the way like now it works when you are not holding the mouse button - the character/color is drawn under the sursor, but not stored to the canvas array yet)
  • DO NOT update the previous coords

So the users are free to adjust the line while holding the shift in any way they want. Releasing shift commits the changes to the drawing. Theres no gaps in the drawing regardless of the state of shift key. Of course this is not axis lock any more... while it maybe minimally harder to draw horizontal/vertical lines, since you do not commit until releasing the shift, I don't see it as a problem, and you gain the ability to draw lines at any angle (which is kinda minimally usefull in petscii, but sometimes can be handy, and the 45 degree angles are).

[nurpax]

IMO drawing a line between two mouse points makes sense and that’s what I’ve been planning to do eventually, just didn’t get to doing that yet. :)

Most paint programs tend to so this so IMO Petmate feels a bit off now that it leaves those gaps.

Fortunately it’s a pretty easy thing to do in my code.

[nurpax]

By two mouse points I mean just drawing a line between two mouse move events. Not a general line drawing, although of course the code could be reused for a line drawing tool too.

[nurpax]

@Viza74

"Shifted" line: if you try to draw an axis locked line, but the cursor leaves the starting character position at the corner, the line shifts one character next to the starting pos. Hmm, I'm not sure if it is understandable with my english, heres a drawing:
starting pos> x
xxxxxxxx"

Mind posting a screencap video? I tried to understand this and repro, but in my quick testing it works as I intended it to work.

The snap to horiz or vert is based on char position x0,y0 changing to either x0+-1,y0 or x0,y0+-1. x0,y0 are character positions, e.g. actual screen coordinate divided by something like 16.

[Viza74]

Sure: https://drive.google.com/open?id=1ID64aBB3zB0Hh3PBplGriTw76OUgXFba

...but no need to fix that if you just use my line-connector suggestion from above :)

[nurpax]

Thanks! I was able to repro too now. Yes, it's definitely a bug.

If it's an easy fix, I'll probably just do it, even if I decide to do something more complicated like what you talk about above.