I was alerted on Twitter of a 100% CPU usage on Linux. So I took a look at it myself.

Noxico 0.1.2.1 on Windows 7 with .Net: CPU usage at 20-something.

The exact same binary on Linux Mint (on a VM) with Mono: CPU usage at around 85%.

Different ways of expressing the usage aside, I’m really starting to feel Mono compatibility is not worth the effort. If it’s not recent versions of MacOS X breaking the keyboard input, it’s inexplicably high CPU usage and lowered framerates. At least the broken graphics after I reimplemented PNG mode made a modicum of sense.

So by now I’ve pretty much had it up to here with Mono compatibility.

And the best part is, if I were to rewrite the game in something that can run natively on both Windows and Linux (let’s assume multiple binaries sharing a single set of data files)… I’d have to rewrite the entire game.

Which I’ve been working on since November 2011.

Is Mono compatibility worth the effort?

After some deliberation with a certain other Kawa, I’ve removed the need for food from Noxico. Foodstuffs now only serve as healing items, with minor TF effects.

They already did that, but there’s no more need to sate your hunger.

Instead, screens can run out of enemies. That way you have to keep moving if you want to keep getting better.

Perhaps I’ll add a thing where newly-spawned enemies get the items dropped by earlier-killed ones?

A while back, I added specific script handlers to items. Aside from when using them, there were optional scripts for equipping and removing items.

Just now, I added timers. To set them up, the item must have a timer token and a timer script block. The token can have a minute count as its value, which defaults to 60 if missing. Every time that amount of time has passed (which is checked in a bad way for now but whatever) the script is executed.

If the timer token has an evenunequipped child token, merely having the item in your inventory triggers the effect. If not, it’ll only activate while worn.

It is done. Later, I’ll add a thing where pressing OK actually applies the new settings as the game is still running. Until then, it asks you to restart.

Working on an internal options screen so you don’t have to work directly with that INI file. The brackets mean that it’s using the i18n system but I haven’t provided any actual text for them yet.

I’m particularly well pleased with the fonts list. Unifont is practically built-in, but those other choices are only there because I put dejavu.mix and fixedsys.mix in the game’s directory.

Mind you, function before form is in effect. I’ll make it spiffy later on.

Dutch words.xml file. As incomplete as the i18n effort on the whole is at this time, it certainly works better (and is more correct) than the Japanese version.

Also smaller, because this doesn’t add 80+ double-size font sheets.

(“Charisma, climax, sluwheid, wellust, stimulatie, gevoeligheid, snelheid, kracht” in case you weren’t wondering.)

I can’t math, and yet I managed to add metablob-based water.

Japanese support has left the labs. It’s in an extension module twice the size of the main data file right now, because it contains 83 pages of kanji to supplement the 20 that the game starts with.

At such a time I’m glad to have added fallback support, or this’d break when running with the DejaVu font.

Bottom-of-the-screen messages are now 20% cooler. It was a little tricky to have them wrap and use their correct colors on the second line, but it’s there. Also, I had to completely mess up the color manager because the text writer needs them called by name. In other words, wow am I glad they keep their color names in their token trees!

Just cocking around with yet another working copy. Aside from the length and padding methods not accounting for the width difference, this actually works like a charm.