Ever since I started using LINK! I found it very handy to add all the things that I wanted to accomplish right in the same .link file I did my planning.

I’d simply do this by adding an asterisk and a space before typing out my task.

* This task is incomplete

When I was done with the task, I’d replace the asterisk with a capital ‘X’.

X This task is complete

It was a clunky system but it mostly worked.

I never figured out how best to “cancel” a task I was no longer interested in without just removing it, something I really don’t like doing.

So I felt it was finally time to add them to LINK!

Now lets face it. The color scheme I originally picked is fine, but it also was mostly just the default colors I use which I always intended on changing.

So I’d like to introduce LINK’s new Light Theme

The Quest for Ever Better Performance

Look!

You see that? That’s 0% CPU and GPU utilization, baby!

Well… mostly.

I’m still struggling to keep it at 0% CPU usage but I’m getting closer. Windows’ task manager generally reports between 0.3-0.8% while idling but it does reach 0% so I’m calling it a win.

The main issue was that I was running way, way, way to many garbage collection steps (by about 4-5 orders of magnitude more often than was necessary). My program doesn’t create much garbage though so I could very likely reduce this even further.

Another issue was that I was “presenting” all objects to the screen every frame whether they needed to be or not. Now it only presents if there’s been a change which saves quite a few cycles.

The last issue is a doozy as it’s related to event handling that I can’t effectively solve with the tools I have available.

Disclaimer, I haven’t delved into this problem super thoroughly so I’m probably wrong or at the very least a bit off. I apologize in advance.

With that out of the way, every time the function love.event.pump is called, the program has to get a mutex lock from the kernel. Kernel calls and obtaining a mutex lock are expensive operations and there’s no way to avoid calling love.event.pump without the program hanging and becoming unresponsive.

I’m hoping I’ll find a solution to my problem (there’s got to be one because other applications have no problem idling at 0% with zero fluctuations) but for now I’m just chosing to ignore it.

When the program is in the background, unfocused, it’ll run at a significantly lower tick rate so love.event.pump is called less often. If the mouse is over the program it’ll run at a reduced but still responsive tick rate.

I’m not really convinced this fix did much but it was simple enough to add so I didn’t waste much time adding it and so far hasn’t caused any issues so I’m going to keep it.

But… Where’s the Update?

Simply put, I’m not ready.

I’ve been adding a ton of different smaller features and am working on some bigger features that are still broken and largely untested.

I want to have more time to fully test these features and work out some implementation issues before I unleash the update onto the world.

LINK is still in early development and while I’m not afraid to make breaking changes, I still prefer not to.

Now that LINK is getting closer and closer to a 1.0 release, I need to seriously consider what I’m looking to accomplish with this software.

While the features I’ve been working on are things I’ve been wanting to add since I started working on LINK, I also am not interested in adding features that don’t in someway benefit the core experience.

I have fragments of ideas of where LINK is headed but they haven’t been fully fleshed out so I’m going to take some time to work on that.

Also, one of the first requests I got after LINK’s initial release was to add some animated GIFs showing LINK in action. While I’ve done it before, it’s never been a big part of my workflow so I’ll be stumbling through the process.

I want the next release to be something special but this takes time.

With all this in mind, the next update to LINK won’t be for awhile but I’ll be sure to keep you updated on its progress.