PS4 v1.02 Save Games

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.

Lumo Build Updates

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. :(

Devupdate - 4th November

How I miss this...

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.

First bit of fan art

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.

Famitsu

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.

Finland

Even the Finnish press have got in on the action!

Box

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.

Devupdate - 13th October

UV Islands

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.

After I’ve recovered from a week in the UK! :D

This is scary...

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.