A few people have still experienced the save icon corruption on PS4 and have posted to the Steam forums for info. Mart from RSG just posted the
following steps which should fix the issue for anyone that’s upgraded from the previous build, but still has problems:

Make sure the game isn’t running.

Check that you’re running V1.02 - you can do that by highlighting the game icon on the PS4 home menu, pressing Options and choosing Update History. If you’re not, download the update from the same Options menu.

From the PS4 home menu, go into Settings > Application Saved Data Management > Saved Data In System Storage > Delete and then go to Lumo.

You should see two files - Player Preferences and Lumo Save Slot 0. The latter is the one that’s causing all the trouble (the system should even tell you it’s corrupted), so delete it.

Exit back to the PS4 home menu and start the game again. The game will create new save data and that should be the end of all the problems.

The trouble appears to be that on PS4, deleting/reinstalling the game does NOT remove the save files - you have to do it manually.

I know this is a massive ball-ache if you’ve managed to get a fair distance through the game, and I can only apologise. As far as we know this does solve the
issue and v1.02 should be stable for you.

The Windows 10 Anniversary update caused a lot of weird issues with how gamepads work, leaving Lumo and a bunch of other games
with broken controls. I’ve just pushed out a new build to Steam that should fix most of these problems.

It’s been tested with the following pads:

PS4

Xbox 360 (Wired and Wireless)

XBox One (wired)

Other joypads should work, but may require you to define your own controller mappings in Settings->Controls. Fight sticks are not directly supported, unfortunately,
as many of them don’t identify themselves as pads, even though the may map to something like the default Xbox 360 layout (like my SF IV Fight Stick does).

In addition to this I’ve re-written the redefine controls screen [and back-end], fixing several small issues that have been in there since release.

Other fixes:

Several affected achievements re-written

Small balancing changes

Clue added to the Ice Cube Stairs room

Mac and Linux were unaffected by the original bugs but I’ve put out new versions for all platforms just in-case. DRM free builds are uploading now and should go live in the next day or two.

In addition - if this wasn’t bad enough - Playstation 4 owners have been plagued by a save icon corruption for the last month. Withouth going into too much detail (coughUnitycough) I can
confirm that the fix for this, on both PS4 and Vita, went live today. Phew :)

Apologies to all affected by these breakages, I know it’s been a complete nightmare. :(

God I miss this stuff. The last 10 days I’ve been down with a snotty cold. The first week was a complete wipeput because Finland, bless it, hasn’t
quite caught up with the idea of dosing yourself to the eyeballs with a cacophony of drugs to ease
yourself through. sniff

It’s not been all bad though.

Lumo received its first bit of fan art!

I’ve never been given something like this before. I was a bit lost for words, tbh.
Complete surprise, but it cheered me up no end. Thank you Cris_Cat_Kun, you made my day.

Lumo’s out in Japan now, and got a respectable flush of 7s from Famitsu. Again, another bucket list
tick, this. I love magazines, and I love seeing my work in them. Famitsu is one of the longest running
and most famous, and even today, it’s a healthy 230 pages of madness. Props to all at Rising Star who
worked behind the scenes to make this happen.

Even the Finnish press have got in on the action!

Annnd, I’ve finally got my hands on the boxed version.

Again, another one off the bucket list.

Since Sudeki I’ve had a little ritual of going into the local game shop, seeing what I’ve worked on nestled
among all big games of the day, and buying it with a big grin on my face. I didn’t catch Lumo in the wild but I was able to
buy it off Amazon, which still counts IMO.

Development wise it’s been a bit slow, what with the man-flu, but I’ve had some productive train coding sessions the last few days.

One of the things I’ve been tempted to do for Neutrino since the start is roll all my tools into the framework so I can carry it all
forward to multiple projects. Key to this is the map editor. I started scratching out what would be required for this, but decided to
pull back. It’s obviously going to grow arms and legs before taking on a life of its own. I’m old enough to know better.

The obvious alternative is TileD, an open source map editor that’s been around, in one shape or form, for years. I’ve looked
at this before for Beat Arena (another project I might return to one day) and passed because it’s quite rigid and a little old school. It’s
not changed much since I last looked at it, and the limitations of using fixed size tiles and rigid grid layouts is going to get on my nerves very quickly,
but it’s a sensible short-cut to create the background layers for Neutrino. I can write some custom tools for spline editing and wave triggering.

There are still a couple of hurdles with this approach:

TileD outputs to TMX or JSON formats, neither of which I support. The Neutrino framework uses libconfig for parsing the various text-based data files,
and I’m loath to add new dependencies. (There’s a good argument for dropping libconfig and just using a single header JSON library, but that’s a question for
another day.)

TileD also expects you to be working with a texture page of square tiles, which is fine, except I have no intention of just using square tiles in any of my games, or
of introducing extra draw calls just so the square tiles can be on their own t-page…

Currently I output texture pages via a build step that runs the individual art assets through Texture Packer, an insanely good
tool for taking a collection of images and spitting out an optimised t-page. (BTW, if this isn’t in your tool box, it should be.) This leaves me with
a .png containing all the sprites, and a text file containing all the sprite meta-data (position within the texture, size, etc).

TileD doesn’t seem to have a way for
me to mark the individual tiles in a t-page by hand - due to this expectation that they’ll be square, so easy to identify in the texture page automagically - meaning I have to drop in individual
assets in order to make maps. Not a problem, except the ID of tiles in TileD’s output will likely differ from the meta-data of the texture page.

It’s stuff like this
that has tempted me to write my own map editor for the last 6 or 7 years…

Anyway, the problem was easily solved with a Python script to pre-process the TileD JSON output, fix the mappings, and then spit out a libconfig format file that
Neutrino can then use to build a VBO of the tile map. This can be inserted into the build process, or just done as and when it’s needed.

Building a VBO of a tilemap is one of those jobs that I must have done 3 or 4 times now. The only thing I think I’ve written more times is a text writer. Literally, the
code to parse strings and spit them onto screen. I keep promising myself that “this will be the last time”. We’ll see if this one is…

When I get around to it. Obviously this
week I prevaricated and put in a few debug bits and pieces that I know I’ll need, the most important of which was the debug fly cam. (Mainly cos I know my first pass at
the tile map will probably end up in the wrong location, so I’ll need to fly around to look for it…)

This ended up being a fun little job as mapping keyboard and joystick input to controls for various player actions involves a bit more than you’d think. For a start, joypads
can be added and removed at runtime so you need to be able to move controllers between players, and keyboard layouts differ between locals, so you can’t just “detect a letter”
and be done with it. SDL’s docs have a couple of gotchas around how you handle this stuff, but I was able to get it all working nicely. The only thing that’s missing
is exposing an interface for assigning controllers or redefining controls. As that’s game specific I figure I can put that off for now.

I’m hoping I’ll get a day clear to go back to Oh Snow next week, but with three teaching courses on the go that might be wishful thinking. Either way, I’ve had
fun this week. In between the sneezes.

I thought I’d do a quick update before I head out to the UK this weekend.

I’ve had a bit of fun this week. Neutrino moved forward for the first time in a long while. I’ve integrated ImGUI, a lovely
header based widget library for games and other multi-media. This is one of those “where have you been all my life” bits of code, that slotted straight in and opened
up a really simple, clean way to do debug output, windows, memory inspection and the like. So far I’ve only added some simple performance counters, but the plan is
to use this to build up the internal editors for things like splines, particle effects and bullet patterns. I’m having a bit of a man crush on it…

Oh Snow’s also moving forward. The base character is done, skinned and rigged. I had to make a few tweaks since the last update, and today I sat down to try and get the UVing
into shape. I’ve not used any of the UV tools in Modo before (can you spot a pattern here?) and to be perfectly honest, for Lumo I got away with everything being basically box
mapped, so don’t really profess to even know the terminology. Every day’s a school day.

As ever, Modo’s been good to me. I made a lot of mistakes, and had to kinda stumble my way through the various options to work out what does what, but I finished today with a pretty
clean set of UV islands, and what appears to be - to me at least - reasonable texel density.

All this highlighted some problems in my modelling workflow. As a lot of the geometry is mirrored, I could have saved myself a lot of time if I’d done a quick UV map on the model
before I mirrored it. I’m wasting UV space for things that could be overlapping. I’m not sure if there’s a quick way to do this after the fact, other than manually line up
the appropriate islands. I might need to ask around on that.

For this game it’s not really going to be a problem…

Also, I should have done the UVing before the skinning, as I noticed a few problems with a couple of quads that meant going back in to make some tweaks. Fortunately this is simple in Modo,
but something to bear in mind in the future.

The paint tools in Modo turned out to be really useful for finding where my UV seams were causing problems, and really drove home how quickly things can look shit if there’s too much
distortion in the quads. Today I found all this out after I thought I was ‘done’, so I scrapped everything (basically the whole day’s work) and started again. Once I vaguely knew what
I was doing the whole process took less than an hour.

I’m having to stop myself from getting too stressed over the slow progress I’m making atm, and keep reminding myself that taking the hit now will pay off down the road. Learning Modo - and
pretty much the entire art pipeline - is a pretty big task. Learning UE4 is also going to take a good long while. The fact is, I need these skills if I’m going to continue making games on my own,
so it’s nice when I do finally crack something. Even if it takes all day… :)

So, next up: a quick pass on the texture, then some simple poses for test anims.

Quick aside: I’ve been doing a bit of work on the side project this week - mainly on the train to and from my teaching classes - and I noticed something a bit worrying. For a
while I’ve been wondering why my 2D framework for Neutrino appears to be pixel-fill limited on my laptop. Much more so than I expected. Jumping to 1080p in a window is enough
to really hit the performance, so after integrating ImGUI I dug a little
deeper and added some profilng.

It turns out that the engine isn’t as slow as I thought. Internally it was vsync’d to 60, but unbound could
potentially hit ~1400fps. Visually, however, it was blatantly dropping frames. If anything, it looked sub Dirty Hz (30fps). Not good. So I tried glmark2 and it was showing the same problem,
it’d report fps in the hundreds, but visually appear dog slow.

My laptop runs Ubuntu 16.04, and for the desktop environment I’ve been using the latest version of Cinnamon. I like it, it’s incredibly clean, good looking and does what I need.
The other big plus is Nemo - the file manager - which is by far my favourite thing about it. Default split-pane views ftw! But, for whatever reason, I didn’t consider that my performance problems could
be related to this.

On a whim I tested the game under Unity, and lo. A silky smooth, 60fps.

So yeah, even though Cinnamon claimed that it wasn’t running in SW rendering mode, for whatever reason, the window update wasn’t actually matching what I was outputting. Quite a big “Whoah” moment,
and something I thought was worth sharing. Not all desktop environments are equal, and some aren’t good for games.

Real shame, as I can’t use Cinnamon while it’s exhibiting this kinda problem. Also doesn’t bode well for when I release something, but I’ll cross that bridge when I come to it.