From 3e0f620a933cf2a9325d051e87952edb1c3f9270 Mon Sep 17 00:00:00 2001 From: Akshay Date: Wed, 17 Mar 2021 17:59:43 +0530 Subject: new post: sdl2 devlog --- docs/index.html | 16 ++--- docs/index.xml | 62 +++++++++++++++++ docs/posts/SDL2_devlog/index.html | 131 +++++++++++++++++++++++++++++++++++ docs/posts/index.html | 17 +++++ docs/style.css | 7 ++ posts/SDL2_devlog.md | 139 ++++++++++++++++++++++++++++++++++++++ 6 files changed, 364 insertions(+), 8 deletions(-) create mode 100644 docs/posts/SDL2_devlog/index.html create mode 100644 posts/SDL2_devlog.md diff --git a/docs/index.html b/docs/index.html index 3d05a65..f592a26 100644 --- a/docs/index.html +++ b/docs/index.html @@ -42,15 +42,15 @@
- 17/10 — 2020 + 17/03 — 2021
- - Self-hosting Git + + SDL2 Devlog - 5.4 + 5.0 min @@ -59,15 +59,15 @@
- 01/09 — 2020 + 17/10 — 2020
- - NixOS + + Self-hosting Git - 3.3 + 5.4 min diff --git a/docs/index.xml b/docs/index.xml index a647bdf..a39131a 100644 --- a/docs/index.xml +++ b/docs/index.xml @@ -12,6 +12,68 @@ en-us Creative Commons BY-NC-SA 4.0 +SDL2 Devlog +<p>I have been working on an editor for the <a href="https://git.peppe.rs/graphics/obi/about">One Bit Image</a> file format in Rust and SDL2. This entry in my blog follows my progress on the editor. The days are listed in reverse chronological order, begin from the bottom this is your first time on this page.</p> +<h3 id="day-10">Day 10</h3> +<p>I started reading up on dithering methods and half-toning, I wanted to create a dithering brush that would automatically produce popular dithering patterns. The method that caught my eye (and also the one used most often in pixel art), was Bayer’s ordered dithering. When applied to a black and white image, each pixel, based on its intensity, is mapped to a 4x4 grid of pixels. A completely empty (completely black) 4x4 grid represents zero intensity, and a filled 4x4 grid represents full intensity. Bayer’s ordered dithering can produce 15 steps of intensity between zero and full (by switching on exactly 1 pixel more at each level), thus, being able to draw 17 “shades” from white to black. Creating a dithering brush from here was fairly trivial. Our pixmap is supposed to represent the final dithered image, it must be divided into 4x4 grids. Each grid is colored based on the intensity of the brush passing over it:</p> +<figure> +<img src="https://u.peppe.rs/Mn.png" alt="Day 10" /><figcaption aria-hidden="true">Day 10</figcaption> +</figure> +<h3 id="day-9">Day 9</h3> +<p>I started working towards an interface. I like the idea of a largely read-only HUD, i. e., an interface that simply describes the state of the application. Changes to this state are initiated via keybinds or text commands. I am proud of the symmetry indicator; <code>-</code> for horizontal symmetry, <code>|</code> for vertical symmetry, <code>+</code> for radial symmetry.</p> +<figure> +<img src="https://u.peppe.rs/hx.png" alt="Day 9" /><figcaption aria-hidden="true">Day 9</figcaption> +</figure> +<h3 id="day-8">Day 8</h3> +<p>One of my favourite features of GIMP was symmetric editing. I added some coordinate geometry primitives to my pixmap abstraction, allowing for mirroring and reflecting figures about lines or points. The result was an ergonomic function that applies symmetry to any painting operation, (undo/redo works as expected):</p> +<div class="sourceCode" id="cb1"><pre class="sourceCode rust"><code class="sourceCode rust"><span id="cb1-1"><a href="#cb1-1" aria-hidden="true"></a><span class="kw">let</span> line <span class="op">=</span> <span class="kw">self</span><span class="op">.</span>pixmap<span class="op">.</span>get_line(start<span class="op">,</span> end)<span class="op">;</span></span> +<span id="cb1-2"><a href="#cb1-2" aria-hidden="true"></a><span class="kw">let</span> sym_line <span class="op">=</span> <span class="kw">self</span><span class="op">.</span>symmetry<span class="op">.</span>apply(<span class="op">&amp;</span>line)<span class="op">;</span></span> +<span id="cb1-3"><a href="#cb1-3" aria-hidden="true"></a><span class="kw">for</span> point on line<span class="op">.</span>extend(sym_line) <span class="op">{</span></span> +<span id="cb1-4"><a href="#cb1-4" aria-hidden="true"></a> <span class="co">// draw to window</span></span> +<span id="cb1-5"><a href="#cb1-5" aria-hidden="true"></a><span class="op">}</span></span></code></pre></div> +<figure> +<video src="https://u.peppe.rs/B1.mp4" controls=""><a href="https://u.peppe.rs/B1.mp4">Day 8</a></video><figcaption aria-hidden="true">Day 8</figcaption> +</figure> +<h3 id="day-7">Day 7</h3> +<p>Bresenham saves the day again! This time, I implemented his line drawing algorithm, to, well, draw lines. Each point on the line is then “buffed” based on the active brush size. Today’s changes fit in very well with the undo system and the brush size feature. Creating the right abstractions, one at a time :)</p> +<figure> +<video src="https://u.peppe.rs/xt.mp4" controls=""><a href="https://u.peppe.rs/xt.mp4">Day 7</a></video><figcaption aria-hidden="true">Day 7</figcaption> +</figure> +<h3 id="day-6">Day 6</h3> +<p>I extended Bresenham’s algorithm to draw not just circle outlines, but also generate their fills. Unlike Bresenham’s algorithm, this variant generates points for two quadrants at once, these points are mirrored over the dividing axis to generate the other two quadrants.</p> +<figure> +<img src="https://u.peppe.rs/f3.png" alt="Day 6" /><figcaption aria-hidden="true">Day 6</figcaption> +</figure> +<h3 id="day-5">Day 5</h3> +<p>I discovered and implemented Bresenham’s algorithm for efficient circle drawing. The algorithm allowed for sized circular brushes, something I really liked from GIMP. Very convenient that the Wikipedia page for Bresenham’s algorithm also includes a section about optimizing for integer based arithmetic. I managed to abstract out another giant component of the application, the pixmap. Any image is just a grid of pixels (a pixmap), where the pixel’s value is decided by the application (1-bit in my case). I could potentially extend the application to a 24-bit image editor!</p> +<figure> +<video src="https://u.peppe.rs/Kh.mp4" controls=""><a href="https://u.peppe.rs/Kh.mp4">Day 5</a></video><figcaption aria-hidden="true">Day 5</figcaption> +</figure> +<h3 id="day-4">Day 4</h3> +<p>I created a generic “undo stack” data structure that allows for infinite “undos” and “redos”. Every modification operation to the grid is persisted to the application state. A couple of keybinds allow the user to revert and re-apply these operations! I expect abstracting this component will come in handy down the line.</p> +<figure> +<video src="https://u.peppe.rs/w5.mp4" controls=""><a href="https://u.peppe.rs/w5.mp4">Day 4</a></video><figcaption aria-hidden="true">Day 4</figcaption> +</figure> +<h3 id="day-3">Day 3</h3> +<p>I implemented the bare minimum required to call the program and “editor”. The application displays a grid, tracks mouse events, paints white to the canvas on left click, and black to the canvas on right click. I created a make-shift MVC architecture à la Elm in Rust.</p> +<figure> +<video src="https://u.peppe.rs/GF.mp4" controls=""><a href="https://u.peppe.rs/GF.mp4">Day 3</a></video><figcaption aria-hidden="true">Day 3</figcaption> +</figure> +<h3 id="day-2">Day 2</h3> +<p>I started figuring out event handling today. Implemented a couple of keybinds to zoom in/out of the drawing area. Conversions of SDL2 coordinates (measured in signed 32 bit integers) to my internal “drawing area” coordinates (measured in unsigned 32 bit integers) is very annoying. Hopefully the unchecked conversions won’t haunt me later.</p> +<figure> +<video src="https://u.peppe.rs/L4.mp4" controls=""><a href="https://u.peppe.rs/L4.mp4">Day 2</a></video><figcaption aria-hidden="true">Day 2</figcaption> +</figure> +<h3 id="day-1">Day 1</h3> +<p>Getting started with Rust and SDL2 is very straightforward. The <code>rust-sdl2</code> library contains some detailed examples that allowed me to get all the way to drawing a grid from a <code>Vec&lt;bool&gt;</code>:</p> +<figure> +<img src="https://u.peppe.rs/Ma.png" alt="Day 1" /><figcaption aria-hidden="true">Day 1</figcaption> +</figure> +https://peppe.rs/posts/SDL2_devlog/ +Wed, 17 Mar 2021 05:02:00 +0000 +https://peppe.rs/posts/SDL2_devlog/ + + Self-hosting Git <p>Earlier this week, I began migrating my repositories from Github to <a href="https://git.zx2c4.com/cgit/about/">cgit</a>. If you care at all about big corporates turning open-source into a T-shirt farming service, this is the way to go.</p> <h3 id="offerings">Offerings</h3> diff --git a/docs/posts/SDL2_devlog/index.html b/docs/posts/SDL2_devlog/index.html new file mode 100644 index 0000000..278deef --- /dev/null +++ b/docs/posts/SDL2_devlog/index.html @@ -0,0 +1,131 @@ + + + + + + + + + + + + + + + SDL2 Devlog · peppe.rs + +
+
+ Home + / + Posts + / + SDL2 Devlog + View Raw +
+
+ 17/03 — 2021 +
+ + 55.53 + + cm +   + + 5.0 + + min +
+
+

+ SDL2 Devlog +

+
+

I have been working on an editor for the One Bit Image file format in Rust and SDL2. This entry in my blog follows my progress on the editor. The days are listed in reverse chronological order, begin from the bottom this is your first time on this page.

+

Day 10

+

I started reading up on dithering methods and half-toning, I wanted to create a dithering brush that would automatically produce popular dithering patterns. The method that caught my eye (and also the one used most often in pixel art), was Bayer’s ordered dithering. When applied to a black and white image, each pixel, based on its intensity, is mapped to a 4x4 grid of pixels. A completely empty (completely black) 4x4 grid represents zero intensity, and a filled 4x4 grid represents full intensity. Bayer’s ordered dithering can produce 15 steps of intensity between zero and full (by switching on exactly 1 pixel more at each level), thus, being able to draw 17 “shades” from white to black. Creating a dithering brush from here was fairly trivial. Our pixmap is supposed to represent the final dithered image, it must be divided into 4x4 grids. Each grid is colored based on the intensity of the brush passing over it:

+
+Day 10 +
+

Day 9

+

I started working towards an interface. I like the idea of a largely read-only HUD, i. e., an interface that simply describes the state of the application. Changes to this state are initiated via keybinds or text commands. I am proud of the symmetry indicator; - for horizontal symmetry, | for vertical symmetry, + for radial symmetry.

+
+Day 9 +
+

Day 8

+

One of my favourite features of GIMP was symmetric editing. I added some coordinate geometry primitives to my pixmap abstraction, allowing for mirroring and reflecting figures about lines or points. The result was an ergonomic function that applies symmetry to any painting operation, (undo/redo works as expected):

+
let line = self.pixmap.get_line(start, end);
+let sym_line = self.symmetry.apply(&line);
+for point on line.extend(sym_line) {
+    // draw to window
+}
+
+ +
+

Day 7

+

Bresenham saves the day again! This time, I implemented his line drawing algorithm, to, well, draw lines. Each point on the line is then “buffed” based on the active brush size. Today’s changes fit in very well with the undo system and the brush size feature. Creating the right abstractions, one at a time :)

+
+ +
+

Day 6

+

I extended Bresenham’s algorithm to draw not just circle outlines, but also generate their fills. Unlike Bresenham’s algorithm, this variant generates points for two quadrants at once, these points are mirrored over the dividing axis to generate the other two quadrants.

+
+Day 6 +
+

Day 5

+

I discovered and implemented Bresenham’s algorithm for efficient circle drawing. The algorithm allowed for sized circular brushes, something I really liked from GIMP. Very convenient that the Wikipedia page for Bresenham’s algorithm also includes a section about optimizing for integer based arithmetic. I managed to abstract out another giant component of the application, the pixmap. Any image is just a grid of pixels (a pixmap), where the pixel’s value is decided by the application (1-bit in my case). I could potentially extend the application to a 24-bit image editor!

+
+ +
+

Day 4

+

I created a generic “undo stack” data structure that allows for infinite “undos” and “redos”. Every modification operation to the grid is persisted to the application state. A couple of keybinds allow the user to revert and re-apply these operations! I expect abstracting this component will come in handy down the line.

+
+ +
+

Day 3

+

I implemented the bare minimum required to call the program and “editor”. The application displays a grid, tracks mouse events, paints white to the canvas on left click, and black to the canvas on right click. I created a make-shift MVC architecture à la Elm in Rust.

+
+ +
+

Day 2

+

I started figuring out event handling today. Implemented a couple of keybinds to zoom in/out of the drawing area. Conversions of SDL2 coordinates (measured in signed 32 bit integers) to my internal “drawing area” coordinates (measured in unsigned 32 bit integers) is very annoying. Hopefully the unchecked conversions won’t haunt me later.

+
+ +
+

Day 1

+

Getting started with Rust and SDL2 is very straightforward. The rust-sdl2 library contains some detailed examples that allowed me to get all the way to drawing a grid from a Vec<bool>:

+
+Day 1 +
+ +
+ +
+ Hi. + +

I'm Akshay, I go by nerd or nerdypepper on the internet.

+

+ I am a compsci undergrad, Rust programmer and an enthusiastic Vimmer. + I write open-source stuff to pass time. + I also design fonts: + scientifica, + curie. +

+

Send me a mail at nerdy@peppe.rs or a message at nerdypepper@irc.rizon.net.

+
+ + Home + / + Posts + / + SDL2 Devlog + View Raw +
+
+ + diff --git a/docs/posts/index.html b/docs/posts/index.html index 61f1d2e..bd8c4ad 100644 --- a/docs/posts/index.html +++ b/docs/posts/index.html @@ -24,6 +24,23 @@
+ + + + +
+
+ 17/03 — 2021 +
+ + SDL2 Devlog + +
+ + 5.0 + + min +
diff --git a/docs/style.css b/docs/style.css index db4a163..b760db0 100644 --- a/docs/style.css +++ b/docs/style.css @@ -197,6 +197,13 @@ img { box-shadow: 0 0 1.5rem 0.5rem rgba(0, 0, 0, 0.10); } +video { + max-width: 100%; + border: 2px solid var(--dark-white); + border-radius: 0.4rem; + box-shadow: 0 0 1.5rem 0.5rem rgba(0, 0, 0, 0.10); +} + hr { height: 2px; background-color: var(--dark-white); diff --git a/posts/SDL2_devlog.md b/posts/SDL2_devlog.md new file mode 100644 index 0000000..0b05c90 --- /dev/null +++ b/posts/SDL2_devlog.md @@ -0,0 +1,139 @@ +I have been working on an editor for the [One Bit +Image](https://git.peppe.rs/graphics/obi/about) file format in +Rust and SDL2. This entry in my blog follows my progress on +the editor. The days are listed in reverse chronological +order, begin from the bottom this is your first time on this +page. + +### Day 10 + +I started reading up on dithering methods and half-toning, I +wanted to create a dithering brush that would automatically +produce popular dithering patterns. The method that caught +my eye (and also the one used most often in pixel art), was +Bayer's ordered dithering. When applied to a black and white +image, each pixel, based on its intensity, is mapped to a +4x4 grid of pixels. A completely empty (completely black) +4x4 grid represents zero intensity, and a filled 4x4 grid +represents full intensity. Bayer's ordered dithering can +produce 15 steps of intensity between zero and full (by +switching on exactly 1 pixel more at each level), thus, +being able to draw 17 "shades" from white to black. Creating +a dithering brush from here was fairly trivial. Our pixmap +is supposed to represent the final dithered image, it must +be divided into 4x4 grids. Each grid is colored based on the +intensity of the brush passing over it: + +![Day 10](https://u.peppe.rs/Mn.png) + + +### Day 9 + +I started working towards an interface. I like the idea of a +largely read-only HUD, i. e., an interface that simply +describes the state of the application. Changes to this +state are initiated via keybinds or text commands. I am +proud of the symmetry indicator; `-` for horizontal +symmetry, `|` for vertical symmetry, `+` for radial +symmetry. + +![Day 9](https://u.peppe.rs/hx.png) + +### Day 8 + +One of my favourite features of GIMP was symmetric editing. +I added some coordinate geometry primitives to my pixmap +abstraction, allowing for mirroring and reflecting figures +about lines or points. The result was an ergonomic function +that applies symmetry to any painting operation, (undo/redo +works as expected): + +```rust +let line = self.pixmap.get_line(start, end); +let sym_line = self.symmetry.apply(&line); +for point on line.extend(sym_line) { + // draw to window +} +``` + +![Day 8](https://u.peppe.rs/B1.mp4) + +### Day 7 + +Bresenham saves the day again! This time, I implemented his +line drawing algorithm, to, well, draw lines. Each point on +the line is then "buffed" based on the active brush size. +Today's changes fit in very well with the undo system and +the brush size feature. Creating the right abstractions, one +at a time :) + +![Day 7](https://u.peppe.rs/xt.mp4) + + +### Day 6 + +I extended Bresenham's algorithm to draw not just circle +outlines, but also generate their fills. Unlike Bresenham's +algorithm, this variant generates points for two quadrants +at once, these points are mirrored over the dividing axis to +generate the other two quadrants. + +![Day 6](https://u.peppe.rs/f3.png) + +### Day 5 + +I discovered and implemented Bresenham's algorithm for +efficient circle drawing. The algorithm allowed for sized +circular brushes, something I really liked from GIMP. Very +convenient that the Wikipedia page for Bresenham's algorithm +also includes a section about optimizing for integer based +arithmetic. I managed to abstract out another giant +component of the application, the pixmap. Any image is just +a grid of pixels (a pixmap), where the pixel's value is +decided by the application (1-bit in my case). I could +potentially extend the application to a 24-bit image editor! + +![Day 5](https://u.peppe.rs/Kh.mp4) + + +### Day 4 + +I created a generic "undo stack" data structure that allows +for infinite "undos" and "redos". Every modification +operation to the grid is persisted to the application state. +A couple of keybinds allow the user to revert and re-apply +these operations! I expect abstracting this component will +come in handy down the line. + +![Day 4](https://u.peppe.rs/w5.mp4) + + +### Day 3 + +I implemented the bare minimum required to call the program +and "editor". The application displays a grid, tracks mouse +events, paints white to the canvas on left click, and black +to the canvas on right click. I created a make-shift MVC +architecture à la Elm in Rust. + +![Day 3](https://u.peppe.rs/GF.mp4) + +### Day 2 + +I started figuring out event handling today. Implemented a +couple of keybinds to zoom in/out of the drawing area. +Conversions of SDL2 coordinates (measured in signed 32 bit +integers) to my internal "drawing area" coordinates +(measured in unsigned 32 bit integers) is very annoying. +Hopefully the unchecked conversions won't haunt me later. + +![Day 2](https://u.peppe.rs/L4.mp4) + +### Day 1 + +Getting started with Rust and SDL2 is very straightforward. +The `rust-sdl2` library contains some detailed examples that +allowed me to get all the way to drawing a grid from a +`Vec`: + +![Day 1](https://u.peppe.rs/Ma.png) -- cgit v1.2.3