gridbugs

I’m making steady progress on my gpt fat disk image tools project.

To test my disk image tool, I set up a spare USB stick with a GPT partition table and FAT32 partition.

I’ve started working on a new personal project: GPT FAT Disk Image Tools.

About a month ago I switch to FreeBSD on my laptop - a Lenovo Thinkpad T470.

Several times in the past few weeks I’ve been frustrated by the lack of a tool for generating a disk image containing a partition with a filesystem containing a set of given files.

On the road to setting up basic memory-management for my hobby OS, I found that the bootloader I’ve elected to use (bootboot) doesn’t tell the booting kernel about all the available physical memory.

In the last day I’ve found bugs in two different kernel code samples I’ve been using as a reference for my own hobby OS.

My goal for the last couple of days has been getting my hobby OS project to the point where it can switch into user-mode.

My hobby OS adventure has led to the need to handle interrupts.

In x86 processors, the Global Descriptor Table is a data structure that stores characteristics of regions of memory known as “segments”.

Today I solved an os-dev problem I’d been stuck on for a few days.

I managed to resolve my problem from yesterday, though I’m still not satisfied that I understand why it now works, so it’s possible that it just works by accident.

I’m working out the shortest path from a kernel-mode program that prints “Hello, World!”

Yesterday I wrote about Homogeneous Coordinates.

Matrix multiplication is awesome.

Tonight I set myself the task of printing some text over a serial port in a tiny kernel mode program that boots with the BOOTBOOT bootloader.

Early this year I spent a week trekking in Nepal.

This is the final part of the tutorial, in which we’ll add equipment.

In this part we’ll update terrain generation logic such that the game gets more difficult the deeper you descend into the dungeon.

Today I finished writing the code and tutorial pages for the tutorial I’m making as part of roguelikedev subreddit does the complete roguelike tutorial.

A few years ago, at a past job, I received a piece of advice from a code reviewer which I’ve treasured every since: “describe a change in terms of the problem it addresses, rather than the solution it implements”.

A month or so ago I started following the first edition of writing an OS in rust which is a tutorial for writing an OS in rust.

I’m going to stop boiling the ocean in an attempt to run OpenBSD on my laptop and accept that the tools that I need to be productive in my personal projects currently don’t support OpenBSD.

I underestimated my requirements of a rust compiler: I occasionally need to use the nightly compiler rather than the stable compiler to enable experimental features I need to be able to install the web assembly target for rust so I can compile my games to…

Rust projects tend to start using new language features as soon as they land in the stable compiler.

In this part we’ll add stairs, and multiple dungeon levels, as well as the ability to upgrade the player character as they descend the stairs.

A few days ago I listed some problems I need to solve before I consider switching to OpenBSD in earnest.

I’m working on a series of roguelike tutorials as part of roguelikedev subreddit does the complete roguelike tutorial.

I’ve been toying around with OpenBSD in a virtual machine to see whether I could switch to it as a daily driver.

Back in 2010 (which wow - over 10 years ago!)

Last night I rewrote all the CSS in this site.

I recently grew frustrated with the infrastructure running this website.

In this part we’ll make it possible to save and load games, and add a main menu.

First Post!

In this part we’ll introduce ranged scrolls and targeting.

In this part we’ll introduce items, and add an inventory menu.

In this part we’ll add a heads-up display consisting of a health bar and message log.

In this part we’ll imbue NPCs with artificial intelligence, and make it possible for them to deal and receive damage.

In this part we’ll populate the dungeon with enemies.

In this part we’ll implement visible area detection, so players can only see what their character can see, and what they remember seeing.

The definition of “roguelike” is hotly debated but one aspect we can all agree on is that levels must be procedurally generated.

In the previous part we got a single ‘@’ sign moving around the screen.

For getting set up for this tutorial, see Part 0.

This is the first of a series of posts where I follow the python tcod roguelike tutorial but instead of programming in python using the tcod library, I’ll be programming in rust using the chargrid library, which I’ve been developing for about 3 years.

This post is about a Rust program… $ cargo install conway-nes …that prints out a NES binary… $ conway-nes > life.nes …that runs Conway’s Game of Life!

A traditional roguelike where the outcomes of attacking and defending are pre-determined and visible.

It’s done!

I spent today play-testing and tweaking mechanics to make them more fun and balanced.

Today I focused on upgrades.

Lots of work on mechanics today.