mirror of
https://github.com/Bubberstation/Bubberstation.git
synced 2025-12-11 10:11:09 +00:00
7f95f61430
## About The Pull Request First update to the crappy paintings UI I've done in over a year, that I wanted to do it since then, but then I got caught up with the fishing feature. <details> <summary> verbosely explained data size related issue fixed</summary> First and foremost, this PR fixes an issue with the size of the data sent to topic when drawing. For those who don't know it yet, 516 has introduced a size limit of 2kb for topics, which means anything hitting that limit is fucked. Thankfully, Y0SH1M4S73R is working on a way to split the data in chunks. However, what does this have to do with drawing on a canvas? For starters, everytime onmousemove is called while the drawing prop is set to true, point data is pushed in the modifiedElements array, BUT it doesn't check if a point data object with the same x and y values is already there, meaning you can move the mouse back and forth two points of the raster/canvas/whateveryouwannacallit or even inside one point and the array will grow until it reaches the aforementioned limit. Furthermore, there's also an unused prop in the PointData type which only makes this worse. Thankfully, all I had to do Implementing the some() method in a conditional check that prevents point data from being instantiated and pushed if there's an instance with same x and y. </details> Moving on, this PR adds a bucket tool to the UI. By enabling it you can click on a point/square/pixel and it'll fill a same-colored area with a new color, much like how it's done in actual painting softwares. <details> <summary> verbose pseudo-technical rant</summary> The algorithm for it is based on the DM side of the code, although I reckon this is a suboptimal decision, just because there can be a small 1-2 seconds delay between clicking, topic stuff and re-rendering. It is not a major problem but it could be as well scoffed at. The dm proc employs a span filling algorithm, which works with constant x to reduce time spent accessing each position of the array, at the cost of code complexity. The algorithm uses queues, meaning sections on the same x will be handled first, then move to the next x. This is kinda my first time wrapping my head around this sort of things, so apologies if some of the code or comments are nighttime-coding levels of bad. </details> Both bucket mode and grid can now be toggled by key shortcuts with F and G respectively. This will cause some conficts with key bindings on those places if you have them however. If there's a way to prevent standard keybind functions through signals or whatsnot while the UI is open, please tell me. I can perhaps search for a solution to it myself later but I've already done so much. Also I don't want to assign keybinds to them, thank you. The canvas UI is still quite primitive frankly, so it'd be overdoing it. This PR also fixes observers/viewers not being able to zoom in/out regardless of distance, because it didn't work to begin with! My fault! ## Why It's Good For The Game Fixing issues with painting UI/UX. ## Changelog 🆑 fix: Fixed an issue with paintings related to 516. You should now be able to paint larger strokes again. fix: Fixed ghosts and other non-adjacent viewers not being able to zoom the canvas in and out. add: Added a bucket tool to the canvas UI to fill larger areas. You can find the button for it beside the one for the grid. qol: You can toggle the canvas grid and bucket tool with the G and F key respectively. /🆑