New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Axis locking bugs #68

Closed
Viza74 opened this Issue Aug 2, 2018 · 9 comments

Comments

Projects
None yet
3 participants
@Viza74

Viza74 commented Aug 2, 2018

  • "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

This comment has been minimized.

Show comment
Hide comment
@Esshahn

Esshahn Aug 3, 2018

Collaborator

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.

Collaborator

Esshahn commented Aug 3, 2018

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

This comment has been minimized.

Show comment
Hide comment
@Viza74

Viza74 Aug 3, 2018

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. :)

Viza74 commented Aug 3, 2018

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

This comment has been minimized.

Show comment
Hide comment
@Esshahn

Esshahn Aug 3, 2018

Collaborator

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?

Collaborator

Esshahn commented Aug 3, 2018

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

This comment has been minimized.

Show comment
Hide comment
@Viza74

Viza74 Aug 3, 2018

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

Viza74 commented Aug 3, 2018

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

This comment has been minimized.

Show comment
Hide comment
@nurpax

nurpax Aug 3, 2018

Owner

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.

Owner

nurpax commented Aug 3, 2018

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

This comment has been minimized.

Show comment
Hide comment
@nurpax

nurpax Aug 3, 2018

Owner

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.

Owner

nurpax commented Aug 3, 2018

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

This comment has been minimized.

Show comment
Hide comment
@nurpax

nurpax Aug 3, 2018

Owner

@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.

Owner

nurpax commented Aug 3, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@Viza74

Viza74 Aug 3, 2018

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

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

Viza74 commented Aug 3, 2018

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

This comment has been minimized.

Show comment
Hide comment
@nurpax

nurpax Aug 3, 2018

Owner

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.

Owner

nurpax commented Aug 3, 2018

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.

@Esshahn Esshahn added the bug label Aug 4, 2018

@Esshahn Esshahn added this to the 0.3 milestone Aug 4, 2018

nurpax added a commit that referenced this issue Aug 4, 2018

@nurpax nurpax closed this in ea209f1 Aug 4, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment