DEV Community: The Struggling Dev

Liquid Glass Lacks Visual Hierarchy

The Struggling Dev — Tue, 03 Feb 2026 14:00:00 +0000

I've always been obsessed with deep technical details, but lately, I’ve realized I actually give a damn about aesthetics. Now, let’s be clear: I am not a designer. But that’s the thing about visual design — everyone has a "feel" for it. You can tell when something is pleasing (or broken) without necessarily knowing the terminology.

I recently updated to the latest macOS (Tahoe), and honestly? I don't like it.

I already keep transparency effects turned off because I’m a dev and I like to actually see my windows, but even then, it's just not a good-looking OS anymore. I’m not a fan of the "round everything" trend, but that’s just personal preference.

However, there is one thing I think is objectively "wrong" with the new Liquid Glass aesthetic: the death of visual hierarchy.

The Chrome Way: Logical Union

Look at the tabs in Google Chrome:

The active tab header clearly connects to the rest of the UI. It’s one cohesive piece. A union. Your brain immediately understands: "This tab owns this content."

The Safari Way: Floating Pill Syndrome

Now, look at Safari:

It’s just a pill-shaped button with zero connection to the rest of the UI. It just floats there. Logically, it could belong to anything — or nothing. We’ve traded "clear relationship" for "ooh, shiny floating shape."

Finder and the Sidebar Identity Crisis

Another example of this hierarchy breakdown is the window controls in Finder.

We have a sidebar on the left for shortcuts. Sitting inside that sidebar are the traffic light buttons (Close, Minimize, Maximize).

Hierarchically, those buttons are "glued" to the sidebar panel. If we follow basic logic, clicking those buttons should close or minimize the panel, not the entire window.

I made a quick mockup of what it would look like if the buttons were actually placed on the window canvas itself:

I’m not saying my mockup is "prettier", but at least it's logical.

Why should we care?

When we break visual hierarchy in favor of "vibes" or "Liquid Glass" effects, we make the interface harder to parse subconsciously. But for us devs, the problem goes deeper than just aesthetics:

The "Glass" Tax: All those real-time blurs, transparency layers, and frosted glass effects aren't free. Your GPU is constantly working to recalculate those shadows and refractions every time a window moves.
Battery Drain: If you're working on a MacBook, every unnecessary GPU cycle is a hit to your battery life. I’d much rather have an extra 30 minutes of compile time than a pretty blur effect on my terminal background.
Cognitive Load: As a dev, I struggle enough with complex codebases; I don't want to expend extra brain power figuring out which "floating pill" belongs to which parent container.

Conclusion

Is Apple losing the plot on logic, or am I just a grumpy dev who misses sharp corners? To me, it feels like we’re sacrificing the "Functional" part of "Functional Design" to chase a trend that looks great in a marketing screenshot but fails in daily use.

AI Made Me More Productive — and Less Sure Why I Code

The Struggling Dev — Tue, 23 Dec 2025 20:10:46 +0000

It's been a while since my last post. One thing that has been occupying my mind lately is AI. I think this post won't have much structure — just some ramblings about AI.

In 2017 — almost ten years ago, how time flies — I did some further education in AI. At that time, deep learning was the big thing. Hardware advances allowed for deep neural networks with multiple hidden layers, the way it had been imagined since the 50s and 60s, starting with the perceptron. I was fascinated — by the possibilities, but also by the relative mathematical simplicity. Specialized, trained networks could, for example, find cancer in medical imaging. A neural network doesn't get tired, isn't distracted by private issues, and doctors do too many hours anyway.

Now, LLMs have entered the world. I still think they're not smart and I'm questioning the future of software development — and maybe even the future of the world and humanity. I use LLMs mainly for learning. My favorite use case is using it as a sparring partner: discussing ideas and approaches. One thing I recently started doing, is setting up "think tanks". For example, I tell ChatGPT to assemble a group of software architects and experts who have different views and then let them dissect an idea of mine, or come up with a solution of their own. I learn a lot that way.

Not having to write boiler-plate code sounds good on the surface. But I think I sometimes need the "downtime" of doing something relatively "brainless" for a few minutes — to recharge, or to let my mind wander and come up with new ideas. And if it's more than a few minutes of repetitive work, I automate it — the old-school way — as many of us have done before AI was a big thing.

I'm ambivalent about AI when it comes to juniors. On the one hand, it allows them to punch way above their weight in many ways — speed, sometimes even quality. On the other hand, junior positions seem to be shrinking. I've heard tech leaders say we'll only need senior developers to check and fix what the AI produces. That raises questions: Is that work senior developers actually want to do? How do developers reach a senior level if we stop hiring and training juniors? Or, is the idea that AI won't need checking and fixing by the time the current generation of senior developers retires?

It feels empty. I'm pondering whether my problem is that I always loved the process, the craft, and never the product. Should I just find a way to use AI to make a lot of money, jump off the train, and follow the craft without any pressure? And if I did, would I still want to?

I've been using ChatGPT for a while now, and I've started dabbling with Cursor and agentic AI in other IDEs as well. I see the benefits — the speed, the productivity — but I'm not sure whether the joy of developing can persist in the long run.

Maybe that's the real question AI forces us to ask.

What are your thoughts?

Documenting Decisions

The Struggling Dev — Thu, 30 Jan 2025 19:32:42 +0000

Meetings are for decisions, and these decisions need to be documented.

Decisions must be documented and, in addition to the decision made, include the following additional information or refer to it:
- Reasons why the decision was made
- Any alternatives considered
- Any accepted consequences resulting from the decision
- When the decision was made
Following a decision, it must be defined who needs to be informed about the decision by when and in what form.

Architecture Decisions

Decisions concerning software architecture must be documented in the following Architecture Decision Record (ADR) format.

ADR-001: Concise title

Status: [Draft, Proposed, Accepted, Deprecated, Superseded]

Context

A value-neutral description of the forces at play (technological, political, social, and project-specific)

Decision

The decision made, including the reasoning behind it.

Alternatives

Any alternatives that were considered, including > reasons why they were rejected.

Miscellaneous

Additional information like "Create on", "Accepted on", ...

ADRs should be put under source control and be stored in the corresponding project in the doc folder.
Pull requests can be use for discussion and approval of the ADR.

Make sure to check out Michael Nygard's post on Documenting Architecture Decisions

Decisions in recurring meetings

For recurring meetings I like to keep them in one large document containing the meeting minutes, to dos, ... The format for decisions is similar to the one for to dos, see
Managing To Dos in recurring meetings, when there's no agreed upon tool.

DECISION-001 Architecture decisions must be put under source control

Reason: Decisions can be discussed in pull requests, changes are tracked, decisions are readily available for the developers and close to the code

Consequences: access is limited to readers of the repository

Alternatives: Confluence, Wiki, Word documents

TODO-001 John 2025-02-14: Inform all architects and developers about this decision

If there's no organization-wide decision tracking tool, the above format can be used.

Managing To Dos in recurring meetings, when there's no agreed upon tool

The Struggling Dev — Wed, 04 Dec 2024 16:42:00 +0000

Meetings often lead to to dos and tasks that need tracking. Especially when you're moderating a recurring meeting, like a status meeting, you want to make sure you're on top of these to dos. One challenge I sometimes face is, that there's no common tool for managing to dos that all participants of the meeting use. The reasons for this can be manifold. Different departments use different tools, different tools are used for different kinds of to dos, ...

One approach that has worked well for me for recurring meetings where multiple departments participate, is to create one long meeting notes document and track the to dos within this document.

Because most people know Word and feel comfortable with it, it usually ends up being a Word document. While writing the meeting notes I just add to dos in the following format.

%status-emoj% TODO[%optional-id%] %assigned-to% [%optional-due-date%] %to do%

%date% %status-info%

An example within some made-up meeting notes looks like this:

It's time to replace servers in segment B2 before we launch "Fancy Product". Marc suggests we should switch from Intel to AMD because of performance and pricing.

TODO-001 John 2025-01-21: Make suggestion for new servers (Intel vs AMD)

You can go as fancy or as bare bones as you want with the format.

TODO John: John needs to do something

TODO John 2024-12-31: John needs to do this by the end of the year

🔁 TODO-001 John 2025-01-31: John ...

2024-12-04 First milestone reached

2024-12-15 John needs more time because project A got prioritized, due date adjusted from 2024-12-31 to 2025-01-31

✅ TODO-001 John 2025-01-31: John ...

...

2025-01-31 Done

If you're using Word you have the added benefit of having a decent to do list by searching the document for "TODO-".

It sure is not perfect, but it works - at least for me. In keeping with my initial post about using RFC 2119 to convey intent, here are my rules for these sort of to dos.

To dos must be written down for all participants of a meeting to access
To dos must be assigned to at least one person
To dos should have a due date
To dos should be tracked in the tool appropriate for the assignees of the to dos. If the participants can't agree on one tool, the above format can be used.

Quickie post test.

The Struggling Dev — Wed, 27 Nov 2024 18:19:24 +0000

Hopefully Helpful Notes, Best Practices, ...

The Struggling Dev — Tue, 26 Nov 2024 19:47:35 +0000

Thought I'll give quickie posts a try. But as it turns out, this is too large for a quickie post ;). So, back to the normal full post.

Over the years I've been collecting notes, checklists, best practices, rules, ... that are more or less related to working as a software developer. I've recently started to write them down in a more formal way, and thought why not share some of them in this "new" quickie posts format.

To start this off, we'll go a bit meta and define some rules for writing these best practices, ... down. I'll be leaning on the RFC 2119 to convey how much leeway for example rules allow.

In general, the main key words according to RFC 2119 should be used, e.g. must, must not instead of shall, shall not.
Key words must follow English spelling conventions regarding capitalization.
Key words must be emphasized using bold formatting.

MVP as an Excuse for Bad Code?

The Struggling Dev — Wed, 23 Oct 2024 15:42:00 +0000

Introduction

I've recently had a discussion about Minimum Valuable Products (MVPs) and what exactly they are. Actually it was more buzzword name-dropping. The interesting part was, the context in which it came up: hardware development.

In this case, the MVP was explained to me as an "ugly gray box". A thing you put together to see if an idea works. It's just made up of some cobbled up components that are laying around, some duct tape and an idea.

Ever the critical developer, this struck a nerve. To me this sounded more like a prototype than an MVP. Don't get me wrong I don't want to say it's wrong to call what they do an MVP. Hardware development is a very different beast than software development - I assume, and I'm not even sure whether this is a widely adopted nomenclature. It just made me think of the "dangers" when you interchange these two things in software development. And for software developers who've never heard of an MVP, this sounds like a free ticket to hack something together.

Which, at least in my opinion, it's not. So let me try to define different approaches to software development. This is my interpretation, if you disagree let me know - I'd appreciate it.

Proof of Concept (PoC) or Exploratory Programming

What you do when you hack something together after you've identified the critical parts of the thing you want to implement. E.g., you have to implement a feature in an existing app, you need to use some framework tool you've never used, you have no idea whether you're approach will work, ... . You know, you'll need to properly integrate your feature, get the values from your data store, pass them properly to your feature, validate, ... But you kick that all to the curb, misappropriate the first and easiest to call button in your app, pass some constant values in, ignore all code style rules and just figure out if there's a chance this will work.

This is no product, just loose parts.

Prototype

You have an idea for a product, but you're not sure there's a market for it. You implement all you need to figure this out as quickly as possible. Whether there's a market or not, you usually scrap the prototype. If you have a market, you start working on an MVP. If not, you start over with your next idea - or in lack of one, go to the next pub.

This is also no product, but it has the potential to become one.

Minimum Viable Product

Now we finally have a product, it's right there in the name. We know we have a market. We now have a software product, that we will need to maintain. So this is the point where we stop programming and start developing. We concentrate on the most important functional requirements and leave the nice to haves out. We might also postpone some non-functional requirements as long as they aren't relevant to our architecture decision. While PoCs and prototyping are acceptable reasons to program quick and dirty and don't care about architecture, this stops when we start implementing an MVP.

Sometimes people ask "What's the difference between a programmer and a software developer?" I recently heard a definition, I kinda like. The difference is time. When you're developing software, you take into account that your software needs to grow (needs to develop) and change because it will be around for many years. A small program you just use once, or that never changes, doesn't need to adhere to the same standards of maintainability. In the end it's a mind set.

Closing the circle

One reason I can see why it's less "dangerous" to call the ugly gray box an MVP, is that creating hardware and software are so vastly different things. When you create a hardware product you inherently know that you have to start from scratch once you're finished, you can't copy hardware as you can software. Your ugly gray box consists of off the shelve parts and your battery is duct-taped to the box because it's too expensive to commission a special Möbius strip-shaped battery so it fits into your fancy designer box. Your ugly gray box also won't get the approval stamp from any authority.

I'm curious to hear other points of view, so drop me a comment if you like.

Thanks for reading and keep on struggling.

A Take on Agile, Scrum, Lean and DevOps: Conclusion

The Struggling Dev — Wed, 16 Oct 2024 15:42:00 +0000

Introduction

This post has been sitting around as a draft for a long time. I was wondering whether it would even make sense to publish it. But then I thought "finish what you've started" and conclude the series that started almost two years ago. So, let's get into it:

Now that we have a basic understanding of Agile, Scrum, Lean and DevOps - let's compare them. Which one is the best? Which one should you choose? Although, I have a feeling you already know where this is going. ;)

Over this series we've established that Agile and Scrum, as well as Lean and DevOps build pairs. Let's see what happens when we juxtapose these two pairs. I'm using the principles behind the Agile Manifesto as an anchor for the comparison.

Continuous Delivery of Value in Small Batch Sizes

The first principle behind the agile manifesto states:

Principle behind the Agile Manifesto #1
"Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."

And the third one:

Principle behind the Agile Manifesto #3
"Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale."

Scrum wants us to work in short Sprints with Sprint Reviews at the end of every Sprint. That way, we get feedback from the stake holders and users to see whether we're still on track and our product increment is valuable to them. Features should be broken down to be completable in one Sprint, tasks should be doable in a day or so.

Lean is all about improving value streams and removing blockages and waste, so we can delivery value of high quality to the customer. We do this by working in small batch sizes, removing waste, ... . DevOps, unsurprisingly, agrees with this and describes this in detail in its First Way: The Principles of Flow. Work in small badge sizes, automate deployment (CD) so that we can deploy multiple times a day, ...

Collaboration

Software development is a team effort. The agile manifest has two principles dedicated to this fact.

Principle 4

Principle behind the Agile Manifesto #4
"Business people and developers must work together daily throughout the project."

and principle 6

Principle behind the Agile Manifesto #6
"The most efficient and effective method of conveying information to and within a development team is face-to-face conversation."

With Scrum we implement this by building multidisciplinary teams that include the product owner and in the best of cases the users themselves.

One can argue that Lean and DevOps are less focused on collaboration with the customer. But the big thing is that development and operations need to work closely together, it's in the name. This gets expanded with DevSecOps, MLOps, ...

Or as Taiichi Ohno said:

"Teamwork is everything"
-- Taiichi Ohno, Toyota Production System - Beyond large-scale production

Learning and Motivation

Principle behind the Agile Manifesto #5
"Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."

Scrum recommends self-organizing teams that take ownership of the product. Lean wants us to foster a blameless culture that allows for failures and encourages continuous learning and experimentation, which DevOps manifests in the Third Way: Principles of Continual Learning and Experimentation.

Technical Excellence

Principle behind the Agile Manifesto #9
"Continuous attention to technical excellence and good design enhances agility."

This principle doesn't seem to be addressed explicitly by Scrum. One could argue that the Daily Scrum meeting at least allows for the voicing of such concerns ("What impedes my progress?"), which the Scrum Master then should address. This lack might also be one of the reasons for a point of contention that arises when it comes to the incorporation of software architecture in agile methods.

The Toyota Production System on the other hand is more explicit. It wants us to swarm problems and remove waste and ever improve the way we work. DevOps even gives us a concrete number and recommends its practitioners to spend 20% of cycle time on paying down technical debt.

Reducing Waste

Principle behind the Agile Manifesto #10
"Simplicity--the art of maximizing the amount of work not done--is essential."

In Scrum we talk to our customers regularly to make sure what we do/planned is still what they need. Approaches like Minimum Viable Products (MVP) help us to focus on what really required. And Lean cherishes almost nothing more than reducing waste.

More Similarities than Differences

There are many more comparisons left to be made and parallels to be drawn. But I'll leave you with the ninth principle, and let Taiichi Ohno have the last word in this section.

Principle behind the Agile Manifesto #9
"Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely."

Scrum wants us to continuously deliver value to the customer, plan our Sprints accordingly and "find" our velocity to forecast future work.

"Speed is meaningless without continuity".
-- Taiichi Ohno, Toyota Production System - Beyond large-scale production

In the end, there are more similarities than differences. Agile, Scrum, Lean and DevOps are all mindsets - ways to think at whose hearts lies continuous improvement. Although they might use different terminology, they're very similar if not the same as far as intent goes. There are even tools like Kanban to visualize work and work in progress that are used by practitioners of all of these mindsets.

They're also all more than the sum of their parts. Just planning some Daily Scrum meetings and throwing planning poker cards on a table isn't enough. And that's why they're hard, they require the most difficult kind of change: organizational change.

You see things differently? Awesome, leave me a comment!

Thanks for reading and keep on struggling.

(Game)Dev with Emacs - Because it's not Already Hard Enough Without it

The Struggling Dev — Mon, 07 Oct 2024 16:42:00 +0000

Introduction

This is another tale from down the rabbit hole. See Writing an Emacs Major Mode - Because Why Not? (DEV), for my first post on Emacs. As I wrote in my post on Character Design (DEV), I'm playing around with writing a game. And to make it even more fun I've decided to use Emacs for it.

Emacs Setup and Syntax Highlighting & Code Complete

I'm using Doom Emacs. I'm refraining from reproducing the installation guide here and just point to it for anyone who's interested: Doom Emacs #Install (GitHub). After the installation we activate support for C++ and LSP (auto-complete and stuff) by removing the comments from the init.el file (just press SPC+f+P on the Doom dashboard and choose init.el). Search for "lsp" and "(cc" and remove the leading ;;.

;;lsp
;;(cc +lsp)

Additionally, we add the following line to the end of the init.el.

(setenv "LSP_USE_PLISTS" "1")

This line improves LSP performance significantly, see LSP Mode - Performance for more performance tips.

If you've already used LSP mode in Emacs without plists active, you have to delete the LSP package first - otherwise you'll get errors when activating LSP mode the next time.

According to the documentation you should be able to just delete the package by using package-delete, but in my case I couldn't find any lsp packages listed. If you run in the same problem, and are on MacOS, here's how to delete the packages manually.
# cd into your .emacs folder and search for lsp stuff
find ./ -name "lsp*"
# and delete it - after checking the results. In my case, removing the following did the trick.
rm -rf .//.local/straight/build-29.1/lsp*
rm -rf .//.local/straight/repos/lsp*

After these changes we close Emacs and run doom sync. Back in Emacs we can run M-x lsp-doctor to check whether we're all good.

The native compilation part is intriguing, but I haven't had time to check this out more closely and after switching to plists performance was fine.

If we now open a projectile project (a directory with a .git folder should automatically be identified as a project), we have syntax highlighting and code completion.

Now that we have some of the creature comforts for developing in place, let's compile an application.

Compiling an Application

While we're in a project we can start compilation with SPC+p+c. The issue is, we have to provide the compile command ourselves. For my project I'll call CMake. Typing this every time we want to compile is annoying, luckily Emacs remembers our last command. But what if we have multiple components we want to compile, which we should've because tests 😉.

For this case I've started using bash files to compile and run my projects.

#!/bin/bash
cmd=$1
if [ "$cmd" = "build" ]; then
  cd build && cmake --build .
elif [ "$cmd" = "run" ]; then
  cd build && cmake --build . && ./MyGame
elif [ "$cmd" = "configure" ]; then
  cd build && cmake ../src
elif [ "$cmd" = "test" ]; then
  cd build && cmake --build . && ctest
else
  cd build && cmake --build . && ./MyGame
fi

With this file in our project root, we can just SPC+p+c and ./run.sh for most cases when we want to compile and run the application. Easy as pie, or is it?

Should you Ditch your IDE?

I'm not deep enough down the rabbit hole to really provide a profound answer to this question yet, sorry. But, I'll do it anyway - as someone still on the journey might describe the destination he hasn't yet seen: NOOOO. Thanks for reading.

But let me elaborate. Like with everything in life there are trade offs.

What I Like

It's a stupid argument, (Doom) Emacs just looks and feels "cool" 🤓. It has that "hacker"-aesthetic.

But on to some functional arguments.

Highly optimized for keyboard input. Emacs does have mouse support, but I rarely use the touchpad for anything with Emacs.
It's relatively light-weight and easy on resources.
It's highly customizable
Org mode. Org mode is just great for taking notes and organizing tasks. I might write a post on it one day. If you're interested, check out Org Mode in the mean time.
I enjoy just having one editor for everything - kinda like an integrated development environment 🤔. Sure you can code and take notes in CLion or VS Code as well, but can you also browse?🤪 Emacs has you covered with the Emacs Web Wowser (eww). It's basic, it's ugly and I've used it only a few times for quick searches, but it's there.

Stuff that's Missing or That I Don't Like

I've previously used CLion for C++ development, and there's a few things I miss. For one, I'm not a C++ developer by trade, so I mostly suck at it. CLion is great that way as it supports you with tips and best practice hints. Maybe, likely, I can add linters to Emacs as well.
There are some vim commands that are not mapped in EVIL mode.
Debugging seems to be possible, didn't get around trying it out.
The basics are much harder than with any IDE. Not only do you have to do something extra to get code completion, you (might) have to do even more to make it fast.

For all its power, Emacs makes you earn it. It's not comfy - it might be after you've configured everything you need. If you ever get there:

The Struggles

Emacs - Emacs is suffering. It makes you swear, it makes you despair, ... and it makes you celebrate if/when it finally works. Emacs is interesting, powerful and highly customizable. And with that comes the big downside. Although you most likely can do everything with Emacs, it takes time, research, configuration, trial & error and nerves.

The biggest challenge when writing this post, was what I should leave out. For example reproducing the Doom Emacs installation guide seemed to be a waste of time and space. If something's missing, don't hesitate to ask/point it out in the comments.

Thanks for reading and keep on struggling.

Shadow Shader Experiments

The Struggling Dev — Mon, 30 Sep 2024 16:42:00 +0000

Introduction

After playing around with light and normal mapping, the next thing that comes to mind is shadows. Instead implementing something from the shelf like shadow mapping or ray tracing, this post deals with a custom implementation. The implementation is based on an idea, it has (severe) limitations, it might not work, other people might have already implemented or refrained from implementing it because they had more foresight than me, ... I don't know, but we'll find out.

DISCLAIMER Again, this is just experimental stuff and likely a waste of time. If you value your time, stop reading now. If you proceed, don't say I haven't warned you. ;)

So, let's go and have some stupid fun! ;)

The Basic Idea

Given that I have a pixel art game with a low resolution (currently tending to 320x240 internal) and I already have some per-pixel lighting in place, the idea is as follows. For every pixel I'll check whether the neighboring pixel is elevated and in between the current pixel and the light source, and if so darken it a bit. One limitation that is a given is that my shadows can only be one pixel large.

We need eight values for every pixel that indicate whether each of the neighboring eight pixels is elevated or not. It's kind of a degenerated gradient descent map.

We might even be able to adjust the shadow based on the difference in angle between the light source and the pixel that casts shadow on the current pixel.

We already have the direction from the current fragment to the light source from the normal mapping post.

An Attempt at Implementation

We need eight boolean values for each pixel. Similar to using normal maps to store non-color information, another texture seems to be a good candidate for this. We can just use the bits of an 8bit color channel to encode this information. Let's define the pixel directly above as 0 and then go around clockwise.

+---+---+---+
| 7 | 0 | 1 |
+---+---+---+
| 6 | x | 2 |
+---+---+---+
| 5 | 4 | 3 |
+---+---+---+

0: 1000'0000
1: 0100'0000
2: 0010'0000
3: 0001'0000
4: 0000'1000
5: 0000'0100
6: 0000'0010
7: 0000'0001

if the pixels 0, 1 and 2 were elevated in comparison to x, we would encode the value 1110'0000.

To make it easier to draw the gradient map, we convert these binary values to hex values. b1110'0000 becomes 0xE0 for example. We'll use the red channel, therefore the entire color's hex values is 0xE00000. We could create a small tool to make this process easier, but since it's not clear whether this approach has any future, we just do everything by hand.

We have a 3x3 grid which leads to quite a few permutations, but we don't need all of them.

At the top of the image is the final gradient map for the floating rock. Most of the image is black, which means there's no difference in elevation. Below are some of the possible variations from which we can pick the corresponding color.

Now that we have the texture we'll need to do something with it in the fragment shader. First we need to a add another texture sampler, from which we'll then get the red channel. We can check whether a certain direction is above the current fragment by using the bitwise AND operator & (details in the shader comments).

// ...
uniform sampler2D gradientMap;
// ...

void main() {
    // ...
    // Get the red channel from the gradient map, this is where our elevation information is stored.
    float redChannel = texture(gradientMap, TexCoord).r;
    // Convert it to an integer as bit-wise operators only work with integers
    int intValue = int(redChannel * 255.0);
    // Check for each direction if it's elevated (1) compared to our current position.
    int north = intValue & 0x80;
    int northEast = intValue & 0x40;
    int east = intValue & 0x20;
    int southEast = intValue & 0x10;
    int south = intValue & 0x08;
    int southWest = intValue & 0x04;
    int west = intValue & 0x02;
    int northWest = intValue & 0x01;

    // Next, calculate the shadow by adding a value for every direction whose pixel is elevated. The values for the variables north, northEast, ... are all greater 0 if they are elevated and should therefore add to the shadow value.  The step function returns 0 if the value of the second parameter is smaller than the first one, and 1.0 otherwise. This way only the directions > 0 contribute to the shadow value and all to the same degree.
    float shadow = step(0.1f, north) * max(dot(vec3(0, 1, 0), lightDir), 0);
    shadow += step(0.1f, northEast) * max(dot(vec3(1, 1, 0), lightDir), 0);
    shadow += step(0.1f, east) * max(dot(vec3(1, 0, 0), lightDir), 0);
    shadow += step(0.1f, southEast) * max(dot(vec3(1, -1, 0), lightDir), 0);
    shadow += step(0.1f, south) * max(dot(vec3(0, -1, 0), lightDir), 0);
    shadow += step(0.1f, southWest) * max(dot(vec3(-1, -1, 0), lightDir), 0);
    shadow += step(0.1f, west) * max(dot(vec3(-1, 0, 0), lightDir), 0);
    shadow += step(0.1f, northWest) * max(dot(vec3(-1, 1, 0), lightDir), 0);

    // limit the value to a range of 0 to 0.5, choose whatever range looks good to you
    shadow = clamp(shadow, 0, 0.5);
    // Since we subtract the value later on, we need to set the alpha channel to 0.0f. If we'd set it to a greater value we'd influence the transparency of the final fragment color.
    vec4 shadowVec = vec4(shadow, shadow, shadow, 0.0f);
    FragColor = texture(tex, TexCoord) * (ambient + diffuseColor - shadowVec);
}

Let's have a look at how it looks like.

The little dot about the green stuff is the light source.

It's nothing to phone home about, but it's not that bad either.

The Struggles

I wasn't sure whether I should implement it and even more so whether I should blog about it. Also, there were multiple times when I wanted to optimize for performance and had to remind myself that this is just a proof of concept and now was not the time to do that. I might have wasted some time for a solution that I'll likely not use in the future. On the other hand I've learned some things and have gotten more comfortable with shaders. Trying to figure out something from the ground up, without just following a tutorial or checking what other options are out there. Aaaand it was fun.

Implementation-wise I took a detour by using floatBitsToInt which just interprets the float bits as an int. Not what I was looking for and the solution was much easier - a simple int(x) cast.

Thanks for reading and keep on struggling.

Major Mode Comfort Functions, Because I'm Lazy

The Struggling Dev — Mon, 23 Sep 2024 16:42:00 +0000

Introduction

After creating a bare bones major mode for Emacs, there are some minor things to do to improve the overall usability. For one, I currently have to build the .el file every time I want to use the mode. And for another I have to manually choose the mode for a given buffer. Let's fix these two annoyances.

Registering the Major Mode when Emacs Starts

We could just always load the file on startup. A better way though is to autoload the major mode. This way the actual function is only evaluated if and when the mode is used. Kinda like a method definition in a header file. The time tracking mode is not really complex, but why load it every time we start Emacs when we can do it only when it's actually being used. To achieve this we add the following line to init.el.

(autoload 'time-tracking-mode "/path/to/major/mode/directory/time-tracking-mode.el" "Major mode for time tracking." t)

the first parameter is the name of the function that defines the major mode
the second one is the path to the file containing the function
the third one is the doc string of the function
and the fourth one says that function can be called interactively
Autoload (GNU)

If we now restart Emacs the major mode should be available without us first needing to open and evaluate the file manually.

We can test whether it's really only loading the major mode when needed. If we change the file name to something that doesn't exist, we get an error when we activate the major mode for a buffer, saying that the file couldn't be found.

Great, let's move on to the next quality of life feature.

Activating the Major Mode When We Open a File with a Certain Extension

We can tell Emacs to switch to a major mode whenever a file with a certain extension is opened. The only thing we need to do is to add the corresponding mapping to the auto-mode-alist. We can do this by adding the following to config.el.

(add-to-list 'auto-mode-alist '("\\.ttr" . time-tracking-mode))

"\\.ttr" is the file extension
time-tracking-mode is our major mode

If we restart Emacs and open a file with the extension ttr the time tracking mode gets activated automatically.

The Struggles

Still struggling a bit with the Emacs documentation, but it's getting better. I'm taking more time to really read the articles - I'm still quite impatient though - small changes and have to read 2 pages of text ;). What I'm not really getting the hang of is where to put the functions. add-to-list for example didn't work in init.el, only in config.el. Need to read up on that.

Thanks for reading and keep on struggling.

Jergen gets Normal Mapped

The Struggling Dev — Mon, 16 Sep 2024 07:42:00 +0000

Introduction

In my last post I checked the art side - still struggling with the word art - of my player character. This time we're moving on to something more technical, although it's still a bit "artsy". Currently Jergen looks a bit bland.

I've therefore decided that its time to turn the lights on.

Let There Be Light

Okay, Jergen already looks sufficiently lit 😉. This is because the current shaders use the texture's color as the final color value to draw. Let's change this so we can later see the effects of lights being shone on Jergen.

First, we'll add some ambient light. I'm struggling to explain ambient light in my own words, but to me it's just the base light level. All the light that is scattered around from multiple light sources, so you can't really make out where the light comes from anymore. Therefore, neither distance to, or direction of the light source matter. I feel the fragment shader does a better job at explaining it.

// Fragment shader
#version 330 core

in vec2 TexCoordinate;
out vec4 FragColor;
uniform sampler2D tex;

void main() {
    // ambient light, kind of a base light amount that is just there.
    // All zeros would mean it's completely dark.
    vec4 ambient = vec4(1.0f, 1.0f, 1.0f, 1.0f) * 0.2f;
    FragColor = texture(tex, TexCoordinate) * ambient;
}

The ambient light is white, but dimmed to 1/5 of.

While proof reading this post, I realized that I made a mistake. I'm also making the final FragColor transparent by multiplying ambient by 0.2f. This makes the entire image darker. All the images in this post contain this mistake. The GIF at the end corrects this and uses vec4 ambient = vec4(0.2f, 0.2f, 0.2f, 1.0f); instead.

For completeness' sake, here's the corresponding vertex shader:

// Vertex shader
#version 330 core

layout (location = 0) in vec3 inPosition;
layout (location = 1) in vec2 inTexCoordinate;

out vec2 TexCoordinates;

void main() {
  gl_Position = vec4(inPosition, 1.0);
  TexCoordinate = aTexCoordinate;
}

Can you still see Jergen? It's quite dark where he is.

Next, we add diffuse lighting. Diffuse lighting is the light that comes from a certain light source. Therefore, in contrast to the ambient light, the direction of the light plays a role in how it affects the object it illuminates. If our object faces the light source, it should be brighter, if it's facing away it should be in shadow. We'll need to give the light source a position in our world. With that, we can then calculate the direction from our object to the light.

Since the fragment shader doesn't know the world position of the fragment it shades, we need to pass it in from the vertex shader.

Let's add a new output to the vertex shader and assign a value to it.

// Vertex shader
// ...
out vec2 TexCoordinate;
out vec3 FragPosition;  // <- added

void main() {
  gl_Position = vec4(inPosition, 1.0);
  TexCoordinate = inTexCoordinate;
  FragPosition = inPosition;  // <- added
}

Then we add the corresponding input to the fragment shader. We also define variables for our light source and a surface normal for the object we want to illuminate. The variables are described in the following code snippet.

// Fragment shader
// ...
in vec2 TexCoordinate;
in vec3 FragPosition; // <- added
// ...
void main() {
    // ambient light, kind of a base light amount that is just there
    vec4 ambient = vec4(1.0f, 1.0f, 1.0f, 1.0f) * 0.2f;

    // The color our light emits, Halloween season is around the corner,
    // so let's make it a creepy red.
    vec4 lightColor = vec4(1.0f, 0.0f, 0.0f, 1.0f);
    vec3 lightPosition = vec3(10.0f, 1.0f, 0.0f);
    // We normalize the direction vector because we're only interested in the direction.
    vec3 lightDirection = normalize(lightPosition - FragPosition);

    // Next we define a normal for the fragment. The normal defines which way a surface is facing.
    // With this information we can figure out if it's facing towards the light source 
    // and should therefore be illuminated. 
    // Our normal for every fragment points to the right side towards the light source.
    vec3 normal = normalize(1.0f, 0.0f, 0.0f);

    // We use the dot product to figure out how much the surface normal and the light direction align.
    float diffuseStrength = max(dot(normal, lightDirection), 0.0f);
    vec4 diffuse = diffuseStrength * lightColor;

    // We now add the diffuse light component to the already existing ambient component before multiplying.
    FragColor = texture(tex, TexCoordinate) * (ambient + diffuse);
}

If we calculate this for the top left corner of the rectangle (-0.25, 0.5) that displays Jergen we get.
lightDirection = (10, 1, 0) - (-0.25, 0.5) = (10 - -0.25, 1 - 0.5, 0 - 0) = (10.25, 0.5, 0)
which is (0.998812, 0.0487226, 0) when normalized.

The strength of the diffuse light is then:
diffuseStrength = (1, 0, 0) * (0.998812, 0.0487226, 0) = 1 * 0.998812 + 0 * 0.0487226 + 0 * 0 = 0.998812
The diffuse light is therefore strong, which makes sense as the surface normal is almost parallel to the light direction. Let's see how this looks.

Jergen bathed in creepy red light.

Let's see what happens if we change the normal to point upwards. This way the normal and the light direction are almost perpendicular, which should result in a much darker image.
But let's calculate the diffuse contribution before we actually check.

The lightDirection stays the same. The new diffuse strength is
(0, 1, 0) * (0.99812, 0.0487226, 0) = 0 * 0.998812 + 1 * 0.0487226 + 0 * 0 = 0.0487226, which matches our expectation.

And now, curtains up. Jergen's almost gone again.

Now that we have some basic lighting in place, let's go a step further and introduce normal mapping.

A Map of Normals

So far we've used the same normal for all fragments and have set it directly in the shader. We could define the normals in our vertex data, along with the positions and the texture coordinates. That way we would be able to specify a normal per vertex. For Jergen that would mean we could specify four vertices as Jergen is just a rectangle. But, we want more. We want to be able give different normals to Jergen's face, his backpack, .... The way to do this, is to use a normal map.

A normal map is just a texture in which the colors represent normal vectors. You can check out an example in the Wikipedia article on normal mapping

If we wanted to reproduce the same lighting we currently have, we'd just create a texture where each pixel contains the value (1, 0, 0), or (0, 1, 0) respectively. But as mentioned before, we want different normals for (almost) every pixel. But how do we create a normal map? An easy way, at least for pixel art with few pixels, is to just pick colors from an existing normal map - like the one from Wikipedia. And that's exactly what I did. First, I copied the existing texture of Jergen and started to pick colors from the normal map.

Now comes the fun part, we're going to use that map to give Jergen some more variation. Since we'll use a separate texture for the normal map with the same dimensions of the main texture, we can reuse the texture coordinates and keep the vertex shader as is.

The fragment shader needs a few changes though.

// Fragment shader
// ...
uniform sampler2D tex;
uniform sampler2D normalMap; // <- We need to add another sampler for the normal map
// ...
void main() {
    // ...

    // We now use the normal map to get the normals for the current fragment
    vec3 normal = normalize(texture(normalMap, TexCoordinate).rgb);

    // ...
}

And that's all she wrote.

And here's the same thing with a light source that circles Jergen.

And another bonus (no idea why the video quality is so bad after uploading):

The Struggles

There was one small hiccup at the end when I switched to using the normal map in the shader. The texture had no effect. So I first changed the first texture to the normal map file to see whether I could draw the normal map - everything OK. Reverse everything, try to bind the normal map to texture unit one, draw the color texture on unit two, ... In the end I just forgot to activate the second texture unit - d'Oh.

The math was also easier than I had anticipated, mistook the dot product for the cross product, ...

All in all, this one went relatively smoothly. Dividing the task into sometimes ridiculously small steps, like just adding one more variable to the shader and testing it or defining variables within the shader instead of passing them from the host code, helped a lot.

Thanks for reading and keep on struggling.