Week #4

Version Control #1 / Iterative Patterns #2

Part 1: Practice

Decode #1

OriginalModified

  1. The canvas is going to take up the whole screen, and adjust itself if the size of the window changes.
  2. The sketch will have a white background, and shapes with black stroke.
  3. On a grid whose cell size is 1/10 of either the width or the height of the screen (the smaller of the two), squares will be drawn in such a way that each would be rotated a little bit more the than the previous one, and create a gradually increasing rotation amount.
  4. The change in rotation angle between each two squares won't be the same, but a random amount within a range of a negative and a positive number (it is the same number) that is becoming slightly larger in each loop, hence the eventual gradual increased rotation.
  5. All of this would only happen once.

Decode #2

OriginalModified

  1. For each cell in a grid, two squares will be drawn as follows: one set of squares will be drawn with increasing gaps in between the squares. The other set of squares will actually be 5 squares drawn within the boundaries of the first square, but with a small offset and a smaller size.
  2. The sizing is relative to the dimensions of the canvas, whose dimensions take up all of the window's available width and height. (I try to use an actual number, like 400, and go through all the variables based on that to get a feel of how things will look like. That hard coded 80 seems like a lot — it means total is like 5, and then sqSize is 80, and sizeDifference is a weird 13.333 — and so I know there's going to be (for a given 400px wide window) 80px squares with 5 more squares inside of them, each of which is around 13 px smaller than the next one.
  3. All of this only runs once, drawn from the center of the squares, just black stroke on white background.

Decode #3

OriginalModified

  1. The pivot point for drawing is moved to the center of the screen
  2. In a grid, starting from a negative number all the way to a positive number (same number, so it'll still be centered), drawing a circle in each cell, in such a way that each circle's position and size is a little different than the previous one, using noise() so it's rather smooth (as opposed to using random() that's is more "jumpy").
  3. The circles are all drawn with a black stroke only, and the background is white. The program only runs once.

Decode #4

OriginalModified

  1. A grid is created with equal gaps, both from the edges of the screen, as well as between each element inside of each cell.
  2. The first third of the cells will have one line in each cell, the second third of the cells will have two lines in each cell, and the remaining third of the cells will have three lines in the each cell (this is dictated by the number of positions provided in the last argument of drawLine().
  3. For each cell, the line or lines drawn inside of it will be rotated a random amount (but the angle will remain the same for each cell of the grid).
  4. The lines will be black, the background will be white, and the lines will have rounded caps.

The part that I was most unclear about is why there's a need for two translate functions inside of the drawLine function. I understand that one is used for setting the rotation and the other is for positioning the lines, but it's hard to wrap my head around and I couldn't really get it before seeing how it affects the outcome.

Decode #5

OriginalModified

(I did take a peek at the video that was linked next to that assignment so I know I can expect something recursive...)

  1. There's no draw function, only setup, that calls a custom function, that calls another custom function that then calls itself until it reaches the exit rule (step #).
  2. There will be a grid of cells where 6 squares will be drawn in each cell. Each instance will either stay centered or move to the left or to the right (randomly).
  3. For each cell, all the squares will be drawn inside one another.
  4. This might look a lot like Decode #2(?!)

Part 2: Re/Code

The prompt for this week's assignment made me think of sorting algorithms again, as in sorting elements gradually based on a specific value they have, rather than drawing something that is gradually changing. I watched the Coding Train's video about Bubble Sort and that was really helpful with getting started with figuring out how these algorithms work. My plan was to have an image taken from the webcam, and then its pixels sorted by brightness (I first tried sorting them by reddest to greenest to bluest but I couldn't really get that to work).

I decided to try and use ChatGPT to help me with some technical questions, as well as with just walking me through some parts of the code and explaining how some sorting algorithms work. But unfortunately I think it made the whole process less clear to me. I reached a point where the code is only half working, some parts of it were written by me, others by ChatGPT, and it's hard for me to tell what's going on and where the problem is.

Currently when the sketch starts the webcam turns on and you can see a very low-resolution, pixelized version of yourself. When you click the mouse, your picture is taken, and then its pixels are being sorted and animated to show the sorting. But for some reason, the end outcome is not fully sorted — it seems like we need to have more passes over the array until no more swaps are needed. ChatGPT wasn't helpful anymore at this point and just kept suggesting I make sure the logic is intact.

This is using Bubble Sort.

Bubble sort is considered one of the simplest sorting algorithms. It goes through the array of elements, looking at one element at a time, comparing it with the one next to it, and swapping them as needed. It keeps iterating this process over the array until no more swaps are needed, which is when all the elements are supposedly sorted.

This is using Insertion Sort.

With Insertion Sort the array is virtually split into a sorted and an unsorted part. Values from the unsorted part are picked and placed in the correct position in the sorted part.

Both algorithms seem to have a similar issue — which might be helpful in solving this! I thought it might have something to do with the way p5 perceives brightness, and so I tried moving to working with HSB rather than RGB because it makes more sense when talking about brightness, but it didn't entirely work (I got weird colors drawn, but they weren't fully sorted as well). I guess the issue lies within the logic, but I haven't been able to figure it out yet. I hope I can redo this in the coming weeks because I'm getting interested in working with sorting algorithms and I'd like to find interesting ways to use them creatively.

X button icon

Jasmine Nackash is a multidisciplinary designer and developer intereseted in creating unique and innovative experiences.