One of the biggest failures of Sprite Lamp (as a project) so far has been the OSX version. From the point of view of anyone who backed the Sprite Lamp project as a Mac user, it is now massively overdue, and all they’ve had to go on has been a crappy beta version that isn’t very stable. The good news is, this is about to be resolved. Since this is a blog about development, I’m going to tell you the story that brought me to the current situation, but if you don’t want to read my long-winded rambling, scroll to the TL;DR at the bottom of this post.

The story so far

When I started working on Sprite Lamp, I wasn’t expecting it to be a big deal at all – it was actually just a personal experiment. At the time I was messing around with C#, so I picked up WinForms as quick way of making a UI, and off I went. This was all well and good, and Sprite Lamp came together for Windows reasonably quickly. I put together what I thought was a minimal OSX version that contained all the basic requirements of Sprite Lamp (open images, process them, render an OpenGL window to preview, save images to disk) to make sure the port was doable, because it would be stupid to promise a cross-platform release in the Kickstarter if I hadn’t done at least that, right? And off we went. The Kickstarter succeeded, far quicker than I had expected it to, and development began. Because it exceeded its goal, it even became possible to contract someone to help with the cross-platform stuff. This was a relief, because in spite of me doing my little proof-of-concept port, I didn’t know my way around OSX all that well. At this point I was pretty confident that, though it might not fit perfectly into my schedule because of stretch goals, things were looking pretty good.

And as far as the Windows release, things were basically okay! It did come in a bit late, but I think mostly people got what they were after. At this point I was working with someone who knew OSX better than I did to make a start on that port as well. It turns out that WinForms and C# is quite well-emulated on Linux, so I was working on that version, but while WinForms can run under Mono on OSX, it’s not pretty – we needed to build a new UI. So, on it goes.

However, it soon becomes apparent that things are kind of heavy-going on the port. Despite the unexpected success of Sprite Lamp, I can’t afford to pay all that much to my contractor, and working with C# and building a new UI is going slower than he thought it would (quite understandable, these things happen). Unfortunately, this is getting drawn out to the point that life is getting in the way – he certainly isn’t able to work on it full time, and while he’s an honourable guy and is going to deliver what he said he’d deliver, it’s not easy while he has to make a living somehow at the same time. It gets more and more difficult to organise meetings and make things happen. He and I are kind of hating things at this point – getting things to happen is pretty painful, and I feel sure he’s (understandably) regretting getting involved in the project. All the while, I’m mindful of the fact that people were promised an OSX port, and it keeps failing to progress.

Eventually, my contractor gets a beta together. It’s not perfect, but it’s something, to my relief. Mid last year, I posted about all the troubles we were having, and that we finally had something to show for it. However, that relief didn’t last – development essentially ground to a halt after this. I was starting to feel like Sprite Lamp was a real lodestone on the life of my poor contractor, but it wasn’t going anywhere. Worse, looking at the beta, it wasn’t clear that getting it cleaned up properly was very easy or doable – the UI system we were using was kind of cumbersome, and neither of us knew it well enough to troubleshoot very reliably. When I was really honest with myself, I had to admit what I was expecting to happen – something ‘finished’ gets cobbled together, it’s not very good, I push it out the door with as little fanfare as possible and consider the campaign fulfilled. This option didn’t make me very happy.

A bit over a year ago, it became necessary to get a real job, to pay the bills – and that job was as a programming lecturer. I was teaching C++ (it’s at a game dev school), and though I had used C++ professionally, my skills had atrophied a bit (all of Sprite Lamp was done in C#, after all). So I set about re-educating myself, to get to the point that I could teach C++ with more confidence. Naturally, I’ve been getting more practice through teaching since then.

Now, way back when Sprite Lamp was first funded, some well-intentioned backer suggested I look into rewriting it in C++, because it would make the port easier. At the time, I’d just gotten done writing the thing in C#, my C++ was pretty rusty, and I thought it wouldn’t be so bad on account of my proof-of-concept demo – so I thanked them for the suggestion, didn’t follow it, and forgot about it. It wasn’t until much later, when I was looking at the state of the OSX port and the lack of process that had been made, that I remembered that suggestion. With all the porting woes we were having, and my improved confidence in C++, suddenly this seemed… kind of sane. Back then, the backer had suggested Qt (which I didn’t know anything about at the time), so I had a quick look into it to see if it could get the job done. While rewriting Sprite Lamp in another language just for OSX seemed kind of crazy, anything that provided a glimmer of hope that I could stop disappointing my Mac backers was well worth looking into, and letting my contractor off the hook was pretty appealing, too (he’s a friend of mine, and I don’t like spreading the stress around so much).

Before long, this was starting to sound suspiciously like the best idea ever (usually things have to be pretty grim for “let’s burn the entire codebase to the ground and start again” to sound like the best idea ever, but still), and I started throwing together some first attempts. Before much longer, I had the Sprite Lamp core (ie the engine for converting the images, just no front end) mostly working in C++. I started to wonder if, instead of making the OSX version in C++, I should maybe just get rid of the C# codebase altogether, and relaunch on all platforms.

And now, present day

The idea that the rewrite might be worthwhile first surfaced something like December last year. I apologise for the lack of communication about that decision at the time – I wasn’t sure if it would actually work out, and I really didn’t want to come back here without some good news. Well, I’m pleased to announce that the freshly rewritten version of Sprite Lamp is available on a Steam beta branch right now. I’m not going to just push it to the main branch yet – I’m not that crazy, and obviously it’s less thoroughly tested so I want people to be able to revert to the old (Windows) version if they want. If you want to try it out, the beta password is ‘NoLongerSecretPassword’. There’s a new Windows version there, as well as the OSX version. Please give it a try – the Windows build is much nicer than the old WinForms one, and there are new features too (more on that below), also present in the OSX version.

And if anyone’s wondering, yes, I feel like an idiot for not doing this a long time ago. To that backer who suggested C++ and Qt long ago, it’s very clear now that you were right.

A couple of caveats

Hopefully this fancy new version won’t set anyone’s computer on fire – it has, at least, been pretty stable for my tests. However, there is one persistent and pesky problem with Steam failing to recognise the pro version on OSX (Windows it recognises it fine), and I am still figuring out the best way to bundle the separate command line interface executable into the OSX build. I’ll be getting all the versions up on Humble over the next little while, so if you must have the pro features on OSX, keep an eye on my twitter account. Hopefully that will all be sorted soon, but it didn’t seem worth delaying this announcement for (most people own the hobbyist version, and lots of pro users mostly use the hobbyist features anyway).

How about Linux?

Linux isn’t part of this release, but it will definitely be getting the Qt treatment. A terrible fate befell my Linux box recently, and I haven’t had the time to get it back up and running yet, but before that happened I did confirm that the Qt build worked smoothly. That’s what I’ll be working on next, and I’m expecting (touch wood) that it won’t take all that long.

New Features

Funny thing about rebuilding something from the ground up, is remembering all the design decisions you made the first time around and why, in light of having actually used the thing since then. That hindsight, coupled with Qt being better at certain things, coupled with me being a better programmer now than I was then, have led to a few cool new things. Nothing that’s likely to set the world on fire, but I thought I might as well run through them here:

• You can adjust the colour and the intensity of the light sources separately – so to make the light brighter, you no longer have to go into a colour chooser and increase the brightness without touching the hue and saturation. You can also make lights more intense than was previously possible with this feature.
• You can switch between a point light and a directional light in the preview window. Using a directional light means that light renders for tiling textures will, themselves, tile – so you can make use of baked lighting for tile-based games, now.
• You can adjust the specular intensity in the preview window.
• Inspecting images scales them up without blurring (filtering) them, so you can view a preview of your pixel art normal map more nicely than before.
• For rendering lighting, you can export an animated gif or a static image, and choose whether to export at preview window resolution or at the assets’ native resolution, separately. Mostly, this means you can export animated gifs with the input images’ resolution and framing, which a few people requested.
• You can drag and drop images directly into the Sprite Lamp interface to load them. Dropping onto one of the individual image boxes will load the image into that slot, while dropping them anywhere else in the interface will load the set that image is a part of. This feature has had a pretty big impact on my Sprite Lamp usage – it makes things a lot smoother.
• You can choose to apply bilinear filtering to the textures (for the preview window).
• Everything has tooltips now.
• For the pro version, there is a new CLI parameters helper feature, which automatically puts together the command line arguments you’ll need to process an image with the settings you’ve currently got selected.
• Everything just looks nicer and a bit more modern and polished, in my perhaps biased opinion. I suspect the UI is a little more responsive, too.

Mopping things up

This blog post amounts to me putting this beta out on Steam (by releasing the password publicly), but there’s more to do.

• I have to get the new free/demo versions out and available on Steam and on this website.
• I have to send the non-Steam builds to Humble.
• I have to see what problems come up with the beta test, and hopefully address them.
• I have to sort out those last few problems mentioned above – detecting the pro version on OSX, and getting the CLI working properly.
• I have to get the Linux version done.
• I have to finalise the launch, and make everything officially for sale on all platforms.

I’m still only working on all this during weekends, but I’m hoping I can get this done over the next month or so. I won’t necessarily post here every time one of these things gets done, but I’ll be uncharacteristically active on Twitter and Facebook to keep people informed.

I’m also hoping to spend a bit more time writing posts here about technical issues such as how normal maps work, what anisotropy means, usage of the depth editor, and so on, in the future.

So, if you’re a Sprite Lamp user, please give this a shot and let me know what you think. Even if your experience is ‘it works fine’ I’d like to hear about it, because otherwise it’s hard to tell the difference between “everything is flawless” and “nobody is using it”.

TL;DR: Sprite Lamp has been completely rewritten in C++, meaning a few new features and a working OSX build. No Pro features on the OSX build just yet, nor Linux support, but they’ll come soon. Get them on the Steam beta branch right now and let me know how it goes – password is “NoLongerSecretPassword”.

 

So, finally proper update today, and a new release of the Sprite Lamp Unity shaders to try out. Apologies to all for the time this took (and to anyone wondering, Snake Hill is just about ready for the fire season).  You can get the new shaders at the Sprite Lamp engine page as usual. Here I’m going to write a few things about Sprite Lamp and Unity that might be relevant to you. I’m going to make a quick disclaimer here now though: I’ve been tinkering with Unity for a little while, but I’m not expert – if you read something here and think you know better, you may well be right, and please let me know!

Normal maps in Unity without special shaders

I think with all my talk of Sprite Lamp/Unity shaders, some non-technical (or just non-graphics-savvy) readers might have gotten the impression that you have to use my official Sprite Lamp shaders to use Sprite Lamp with Unity. This is not the case! Sorry if I communicated that poorly. Sprite Lamp creates normal maps, and pretty much any modern 3D game engine that supports dynamic lighting, including Unity, can work with normal maps. As far as the engine doing the rendering is concerned, applying a normal/bump shader to a sprite is no different to applying a normal/bump shader to a mesh. The key thing with Sprite Lamp is allowing normal maps to be created without 3D modelling, and in a fashion that maximally preserves the artist’s style – but at the end of the day, they’re still normal maps and can be used like normal maps! There are some special fancy shader effects that work well in conjunction with this technique – stuff like self-shadowing based on a height map – and I’m writing my official Unity Sprite Lamp shaders to support those effects. But, I’d say most people working with Sprite Lamp would get most of what they want with Unity’s built in shaders.

That all being said, this is simple enough to do. First thing you’ll need is a diffuse map and a normal map (which I’ll presume is made in Sprite Lamp, but need not be). Import both these images into Unity in the usual way, with the diffuse map set as the Sprite type, and the normal map set as the Normal type. It’s important at this point to uncheck the ‘Create from Grayscale’ checkbox on the normal map’s import settings, or else it will look (and be) incorrect.

From there, make a new material and set the shader as one of Unity’s built in shaders with ‘bump’ in the name, such as ‘Bumped Diffuse’. You can now drag your textures into the appropriate slots, and drag the material onto your game object. This can be a sprite you created, or a quad (or a mesh of some other shape).

The advantages of using Unity’s built in shaders are mostly that, now and in the foreseeable future, the people that built Unity understand Unity better than I do. 🙂 They’re likely to have more complete support across all of Unity’s different iterations, different platforms, rendering backends, etc. and, if nothing else, can hopefully provide a fallback if my shaders aren’t perfect. The good people at Unity are likely better optimisers than me, too, especially for mobile platforms where it counts.

The official Sprite Lamp Unity shaders

There’s a detailed writeup of how to make use of the official shaders over at the engine integration page so I’m not going to reproduce that all here. What I will do, is describe what’s changed in this new update – in dot point form.

• Spine – My first attempt at a Spine shader is now included.
• Attenuation that works properly – To my mind, this was the biggest problem with the old shaders – they weren’t terribly usable when you couldn’t reliably avoid nasty hard edges from the lights going out of range. It should be sorted now. You still have some ability to tweak attenuation of lights on a per-material basis (which I still wish I could make a property of lights).
• Spotlight circles need no longer be hard-edged (how soft they are is also adjustable in the material properties).
• Optimisations – I’ve revamped how a few things work, and that should make things faster (fewer branches due to multicompile between different light types is the main thing).
• There are a few platforms that this didn’t compile on before that it now compiles on. If it still doesn’t compile for you, let me know (these things can be hard to track down).

I’ll also add that I’ve decided to keep the ‘several shaders with different features turned on and off’ approach, rather than attempting multicompile stuff, because as far as I can tell this would cause a mild combinatorial nightmare because it is also compiled five times for the different light sources.

Somewhat experimental Spine stuff

I’ve gotten some lit Spine stuff working at my end. I’m not sure that this is the best way to go about things, because I’m even less experienced with Spine and Unity together than I am with Unity on its own, but hopefully it will be of use to some people. It makes use of a fragment shader that calculates the normal/binormal/tangent matrix on the fly, so it can deal with deforming meshes without requiring a bunch of extra code on the CPU side to calculate tangents dynamically as they deform – not sure if that’s the best tradeoff (my guess is that it depends on the platform).

For this reason, it should be reasonably simple to set up, with one exception that I’ll get to in a minute.  Start by setting up a Spine character (or whatever) in Unity the way you usually would – I won’t go over this here because there are better tutorials to be had by googling. When things are working as they should be (but without lighting), there’s one tricky thing to do (and thanks to ashwin911 from the forums here for putting me on the right track with this), which is setting your Spine object to have some Z spacing.  This is because multipass lighting in Unity  depends on the depth buffer, so we’ve got to give it different depth values. There’s a value called zSpacing that you need to set to some small negative value (ashwin911 suggested -0.001, which is what I’ve gone with in my example). The trick is, this value is hidden for some reason, so you need access to hidden variables. You can do this by going up to the “inspector” tab, right clicking, and selecting “debug”. Under the “Skeleton Animation” component, there should be the ‘ZSpacing’ value available to change.

Once you’ve set that to -0.001, you can create a material using the Sprite Lamp Spine shader, and assign your textures to it as usual. From here, assigning your material to your Spine character should be all that’s left!

The new attenuation stuff

I’ll just mention very quickly how I’ve set up attenuation. Basically, it works by calculating a linear drop off in intensity, that goes from one at the origin of the light, to zero at the max range of the light. It then raises this value to a power – you have control over that power, in the ‘attenuation exponent’ shader variable. If you increase this variable, the dropoff will happen suddenly, quite close to the light, then go to zero very gradually. If you lower it, it will drop off gradually at first then suddenly near the end. Lowering it all the way to zero will give you a bright sphere that drops to zero immediately at the maximum range.

Similarly, there’s a variable called ‘spotlight hardness’, that affects how hard-edged the circle of a spotlight will be. This is pretty self-explanatory – setting it to maximum will make the spotlight a hard-edged circle like it was in the older shader, and setting it lower will make it very soft-edged. Unfortunately, both these variables are attached to the material, not the light source (I’m not sure if it’s possible in Unity to attach variables to the light source).

This is a pretty boring post, but I didn’t want to go silent for too long. I just wanted to let people know that work continues on Unity shaders and the Mac port. Things have been slow lately, partly because there is a rather full on week of conferences for game developers in Melbourne (GCAP and PAX Aus happen within two days of each other), and partly because of random personal stuff (mum’s recovering from knee surgery and we’re approaching fire season so there’s been a bunch of stuff that needs doing), and then to put a final annoying conclusion on the whole thing, my computer crapped out yesterday and (seemingly) has to be replaced. Stuff is backed up so no worries on that front, it’s all just inconveniences. Sorry for the somewhat whiny and very unexciting post, but as I say, I figured I should say something so people don’t think I’ve died or abandoned Sprite Lamp. I realise there are folks out there hanging out for updates, particularly Unity-related stuff, and I’m sorry for the time it’s taking getting things done. At least the next couple of weeks will probably be an improvement.

Hi all,

I’m coming at you a bit humbly today, because a comment someone made to me recently called me on being behind in my schedule and generally not telling people what’s up.

I’ll start by saying that this isn’t the dreaded “Sorry, this project isn’t going to happen” post. Sprite Lamp has been and continues to be in development, and all the promised features are on their way.

What this post is, is me apologising for being less productive than I would have liked over the last two months, and not being very communicative about that fact over that time. I have been in the US recently – for personal reasons I won’t go into, it would have been awkward for me to not go on the trip, so I convinced myself that I could just take my laptop and keep up work on Sprite Lamp while I was there. As it turns out, this was kind of foolish on my part, and in retrospect I should have just stayed home. I did keep working while I was there, but productivity has been lower than I hoped, and I haven’t been very good at keeping you all up to date on this. The current state of play is that I’m working on a few things for the next alpha release – UI overhaul, functional/usable palette system, updating some issues with engine shaders, and updated documntation are all coming.

The other thing I haven’t communicated about well is release dates. Initially, I stated that Sprite Lamp would be out approximately now. This was when the Kickstarter was initially written, and it was a small project without any stretch goals. It’s grown beyond that, and of course the stretch goals were things that I hadn’t done any development on, some of which have turned out to be slightly rabbit-hole-ish. At this point I’m hoping for one last alpha release in a week or so, and the first beta release in about a month.

So having said all that, I’m now back home and in a much better state to work in an undistracted fashion. I’ve always been a bit shy about social media and the like, but I’m going to put in an extra effort to be forthcoming on that front, too. For now, I figure the best way to make amends is to get right back into coding, so that’s what I’m going to do.

~ Finn

So I sent out a survey to the early Sprite Lamp backers, asking about what kinds of features they’d find useful, and got a pretty extensive and pretty quick response. So without further ado, I present to you Sprite Lamp’s stretch goals.

There are more details available on the Kickstarter page itself – scroll all the way to the bottom (almost). These stretch goals are bigger than the original goal by such a margin because they represent new features that I have to build from the ground up, now – the original goal represented remaining costs of a significantly pre-developed project.

Other things I learnt are that Sprite Lamp backers are pretty tech-savvy, with 24% saying they’re completely confident they can make their own shaders, and only 5% saying they have no chance of doing so. 24% are rolling their own game engine, and an impressive 70% knew what I was talking about in the question about anisotropy maps. I also learnt that almost half of the backers were planning on using Unity in conjunction with Sprite Lamp, which isn’t all that surprising, that TextureMapper is an overwhelmingly popular atlas tool, and that Spine appears to be the 2D skelmesh software of choice. Finally, I learnt that pretty much everyone is at least intrigued in trying out the palettisation tech that I have in mind.

Thanks to everyone who helped me out by responding to the survey!