I’ve been working on some larger features that I’m excited about but once I got into it realized it’s going to take longer than expected to implement.

In the mean time I squashed a few bugs along the way and made some improvements.

First off, I had to make some changes to how a .link file is generated to fix a bug with any note that had leading or trailing white space characters. I’ll explain more in a bit.

The biggest visual thing I changed was to remove the date and time in LINK’s status bar. Originally I added it to make sure my program hadn’t crashed or stopped responding. At least every second, something should change.

However, LINK is much more stable than it once was (but still, it’s in Alpha and bugs pop up at the most inconvenient of times) and it’s become redundant with the date and time located conveniently on my task bar.

Don’t worry, if you like having the time can be changed by opening game.cfg and change the variable DATE_TIME from false to true.

The New .link Format

While in this stage, the link format will be in flux and is subject to change at my whim. This is one such whim.

Since I sometimes use spaces to make notes wider or to center text within a note, it’s annoying to have those spaces stripped when the file is reloaded.

The problem is because my parser automatically strips any leading or trailing white space. This is working as intended, but has the side effect of removing white space that I wanted preserved.

So now, when a note has any leading white space I add the ASCII control character “STX (start of text)”. And when a note contains any trailing white space, I add the ASCII control character “ETX (end of text)”.

If it happens to have an STX prefix or ETX postfix character already, I’ll add another that’ll be stripped when loaded.

I don’t love this solution so I’ll be exploring alternatives, but if you’ve written any parsers yourself, this is something you’ll want to be aware of.

If a note has no leading or trailing white space characters, nothing will be changed.

Configuring LINK

Ever since its inception, game.lua was my way of picking which .agpack to load. It was a temporary solution in lieu of a much more complicated one.

Since I’ve started to use the file game.lua to hold some customization options for LINK, I decided I was going to need to stop that.

The problem is, I loaded game.lua directly and didn’t sandbox it in any way so it would be incredibly easy to inject some bad acting code into the program. If not now, it will become a problem later down the line.

Of course, I never intended on it being something the end user would modify so I myself included logic that really has no business being there.

This was also before I had a fairly stable INI parser so I went with the simplest solution.

Now that I expect anyone to open and modify it, a static configure file is much more secure. I don’t have to worry about some silly bug stemming from a poorly written config file.

Graphics Rendering

Found more render bugs.

The problem with not rendering all the time is there’s always this one little feature tucked away in a corner of the program that causes a screen update but doesn’t let my render know about it.

When I first write a program, I render everything whether it need to be or not. Partially because I don’t know what needs to be rendered or not and partially because I haven’t added that bit of code in yet.

It doesn’t help that I think in every game I’ve released, I’ve used slightly different ways to create and render objects that require a bespoke solution to not render then. I don’t have to rewrite everything, but I need to hook it up properly.

It’s kinda like the time I installed a CD player in my old car. Sure, the new CD player comes with a selection of adapters but none of them fit my car. So I had to match each wire up and connect them manually with a soldering iron (or at least I should have been using a soldering iron).

So I have this engine that’ll not render items that are off screen, but I wrote my game code in such a way that it’s incompatible without matching all the wires connecting them with my soldering iron.

Bugs?

Always more bugs.

First, when copy/pasting the “goto” buttons, they’d be drawn off center, unless you’re copying then with a note… it seems.

I’m not exactly sure why there’s that disparity but I threw some code at the problem, taped it up, and it works a little more as intended.

Second, I never checked to see if my rectangle would be rendered after I monkeyed with all that code. That’s working better too!

Third, I added Welcome.link back into the release build. I had forgot to add it to the final build script.

What’s Next

Well, I have a few features I’m working on, some too early to talk about, that I’m running into some bottlenecks with.

The problem is becoming an architectural one that has problems down to the foundation.

Not to worry, I’ll be able to rewrite the logic necessary without needing to start from scratch.

The first thing I’m going to tackle is what I’ve been calling “transactions”.

A transaction occurs when a note is created, moved, modified, or deleted. There’s more but those are the main ones.

The problem is, those transactions occur wherever I felt was appropriate at the time. I stand by those decisions and would do it the same way again but they’ve outlived their usefulness.

My approach is going to be to move the processing of all those transactions down to the end of the update loop. Anywhere I currently have a transaction, I’ll set a flag or push data into a queue that’ll be processed near the end of the update loop.

This should be a relatively straight forward process and I’m bound to discover and fix a ton of bugs along the way but it’ll take some time.

I’ll publish any improvements along the way and I have a few smaller features I’d like to add that won’t interfere with my refactoring.