Sprite Lamp, take two

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”.

 

Sprite Lamp, OSX, Linux, and the Humble Bundle

So, two things happened yesterday. First off, Sprite Lamp is a part of the Humble Bundle. Exciting! I imagine, though, that if you’re reading this you already own Sprite Lamp and don’t care much, or just bought it and already know.

The other thing that’s new is that it’s time for (the alpha versions of) the OSX and Linux ports to be released into the wild! These aren’t really ready enough for me to call them ‘released’, so they’re not officially on sale on Steam. If you own Sprite Lamp on Steam, though, you can get the OSX and Linux builds by activating the beta – do this in the ‘betas’ tab of Sprite Lamp’s properties in Steam. The password is ‘CrossPlatformAlpha’. I don’t have a huge range of computers to test this on, though, so if anyone has trouble getting this to work please let me know via my contact form. The cross platform alpha builds are available on Humble, too.

For those wondering what Sprite Lamp is

I have bought Humble Bundles in the past without knowing what all the things in the bundle are. Perhaps that’s what you did, and you found your way here, wondering what Sprite Lamp is? The short answer is, it’s for making normal maps. The slightly longer answer is, it’s a program for processing hand-drawn art into normal maps (and a few other things, such as depth maps), which allows you to do dynamic lighting on ordinarily ‘static’ art styles, such as painted images or pixel art. For a substantially more detailed description, check out the Sprite Lamp page. If you’re wondering about whether you can use Sprite Lamp’s normal maps with a game engine you’re using, the answer is likely ‘yes’ – most game engines that have dynamic lighting nowadays support normal mapping (sometimes known as ‘bump mapping’). For Unity and Game Maker, I’ve also made some headway in writing my own shaders to replicate the lighting in the Sprite Lamp preview window – check out the page on using Sprite Lamp with these engines for more info.

Status of the ports

So, now that Sprite Lamp is on Linux and OSX, it’s worth saying exactly what I mean by ‘alpha’.

The OSX version has been by far the most work, because it’s involved rebuilding the front end with a new system. This unfortunately also means it’s the more alpha-ish of the two. Most of the unimplemented features are from the Pro version, and for that reason I’ve chosen not to make the pro build available yet (I just don’t want anyone paying for it because they will be disappointed with how few of the features are actually there). The Hobbyist version has some rough alpha-ish edges, but should still be useful, and most of the features are in place. Please let me know if you come across problems.

The Linux build is a more direct port (for not-very-interesting reasons involving WinForms support). This means that it doesn’t look as nicely natively Linux, but it’s much more complete – basically everything should work, with the exception of the command line interface which I’m still figuring out, and probably a few other bits and pieces that didn’t make the transition neatly for whatever reason. If you find anything that doesn’t seem right, again, please get in touch.

Getting in contact

In case I didn’t link it enough times in this post, you can contact me via this contact form. I’m a bit crap at social media and forums (sorry), and I don’t use twitter all that often. I’m trying to get more attentive at these things, but the most reliable means of contact is still that contact form – it goes straight to my email and I’m at least reasonably good about responding to those.

Multiple sprite sheets, Sprite Lamp, and Unity

So I mentioned yesterday that I’ve been working on a small tech demo in Unity, to help make sure I notice all the difficulties that can come up with Sprite Lamp, and the first one that has presented itself is the issue of animating with multiple (sets of) sprite sheets. A few people asked me about this already but I didn’t quite have my head in the game enough to give good answers. Hopefully now that I’ve played with it a bit more directly, I can do better.

Here’s the script referenced in this post.

Oh and before I go on, a quick annoying reminder that Sprite Lamp is at 30% off on Steam as I write this!

Animations with a single sprite sheet

The simple situation for frame animation in Unity is one big sprite sheet. This is, I suspect, reasonably common – especially with people working with pixel art, and textures going up to 4096×4096. Someone in this situation who wants to use Sprite Lamp is in a pretty easy situation in terms of programming – essentially, everything just works easily. You’ll want to make a sprite sheet of the diffuse channel, cut it up with Unity’s sprite editor, create animations, and apply them to a game object with an animation controller. So far, everything is normal. Then, you’ll want to create a corresponding normal map sprite sheet with Sprite Lamp (either using whatever texture packer tool you want, though be wary of rotating normal maps, or by drawing the lighting profiles in sprite sheet positions then processing them all at once). You don’t need to cut this up into sprites in Unity after you’ve imported it. Then, apply a Sprite Lamp (or other) material to your game object, drag the normal map sprite sheet into the NormalDepth slot, and everything should be fine.

The reason this works smoothly is because if you have one big sprite sheet, all the animation system is changing is the UVs on the sprite, and because the Sprite Lamp shader doesn’t do anything fancy with UVs, it’ll just look up into each sheet in the same spot.

Multiple sprite sheets

This is where things get tricky. The issue is that Unity’s animation controller automatically switches textures as necessary, but it only provides for switching the main texture, because usually you only have one texture when you’re doing this kind of animation. By way of example, say you have a character who can walk or run. If you’re making a normal 2D game without lighting, you might have two textures: WalkSheet, and RunSheet. Ordinarily, when your character is walking around, Unity will be switching between sprites in one sheet, and thus changing the UVs – but when your character switches to running, Unity has to switch to the RunSheet texture, which it does automatically.

Suppose instead though, you are using Sprite Lamp, so you have six textures. WalkSheet, WalkSheet_Normal, WalkSheet_Emissive, RunSheet, RunSheet_Normal, and RunSheet_Emissive. Your character starts walking around fine, with WalkSheet, WalkSheet_Normal, and WalkSheet_Emissive applied – all is well. Then they break into a run though, and we’re screwed. The animation system switches the diffuse texture to RunSheet, but the normal and emissive channels keep the Walk versions. This will look somewhere between pretty broken and horribly broken, depending on whether or not the walk and run sheets have similar layouts.

How to get around this? Well, essentially, I’ve written this script. It’s still not tested all that much, so I haven’t added it to the official Unity pack yet, but it has worked in my use case and will hopefully work in yours (if not, let me know). The script works by creating a dictionary at load time, which uses a texture as its key, to look up the corresponding textures. Then in the update, it will check the object it’s attached to to see if the texture it’s using has changed – if it has, it automatically sets all the other textures.

To use it, the first thing to do is attach it to your character (or whatever). Second, you have to populate some lists – this is currently done manually, but I’m looking into nicer ways to handle this.  The lists are ‘primaryTextures’ and ‘otherTextures’. Into ‘primaryTextures’, drag all the sprite sheets that your AnimationController knows about – so in our above example, that would be WalkSheet and RunSheet. In the ‘otherTextures’ list, you’ll want to drag all the auxiliary stuff Sprite Lamp uses – here, that would be ‘WalkSheet_Normal’, ‘WalkSheet_Emissive’, ‘RunSheet_Normal’, and ‘RunSheet_Emissive’. For each element of ‘primaryTextures’, the script will search for any textures in ‘otherTextures’ that are suitably named, and associate them so that they get set at runtime.

That should be just about it! As always with Unity things, if I’ve missed some obvious smarter way to do this, please let me know. Also, I’ll be along soon with a more concrete example of this method that you can download, in case my description here doesn’t make things clear.

Coming up next…

The other problem I rapidly ran into here is the problem of ‘light sources’ that exist in the emissive texture map. They tend to move around within the sprite, and you’ll likely want an actual light source to move with it, but the engine doesn’t know how to move it appropriately. I’m working on a script that will automatically parse an emissive map and approximate clusters of bright pixels by creating a light of the appropriate intensity/colour/position. It’s at proof-of-concept-ish stage now and isn’t ready to distribute just yet, but so far it looks pretty cool, particularly by matching the light’s movement to the animation’s framerate.

Sprite Lamp sale, and the eating of dogfood

Hi folks!

First thing’s first, Sprite Lamp is on sale on Steam this week, for thirty percent off.  A couple of people asked me when that was going to happen, so here we go. I turned thirty a couple of days ago so I thought that was as good an excuse as any. I’ll note that this sale includes the upgrade from the hobbyist version to the pro version. So yeah, here are the links to the Steam pages if you want to get in on that.


Mac holdup

I’m not enjoying giving bad news for the mac port, but unfortunately there has been a hold up – we’ve recently been having a pretty major show-stopping bug with some not-yet-understood combination of mono, graphics drivers, and OSX versions. Rob has more resources than I do for this, and he’s currently messing about rolling things back to get it to the point it’s usable. Once we get it to some working state, the plan is to release an alpha to kickstarter backers, to get a feel for reliability, and hopefully that will give us the data we need to move on to a proper release.

Linux alpha incoming

Progress is much more forthcoming on the Linux build, fortunately, and I’m hoping to get an alpha to backers soon. I’m still struggling with the Steam libraries on Linux, but other than that things seem to be coming together pretty okay.

Eating our own dogfood

Developers might recognise this rather gross-sounding phrase. ‘Eating your own dogfood‘ refers to the practice of using your own products internally. Technically, I think this would mean Snake Hill Games was making a new game, and it was using Sprite Lamp, but this isn’t the case (yet). Rather, I’ve noticed that too often, I don’t have a great answer to questions people ask about using Sprite Lamp with Unity, because while I have developed the shaders and put them in a toy environment, I haven’t actually used them for real. Unity is big and complex, and try as I might, I frequently overlook application details that are tripping people up. In an attempt to head that off at the pass, Halley and I have decided to make a small tech demo using Sprite Lamp and Unity. Hopefully the following things will result:

  • I’ll encounter problems with using Sprite Lamp and Unity, and fix them.
  • I’ll encounter workflow issues with Sprite Lamp now that we’re using it for real, and fix them.
  • Halley will create a bunch of art, and write some blog posts on workflow and artistic best practices, that will perhaps be of some use to people.
  • We’ll perhaps end up with some generic assets that people might find use of in their games.
  • We’ll be able to give more concrete answers to questions like “How long will it take to make assets for use with Sprite Lamp?”, as well as point people to a live example of what games that use Sprite Lamp can look like.

This won’t take a great deal of my time (it will be more artwork than codework) but it has already borne some fruit. Tomorrow, I’ll be posting an update about using multiple sprite sheets with Unity’s animation system, and adding a script to the official Unity integration package that automates the process of switching out different sprite sheets.

Anyway, I’m not going to say much about this little tech demo just yet – it’s in very early stages, and there’s nothing really worth showing off yet – but I’ll post a bit more about it soon.

Scattershot update

Quite a few things to put out there today.

Mac and Linux progress

This has been my main focus recently, and though I’m aware that this part of the project is well overdue (more on that in the ‘lessons learned’ section later on), we’re down to the last handful of bugs before the alpha releases on MacOS. Rob reports that he’s been having more trouble than expected with various parts of the project – it was a bit of an unknown working with C# and MacOS in the first place, but there have been more unknown unknowns than either of us saw coming. At this point it’s essentially all UI fixes, but unfortunately they’re not the kind of thing that can be handwaved, even for an alpha. It’s been frustrating at our end, since Halley is a Mac user and has been keen on getting this version sorted for a long time, but the end is very much in sight. I apologise for how long this is taking, though – I don’t mean to gloss over the fact that it’s much longer than expected.

As for Linux, because the MacOS version is mostly in Rob’s hands now, I’ve been looking at the Linux build. This isn’t as big a deal as the Mac version (in terms of work, I mean) because it doesn’t involve an entire UI rewrite, but there are lots of problems that have previously been in the too-hard basket because previous releases haven’t been in any way final, which I’m now having to face head on. A big part of all this is packaging and general unfamiliarity with deployment conventions at this point.

A few engine things

Unreal 4

This is an odd one. Lots of people have been asking me about integration between Sprite Lamp and Unreal 4. I feel a little bit like the winds of change are blowing in the indie gaming word – it seems like everywhere I turn, people are talking about their new project using Unreal 4, or the various advantages the engine offers. I don’t know whether Unreal 4 is going to replace Unity in the near future, but it was enough to convince me that it’d be irresponsible to not look into Sprite Lamp and Unreal 4 playing together.

I’ve spent some time recently learning the engine a bit, and… well, beyond normal maps, it’s not clear there’s much I can do with Unreal 4. As usual, it’s a modern engine and can therefore handle dynamic lighting and normal maps just fine. However, because it uses deferred rendering in a very fundamental way, it’s no longer possible to just write your own custom lighting model with Unreal 4 as far as I can see (and the fancier features of Sprite Lamp’s shaders fall into that category). I’ll add two caveats to that – first is, obviously people are capable of achieving amazing things with Unreal 4’s lighting, and that includes nonphotorealistic results, so very likely things like cel shading are still possible. It just means that I won’t be writing the exact shader from the preview window of Sprite Lamp into Unreal 4, because that appears to not be possible. The other thing is that since Unreal 4 has its full source code available, technically it’s not really true to say that anything can’t be done – almost anything is possible. However, I think that trying to maintain a source-modified version of the engine (that would survive integration when Epic updates and so on) is probably more trouble than it’s worth for everyone involved.

Godot

Another engine that seems to be picking up steam a bit is Godot. Since it’s completely free and open source, Godot’s appeal isn’t hard to understand. I don’t know a great deal about it yet, but I’ve been following along and it seems that 2D lighting is a priority for them in the near future, which is obviously very relevant to my interests, and perhaps yours. That said, unlike Unreal, I haven’t particularly gotten the impression that lots of people using Godot are also using Sprite Lamp – if you’re a Godot fan and would like me to look closer at its use with Sprite Lamp, let me know.

Real life issues

As you’re probably aware, Sprite Lamp has been out on Steam and Humble for a couple of months now, and though it’s doing okay for itself, taken in combination with the above issues about the Mac port taking way longer than expected, it would be financially risky for me to just assume that I can live indefinitely on Sprite Lamp. This has necessitating me getting myself a ‘real job’. It’s a job that doesn’t consume all my time, and don’t plan on completely returning to the normal full time employment world for a little while yet (not while Sprite Lamp is ongoing, certainly).

Lessons learned

One day, I’ll do a proper Sprite Lamp post-mortem, but there are two important things I’d like to put out there in case anyone might learn from them.

First off, it’s clear to me now that the biggest technical misjudgement on my part for this project was underestimating the difficulty of working with unfamiliar platforms. I’ve only ever been a Windows developer, so (I thought) I had a suitably healthy fear for working with other platforms – that’s why I went and made proof-of-concept stuff for MacOS and Linux before promising those versions on the Kickstarter campaign. Still, I was unprepared for how much work gets bogged down (for me, at least) by not knowing the operating system. As a simple example, I recently spent an embarrassingly long time tracking down some issue with apt-get on my Linux install that was stopping me from progressing, which ultimately culminated in having to install a newer version of Linux (which, to its credit, went very smoothly). That stuff adds up, and it’s not psychologically great when it feels like you spend as much time fighting with problems of unfamiliarity as you do writing code. I’m hoping future projects of mine can be cross platform, but I’m definitely going to be less gung-ho in my assumptions. Certainly I cringe internally to recall my intention to do a simultaneous cross-platform release.

Second off, and a little personally, I didn’t foresee how much being a (very very mildly) public figure would be a source of stress, and how crap I would be at maintaining stuff like this blog, a social media presence, etc. I’m actually not a terribly shy person in real life (although admittedly with game development to some extent you’re grading against a curve there), but apparently I am in the internet world, which seems to be the reverse of how most people feel. This mostly makes me respect community managers a lot more, but also gives me some reason to pause in the goal of being an indie developer, since it kind of comes with the territory. Not sure how I’ll feel about that going forward, but if anyone has actually read this far and has any advice on the same kind of thing, please let me know.

 

Anyway, that’s it for now, and I’m back to figuring out Linuxy things. To anyone who read this far, I hope you celebrated whatever they’re inclined to to the best of their ability, and that 2015 is as good or better than 2014.

Sprite Lamp and Unity

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).

Recent issues

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.

Unity shader update/info (minor)

This isn’t quite the update I wanted to make, but it’s something. I’ve just uploaded a new example project and Unity package stuff to the engine integration page.

Working with Unity’s shader system has been a big learning experience, and I’m slowly coming to understand how it all works (and how my initial attempts have failed to do things The Unity Way, as it were). I’m in the process of reworking the shaders to make use of the (startlingly deep) Unity shader macros, and when that’s done I’ll post another update, and it will cause attenuation and light cookies to all work in the nice simple way you’d expect Unity stuff to work. In the meantime, this smaller release fixes the problem a few people have reported involving weird specular lighting appearing where the alpha channel is set to zero and should thus not be visible (this turned out to be a schrödinbug relating to multipass lighting and blend modes), and adds the experimental new implementation of per texel lighting (both the palette and regular shaders have new versions with this feature).

I should also mention something that came up on the forums, which is an unfortunate development regarding performance of Unity on mobile platforms. It seems that Unity2D relies heavily on dynamic batching to keep its performance up to acceptable levels on mobile. However, dynamic batching gets broken by multipass lighting, which is how Unity handles all per-pixel lighting as far as I can see, and so this is causing some performance issues. I currently don’t have a good solution to this – for a while it looked like this would be solvable with a hackish application of Unity’s per-vertex lights, and making use of them in a special fragment shader, but I’m not really comfortable claiming an official solution to a problem that involves such unofficial methods (and I definitely shouldn’t promise they’re going to work on all present and future platforms Unity supports!). One possible solution is static batching, but that’s a Unity Pro feature. Another possible solution is a script that automatically groups tiles together into bigger tiles, which is essentially a custom static batching solution – I’d happily write such a script and distribute it if it would help people out. I’ll keep looking for solutions. In the meantime, you need not buy Sprite Lamp to test such performance issues on your game/hardware – any normal map will do the job.

Steam release, new website, and forums

So! The big news, I suppose, is that Sprite Lamp is out there! In the wild. What’s unusual is how late I am to post about this, but main point is, Sprite Lamp for Windows is on Steam right at this very moment.

The reason I haven’t posted about this yet, despite the Steam release being last Thursday, is that I was hoping to get Sprite Lamp out in its DRM-free form at the same time. I’ll be doing this via the Humble Widget, and I suspect rather strongly that a lot of people would rather own a tool like Sprite Lamp in a more traditional way, rather than having to boot up Steam in order to use it. For that reason, I’ve been holding off on talking much about the release. In other words, I don’t consider it really released until the DRM-free version is out there. The issue is that because I want it to be possible to upgrade from the Hobbyist to the Pro versions of Sprite Lamp, the good people at Humble tell me it takes a bit longer to set up the widget, and that I’ll have it early this week. Big announcement when that happens, of course.

Regarding the new website, this is for a couple of reasons. The old website made use of wordpress.com, largely because I set it up way back before I knew where Snake Hill Games was going, and wanted something easy to deal with. Gradually, there have been more and more things that I wanted to be able to do that I couldn’t via wordpress.com, but it has come to a head by learning that I couldn’t use iframes and thus couldn’t embed the Humble Widget. This isn’t the first thing I’ve been wanting but unable to do with the website, but it’s the first that is an unambiguous show-stopper, so the switch had to be made.

This has a few benefits. For instance, Snake Hill Games now has a forum! This has been a long time coming (shout out to my friends at Graphite Lab who helped me out with some initial forum attempts earlier – it was only because of my foot-dragging that that didn’t happen), but you can now come to the forums (link near the top of the sidebar on the left) and say hello. I’m not overly familiar with the running of forums, and I’m not expecting them to explode into a huge bustling community or anything, but if you have problems or suggestions or want to show off your artwork, head on over – I apologise in advance if I screw up the administrative side of things.