Posts

A few months ago, I decided to redesign my personal site again, after previously unifying the design of the various (mostly inactive) blogs I was operating in 2023. Here, I want to discuss a little of the motivation behind rebuilding from scratch, and the process it took to get here.

Why a full rewrite?

Since I had an existing custom theme, coffeeline, it may seem a strange decision to rip everything down and build from scratch. There were a few factors involved, but the largest (by far) is simply that the content I want to display on my site has drastically changed in the last three years.

At the point of unifying my blogs, I was in my penultimate year of university and in the throes of a job search, which unfortunately resulted in the landing page for my site becoming a defacto CV. Now gainfully employed (in this economy!) and out of university, this makes little sense. I want people to see the things I’m writing, not an executive summary of my very short career.

One other factor is the state of my prior custom theme. The 2023 site design is a hackjob consisting of an existing open-source Hexo theme, bits and pieces adopted from other blog designs, and a heap of small hacks and shortcodes to achieve a consistent look across the set of existing posts. Put bluntly, it was a mess.

This year has been one unlike any other in many ways, which has reflected quite heavily in my Japanese immersion. Following my decision last year to take the plunge and move to Japan, along with a career switch to the game industry (if you can call anything I was doing prior a career), I finally managed to move this year and have begun living and working here full-time. With all the chaos of moving countries and getting set up in a new job, I’ve tried my best to keep my Japanese immersion consistent and at a decent pace in line with prior years, however as I think you’ll see in the stats my content consumption has leaned heavily in one single direction - books.

This year has been an unexpected one in many aspects, especially in terms of my Japanese immersion. After previously having such a packed year in 2022 with a boatload of memorable milestones, this year feels much like a calm after the storm, continuing steadily and diving deeper into personal preferences and hobbies, rather than focusing on exam study or aiming toward any specific goal. That isn’t to say this year was without note, though - I officially passed the JLPT N1 with a score of 156/180 (with a perfect reading section!), and ran through the whole 就活 gauntlet to receive a job offer, and made plans to move to Japan late next year.

A new API proposal being prototyped within Chromium, and the brainchild of a team comprised solely of Google engineers, has become a topic of heated conversation recently - Web Environment Integrity. This proposal has actually been public on GitHub from as far back as late April, however has gained the attention (and ire) of much of the larger developer community and users alike due to its highly polarising end goal and far-reaching implications if implemented across web services and devices.

What does Web Environment Integrity seek to achieve? I’ll let Google’s Ben Wiser (@RupertBenWiser), one of the creators of the proposal, explain it for me.

[WEI seeks to] allow web servers to evaluate the authenticity of the device and honest representation of the software stack and the traffic from the device.
– Ben Wiser, “WEI Explainer”

Essentially, WEI is yet another trusted computing technology. It aims to allow websites to verify the platform and environment of the browser using cryptographically signed “attestations”, provided by a limited set of “attesters” which through some mechanism determine the level of trust for the user’s platform. We’ve seen similar concepts to this introduced into many areas of software in recent years, the most notable of which that comes to mind being Windows 11’s hard requirement of a TPM, and they are, across the board, incredibly controversial.

Hello! If you’re viewing this site after 21st June, 2023, you may notice that the design of this site has changed. In fact, if you’re viewing any of my blogs, you may notice that they have all changed, be it my programming blog, Gengo! 言語 or 脇道の看板. To explain why this all happened in the first place, I’ll present a little bit of backstory.

The Backstory

I’ve run several different blogs for several different purposes for quite a number of years. First came my programming blog, which has always been on the apex domain of the site you’re currently on, c272.org. From 2016 onwards, I continued to (infrequently) update the site and its design up until late 2018, adding posts about various programming projects I was working on at the time, and creating a fair few cringeworthy articles, which have thankfully been lost to time.

Fast forward three years, however, and I wanted to start writing about topics other than programming on my site. One large factor in this was that I began learning Japanese and eventually decided to take on the JLPT N1, which motivated me to write about some of the interesting topics I had come across in my language learning process. However, I wasn’t about to suddenly start posting completely unrelated content onto my main blog, which had (up until this point) been entirely programming focused. Also, I wanted to start writing Japanese language content, which obviously wouldn’t fly in the same post feed as English language programming articles.

This year has been a very interesting (and productive!) year in terms of my Japanese learning, and certainly not one with a moment to spare. I progressed from being halfway through TOBIRA in January and finally reading my first Japanese novel, to in December having taken the JLPT N1 and reaching my goal of reading 52 novels this calendar year.

Here I’ll take the opportunity to look back over all of the content I consumed this year, and hopefully talk about some of both the standouts and letdowns. I’ll also present a portion of the interesting reading and immersion data I collected on myself this year, which should give you an idea of roughly how my time was split up, and in what (unfortunately embarassing) areas I invested far too much time into. Before this though, a quick, mostly complete overview of everything that I consumed this year.

In 2022, I –

• Read 52 Japanese books, a mix of fiction and non-fiction.
• Listened to 172 podcast episodes.
• Completed 55 series of anime.
• Watched 1084 hours of YouTube in Japanese. (good lord…)
• Played through 11 video games in Japanese, on PC and Switch.
• Spoke for ~86 hours in Japanese.

While barely making my previous 新年抱負 of completing a book every week (it certainly didn’t help that I only started properly reading in March), I feel like on the listening front I definitely made progress I can be proud of. I can also definitively say that my speaking ability is in a much better place than it was at the beginning of this year, that being almost non-existant.

As I write this, I have just started studying using Shinkanzen Master N1 (新完全マスターN1), after having finished the N2 series (and learning that the JLPT exams in the UK are cancelled this year - again!), and was reminded as I went to buy my new textbooks that it has been just under a year and a half since I ordered my copy of Genki 1, and just about one and a half years since I began considering studying Japanese at all. With this in mind, I thought it might be a good time to reflect on what I’ve learnt so far, what resources I’ve used, things I enjoyed, and what I would do differently if I could start again from scratch. There have been a million posts on this subject before me, and there will probably be millions after, so take this as one experience and opinion in a sea of many (probably more qualified) opinions!

Sometimes you may want to apply a shader or graphical effect to your game when drawing, which this article will explain how to do.

To apply a post processing effect to the screen, you can override SadConsole’s default drawing functionality, and then apply your own custom draw commands.

To do this, you attach a new DrawableGameComponent to SadConsole’s game instance components, which is set to draw after SadConsole has finished creating the frame for the default screen.

This DrawableGameComponent should then access SadConsole’s final render surface, and apply whatever custom draw code is needed.

Method

Setting up the Class

To begin with, you’ll need to create a new class that inherits from MonoGame’s DrawableGameComponent, and override the constructor and “Draw” functions so that you can draw to screen.

public class MyCustomPPFX : DrawableGameComponent
{
    public MyCustomPPFX() : base(SadConsole.Game.Instance) 
    {
        //...
    }

    //When we need to draw to the screen, it's done here.
    public override void Draw(GameTime gameTime)
    {

    }
}

After this, you’ll need to have your constructor load in the shader you want to use. This can be done through two methods:

We all have the same issue; Should I clip all my props? Won’t it make players annoyed and cause frustration when something that looks like it should be wallbang enabled/walkable is not?

The answer to the first: Yes. The answer to the second: Yes.

There’s a compromise to be made here, one that a lot of mappers struggle to find a balance between. For a great example, look at Valve’s maps, especially fine polished ones such as Dust2. These take a more balanced approach to clipping, as well as employing some clever techniques to make the clipping as smooth and unnoticeable for the player as possible, such as at the stairs leading to B as seen in the cover image of this post.

This isn’t without it’s issues, obviously, so don’t take these to be the holy grail of proper clipping, as you can still get stuck at specific points on the map, but it’s a good general practice to follow. The two easy ones are as follows:

• Clip areas that need to be smoothed out.
• Clip areas where the bomb could get stuck, such as in small corners or areas behind crates.

However, a more contentious example would perhaps be the idea of:

Over the past couple of months, apart from writing my book, “You Suck at Programming” ¹, I’ve been working on an emulator/interpreter for the famous computer simulation “Little Man Computer", by Peter Higginson. It was created many years ago to help students learn about how the CPU and memory worked and interacted with each other, and was a great way for me to try and understand some lower level emulation, as it has an instruction set consisting of just nine operations. These operations are:

ADD – Addition
SUB – Subtraction
DAT – Data Storage
LDA – Load Data
STA – Store Data
HLT – Halt Program
BIZ – Branch if Zero
BRA – Branch Always
BZP – Branch if Zero or Positive

They all sounded fairly simple to implement, so I went about creating the first prototypes for the interpreter of this program. Initially, I tried to create a dictionary with 99 data spaces to store my data, however this ended up causing a lot of problems for me down the line. I eventually had to scrap the entire idea, and ended up just using a simple two dimensional array. Now that that was sorted, I needed to somehow get a standard data format including data and addresses, and have an interpreter read them properly. Luckily, Little Man Computer is close enough to a real computer that it uses “opcodes”, small (in this case 3 character) strings which tell you which command is being executed, and at what address. So, the format I came up with looked like this: