Drawing histograms

https://akkartik.itch.io/carousel/devlog/708682/drawing-histograms

permalink

The simplest possible dither

"Add noise then quantize."

https://akkartik.itch.io/carousel/devlog/706603/the-simplest-possible-dither

permalink

I've been thinking some more about handling what are essentially merge conflicts when editing my .love files.

As background, you can click 'edit' on my Carousel-based .love files…

… to edit their source code right on your device, whether it's a computer or mobile device.

The question is how to preserve your edits in the face of changes to lower levels: either the LÖVE app or the .love file you're making changes to.

It seems to me one essential constraint of my platform choice is: upgrading the LÖVE app on a mobile device will blow away all installed .love files. Nothing I can do about this, and luckily LÖVE upgrades rarely enough that maybe we can live with that.

But it does mean we can't get too comfortable making edits on a mobile device. With that in mind, I'm trying out the following flow:

• When you edit a file in my Carousel-based multi-file apps like sokoban.love, it highlights the file in red to show that it has local modifications.

  

• Later if you switch to a new version of sokoban.love, you can choose to 'revert' the file and blow away your changes.

  

• You can also 'stash' the file so it won't run but you also still have access to it.

  

• Stashed files receive an immutable version suffix, and get highlighted in a third color.

  

• Stashed files can be unstashed if you want to try them out after making edits.

  

Still klunky, but feels like an improvement. And I'm trying to only show the new complexities when they're relevant, so most people won't have to care about them. Above all, the hope is that the red reminds people to not make too many changes on a mobile device.

And yes, I've been thinking about Ink & Switch all week. Perhaps this needs CRDTs and collaborative editing. But making it more friendly might encourage more changes than this platform can candidly handle, given the restrictions of mobile platforms.

permalink

Of all the apps I've built, perhaps my favorite is https://git.sr.ht/~akkartik/snap.love, my box and line drawing tool. I use it constantly -- including for work. I have a terrible short term memory, and now I make quick mindmaps for every little situation where a full-screen IDE on a huge monitor is too tiny to show all the parts of the codebase I care about right now.

I seldom mess with it, but today I modified it to show gridlines any time I drag things around. Should lead to neater maps!

permalink

All the 1-D cellular automata

Here's every possible rule for a one-dimensional (neighborhood-1) cellular automaton. All on a single infinite surface you can pan and zoom around on your touchscreen device. In 100 lines.

https://akkartik.itch.io/carousel/devlog/702311/all-the-1-d-cellular-automata

permalink

This is quite amazing: a 2D shell

https://www.spinellis.gr/sw/dgsh

permalink

permalink

Sokoban is like Tetris, except you don't know which way is "down". And the "ground" is not flat; the contour lines are seldom straight.

The more challenging puzzles often cause me to rewire my sense of gravity halfway through.

permalink

Improving the UX of Sokoban on a touchscreen using a simple solver.

Tap on an empty tile to move the player there -- if possible! -- without disturbing any crates.

Tap on a crate and then an empty tile to move the crate there -- again, if possible! -- without disturbing any _other_ crates.

All integrated with the infinite undo.

Now I can spend less time juggling arrow buttons on a touchscreen and more time thinking about the puzzle itself: which crate to move next, and where to put it.

permalink

I'm up to level 56. I think 42 was the most satisfying/memorable.

A little thing like an 'edit' button introduces cascading issues:

• LÖVE (in combination with mobile restrictions) won't let me modify code files in place. I have to overlay my changes in a new location.
• But now I can't pick up any upgrades to my app. Upgrades modify code files in place, but any overlay persists (otherwise you'd completely lose your changes after upgrading).
• But hey I have a programmable editor here! I'll just create a new file called 'scratch' with a one-liner to blow away the overlay. (With my app user's hat on, I know in this case my changes are minor in a way that I don't with my app developer's hat on.)
• (A few hours later.) Wait, now none of my changes are having any effect. And they're completely blown away when I go back to the code.
• :face_palm: Oh it's that 'scratch' file still hanging around. So it needs to be a 2-liner. I have to make any changes I want to the file system -- and then delete 'scratch' to make this a one-time operation.
• I could try to create a screen of helpers for this, along with a comment that says, "insert file system operations here" after which is a delete of 'scratch'.

In this way I find myself playing meta-Sokoban.. :eyeroll:

Tl;dr - the 'edit' button isn't really usable yet.

I really don't want to go down the road of building a compare and merge flow :eyeroll:

permalink