about summary refs log tree commit diff stats
path: root/drawing.lua
Commit message (Collapse)AuthorAgeFilesLines
* stop caching startyKartik K. Agaram2024-06-111-50/+57
| | | | | This is quite useful because I used to have a long list of places in which to invalidate the cache.
* use editor state font for width calculationsKartik K. Agaram2024-01-121-2/+2
|
* audit all assertsKartik K. Agaram2023-11-181-18/+10
| | | | | | | | | | | | | Each one should provide a message that will show up within LÖVE. Stop relying on nearby prints to the terminal. I also found some unnecessary ones. There is some potential here for performance regressions: the format() calls will trigger whether or not the assertion fails, and cause allocations. So far Lua's GC seems good enough to manage the load even with Moby Dick, even in some situations that caused issues in the past like undo.
* assume starty can be nil in updateKartik K. Agaram2023-09-151-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a backport of a bugfix in pensieve.love. It's not _technically_ a bug here in lines.love, but it seems worth establishing an architectural invariant (or rather lack of invariant). LÖVE's standard event loop performs the following sequence of operations in a single frame: * process events * update * draw Ideally any mutations to global state happen during the first two phases, while drawing includes no mutation. However, there is a special case: `starty`, the top y coordinate for each each line in the editor. This is used all over the place, and the cheapest way to compute it is to simply save it while drawing. However, draw by definition only updates `starty` for lines that are drawn on screen. To avoid stale data on lines off screen, say after scrolling, events often clear `starty` for all lines, leaving it to the next draw phase to repopulate the right lines. Sandwiched between the above two "however"s, the update phase needs to gracefully handle `starty` being nil in the occasional frame right after an event. I think I've audited all our uses of `starty`, and this commit fixes the only place that violates this rule.
* clean up a slight jitter when drawing circlesKartik K. Agaram2023-09-151-1/+2
| | | | | | | | | | Earlier the ghost while drawing wouldn't quite match the final shape. Now the math is identical in draw_pending_shape. It's a little unfortunate that we have this duplication of formulae. At least there are no other stray calls of App.mouse_x in draw_pending_shape.
* App.width can no longer take a TextKartik K. Agaram2023-04-011-5/+4
| | | | | In the process I discovered the horrible fact that Text.x allocates a new Text. And it gets called (just once, thank goodness) on every single frame.
* consistent names in a few more placesKartik K. Agaram2022-12-231-1/+1
|
* make love event names consistentKartik K. Agaram2022-12-231-4/+4
| | | | | I want the words to be easy to read, and to use a consistent tense. update and focus seem more timeless; let's make everything like those.
* dedup points while loading drawing from diskKartik K. Agaram2022-09-031-5/+0
|
* distinguish consistently between mouse buttons and other buttonsKartik K. Agaram2022-08-231-2/+2
|
* bugfix: imprecision in drawingKartik K. Agaram2022-08-031-0/+3
| | | | | | | | | | | scenario: slowly press down mouse button and drag to draw a line release mouse button Before this commit the point would jump just a little bit on release, and points would go slightly to the left of where I expect. Yet another thing it's hard to write an automated test for.
* round one coordinateKartik K. Agaram2022-07-301-1/+1
|
* round coordinates to integers in a few placesKartik K. Agaram2022-07-291-7/+11
| | | | | | | | | | | | | Thanks Lion Kimbro for pointing out this issue. I still have to use floats for start/end angles of arcs. That might be a sign that I don't have the right serialization yet for them. Or that that feature needs to go. I started out with a hazy idea of only using 8-bit ints for coordinates, but now I'm not sure how committed I am to that constraint. While the width is always 256 units, it might be nice to create long portrait drawings at some point, whose height is greater than 256 units.
* bugfix: online helpKartik K. Agaram2022-07-221-2/+2
| | | | Broken in the commit before last.
* move drawing.starty into line cacheKartik K. Agaram2022-07-201-46/+57
|
* a more radical attempt at ignoring nil y'sKartik K. Agaram2022-07-131-4/+0
|
* no, bring back that defenseKartik K. Agaram2022-07-131-0/+4
| | | | | | | | | Scenario where I ran into it: start a stroke inside a drawing press 'o' to switch to circle mode (but any mode switch will do) The problem is that Text.textinput unconditionally blows away all .y values. Sometimes we have to wait for a draw() to fill them back in.
* a bug I've never run intoKartik K. Agaram2022-07-131-3/+0
| | | | | | The previous commit was failing inside a test that I can't reproduce manually. Perhaps it's something about how often draw/update run in practice. Anyways, it's definitely uncovered a real issue.
* hoist couple of variables outKartik K. Agaram2022-07-131-3/+6
| | | | This seems to uncover a corner case I'd never run into until now.
* use available variablesKartik K. Agaram2022-07-131-1/+1
|
* more idiomatic variable namesKartik K. Agaram2022-07-131-5/+5
|
* chunking by simple local variableKartik K. Agaram2022-07-131-4/+6
|
* make local functions look differentKartik K. Agaram2022-07-131-6/+6
|
* more chunks, same approachKartik K. Agaram2022-07-131-3/+6
|
* chunk up some long linesKartik K. Agaram2022-07-131-32/+32
| | | | | Hopefully this is more approachable. Though now I'm creating two new temporary functions on every draw. Whether I need them or not.
* drop final mention of state global beyond main.luaKartik K. Agaram2022-07-121-29/+28
| | | | | | | | | | This is all unfortunate in several ways - lots of functions have extra args - table lookups where we used to have a simple variable - program initialization is a lot more delicate Let's see if it was worthwhile. Can we now actually build around the editor component in forks?
* replace globals with args in a few functionsKartik K. Agaram2022-07-121-71/+74
| | | | | | | | | - Drawing.draw_shape - Drawing.draw_pending_shape - Drawing.in_drawing - Drawing.find_or_insert_point - Drawing.near - Drawing.pixels
* correct a mis-named thresholdKartik K. Agaram2022-07-121-2/+2
|
* drop heavyweight near check on file load/storeKartik K. Agaram2022-07-121-19/+25
|
* left/right margin -> left/right coordinatesKartik K. Agaram2022-07-121-34/+34
| | | | | Editor state initialization now depends on window dimensions, so we have to more carefully orchestrate startup.
* add state arg to a few functionsKartik K. Agaram2022-07-121-25/+25
| | | | | | | - Drawing.current_drawing - Drawing.select_shape_at_mouse - Drawing.select_point_at_mouse - Drawing.select_drawing_at_mouse
* add state arg to few functionsKartik K. Agaram2022-07-121-2/+2
| | | | | | - draw_help_without_mouse_pressed - draw_help_with_mouse_pressed - current_shape
* add state arg to Drawing.updateKartik K. Agaram2022-07-121-7/+7
|
* add state arg to Drawing.drawKartik K. Agaram2022-07-121-15/+15
|
* add state arg to Drawing.mouse_releasedKartik K. Agaram2022-07-121-20/+20
|
* add state arg to Drawing.keychord_pressedKartik K. Agaram2022-07-121-32/+32
|
* add state arg to Drawing.mouse_pressedKartik K. Agaram2022-07-121-15/+15
|
* group all editor globalsKartik K. Agaram2022-07-121-94/+94
| | | | We're still accessing them through a global. But we'll change that next.
* make colors easier to editKartik K. Agaram2022-07-111-7/+7
|
* stop pretending globals are localKartik K. Agaram2022-07-111-4/+0
| | | | | One advantage of this approach: we don't end up with multiple lexical scopes containing duplicates of the same modules.
* make freehand drawings smootherKartik K. Agaram2022-07-051-1/+17
| | | | | | | | | | | | Now I might actually use them more, and maybe I can start considering taking out some shapes. Do I really need circles if I don't provide ellipses? Thanks Ivan Reese for the feedback. "What drawings does your tool encourage?" Minor note: taking out the deepcopy creates a cute little string like effect, where the curve grows tighter the slower you draw it.
* bugfix: 'escape' to cancel a strokeKartik K. Agaram2022-07-051-1/+6
| | | | | | This has been broken since commit b544e8c357 on May 17 :/ I'm just undoing that commit, which turns out to be completely unnecessary. And adding a test.
* right marginKartik K. Agaram2022-06-301-7/+7
|
* rip out notion of Line_widthKartik K. Agaram2022-06-301-7/+7
|
* keep drawings within the line width slider as wellKartik K. Agaram2022-06-221-7/+7
|
* clean upKartik K. Agaram2022-06-171-17/+0
|
* more precise shape selectionKartik K. Agaram2022-06-171-0/+17
| | | | | | | It's important that the error be additive rather than multiplicative, otherwise the area grows asymmetrically along a line. Hopefully freehand drawings will work more intuitively now.
* correct commit f3abc2cbf2Kartik K. Agaram2022-06-171-7/+22
| | | | | | I can't be trusted to do anything without a test. This should fix #5. Please reopen if it doesn't.
* better handle moving pointsKartik K. Agaram2022-06-171-0/+5
| | | | | This should hopefully address #5. I'm removing some constraints from manhattan lines, rectangles and squares.
* dead codeKartik K. Agaram2022-06-151-45/+0
|
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2024-11-15 16:02:21 +0000