Category Archives: Sprite Lamp

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.

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.

Sprite Lamp for Windows launching really soon

Hi folks!

So I guess I’ve kind of given away the main bit of this in the title. There’s a bit of a story behind it, but the TL;DR is that Sprite Lamp for Windows will be launching on Steam on the 25th of this month! Yes, that’s in a few days – this Thursday in fact. I’ve got an application pending for a Humble Widget too, so while I can’t 100% confirm it, I’m hoping that it will be available via Humble Widget (at www.spritelamp.com) on the same day, or at least soon after.

There’s a bit of a story leading up to this which I’m going to tell now – not because it’s particularly interesting, but just for the benefit of people who like to stay informed about adventures in development.

Recent events

My initial plan was to launch a bit earlier, on the sixteenth. I just had a couple of things to do, and one of them was to ask the fine folks at Valve how to tag it as ‘early access’. This would have been on something like the ninth of this month. What I learned when they replied is that Steam’s Early Access feature is for games, not software in general, and as such Sprite Lamp can’t make use of it. Sprite Lamp is in a pretty good state now I think, but there were definitely some bugs still there and I was also hoping for some wider feedback on the UI and general usability issues, so this was bit of a rude shock (NB This was my fault, not Valve’s). I briefly considered delaying, but on further reflection I concluded that:

  1. The serious bugs that remained were probably fixable in a week or so of furious coding.
  2. Though the software will continue to improve in the future, it’s at a point now that people will find it useful for their development, and by delaying it I’d just be keeping it out of people’s hands unnecessarily.
  3. I’m inclined to be pretty nervous about launching products and that’s probably making me cringe away from this situation a bit, but I should correct for that personal bias of mine and just get on with it.

So, steeling myself to a week of reasonably full-on bug fixing and polishing, I got into it! At least, I wish that’s what had happened. What actually happened was that my computer died. Totally random, by all appearances, but not ideal timing. No data loss, but certain set things back a bit. I was back up and running in a few days, delayed the launch by a small amount, and got to work. Fortunately, I was right about being able to get through the bugs on my list in a few days, and that brings us to where we are now. Despite a slightly hair-raising last couple of weeks, Sprite Lamp on Windows/Steam is ready to go!

MacOS and Linux versions

So, I mentioned in my last post that I was going to stagger the launch, because it’s a small team and I’m not familiar enough with MacOS and Linux development, and in general, it’s scary enough launching a product on Steam without throwing in multiple OSes at the same time. However, I’m pleased to announce that the MacOS build is making really good progress. I’ve had my head in Steam stuff for a little while now, but the MacOS port has made enough progress in my absence that it’s time for me to get back into that side of things (that is, it’s reached a point where my knowledge of Sprite Lamp’s codebase will speed things up greatly). Though I’m reluctant to make solid announcements, I’m pretty confident that we’ll have at least something beta-ish in a few weeks, and I’m hoping for the proper launch within a month of the Windows launch.

The Linux build of Sprite Lamp has historically been way ahead of the MacOS build, but I’m afraid that will change at this point. However, it’s definitely going to be following the MacOS build pretty shortly.

Depth editing and imminent update

Hi folks. Just another Sprite Lamp progress report. Before I go into that, I want to give a shout out to two projects that are on Kickstarter right now that are making use of Sprite Lamp. First off, Hive Jump – a 2D shooter with local co-op, and with plenty of dynamic lighting to show off. Secondly, Elysian Shadows, an RPG with some next-gen lighting techniques – they’re not as far along with their Sprite Lamp usage but I’ve been in touch with them about it and they’ve got some sweet stuff planned. Both projects seem to be kicking some arse already funding-wise but you should still go and check them out.

Next Sprite Lamp release

So, I said in my last update that it would be the last time I do an update via the moderately dodgy dropbox link method, as I’d be moving to Steam. I was hoping to make good on that plan, but getting up on Steam is taking me a little longer than expected, and I’m currently sitting on some features that I want to put into backers’ hands sooner rather than later. As such, there’s going to be one last pre-Steam release, and it will be some time over the next few days. This also means one more release with a dodgy not-so-useful Mac version, unfortunately, but see below for some more encouraging news on that front. I’ve been hard at it on the features though, so this next update should be a good one. For everyone, it will contain the Spine integration that I mentioned a couple of posts ago, which is already pretty cool. For pro users, it will also contain the long-promised depth editing system, which I’m about to talk about. There are also a couple of other small improvements and tweaks to things I noticed needed fixing along the way.

Depth editing tools

As mentioned, this is a pro-only feature. Just wanted to get that in early to avoid any disappointment. One of the major things I’ve been working on is a system for editing and fine-tuning depth maps after Sprite Lamp has created them. As you might know, Sprite Lamp is primarily for creating normal maps, but can also create depth maps from them. However, there isn’t enough information in a normal map to create perfectly accurate depth maps, and in some cases the results could use some tweaking (particularly for elaborate character art or other complex objects). Drawing depth maps from scratch is a pain, though, so I wanted to add tools to build on what Sprite Lamp has created so you can get good results without loads of work. Sprite Lamp’s workflow for tweaking depth maps is roughly as follows:

1. Select edges between pixels where there is a depth discontinuity.

2. Select pixels in the depth map – a process which is aided by the edges from step 1 – that are at the wrong depth (say, the pixels of an arm that need to be brought forward).

3. Move the selected pixels forward or back until they’re in the right place.

4. Repeat until things are as you want them to be.

The depth editing interface looks like this:

DepthEditor

In the preview window you can see the place where you actually interact with the image. The red lines are the edges between the pixels. The cyan lines are contours (their display can be toggled) which helps you see problems with the depth map. Edges can be detected based on various things (such as sharp changes in the normal map or the diffuse colour), or painted directly with the mouse. Selection is also painted with the mouse, although factors such as softness can be controlled, as well as only selected pixels of similar depth to where you started (important for selecting creases and the like). Selection is necessarily soft, because if you have a hard-edged selection and pull bits of it forward and back, you’ll get a big step in the depth function, which isn’t usually what you want.

You’ll also notice that there’s an undo and redo button, which kind of goes without saying with tools like this, but I still wanted to mention it because it was such a pain to implement.

I’ve since gone back to some of the Sprite Lamp test artwork that caused problems for the depth generation algorithm and done some work with the depth editing tools, and so far it has taken me very little time (usually five to ten minutes of messing about) to get things to a good state. I admit I’m not all that sure how many of Sprite Lamp’s userbase will be making extensive use of this feature but I think those that want it will be pleased with the results.

Progress on the Mac port

One of the reasons I haven’t been super talkative about features recently is that I’ve been working on some major refactoring. For the non-programmers reading this, ‘refactoring’ is another word for ‘working really hard and producing no visible results’ – in other words, I’ve been reorganising the guts of Sprite Lamp rather than adding features. This is to make things as quick and painless for the Mac port, which I’m pleased to say is now underway. I mentioned it was underway last time I think, which it was in the sense that I’d confirmed with Rob that he wanted to work on the project and he was looking over the code. Now it’s underway in the sense of code is being written and the MacOS UI is being built. This is pretty exciting for us over here, since Halley (who you may remember as the artist who has done pretty much all of Sprite Lamp’s sample art from the Kickstarter and these blog posts) is a Mac user and is very much looking forward to getting a real copy of Sprite Lamp up and running on her machine. I know there have been some people hanging out for the native Mac version, so I hope the news is good for them too.

Remaining features

The list of tasks remaining on Sprite Lamp isn’t empty, but it is getting pretty short (note that I’m not talking about engine integration stuff for the moment – there’s certainly plenty of work left to do there). I’ve still go a few things I still want to add, though, and I wanted to give people some idea of stuff that is still coming. Two major-ish features that remain on the list, both pro features, are the ability to load custom shaders for the preview window, and the ability to export a mesh based on the depth map you’ve created. Another feature that I really want in is the ability for all the map generation functions to be interruptible – currently they just block Sprite Lamp, which is fine for pixel art because they take a fraction of a second, but it’s a bit awkward having Sprite Lamp basically hang for ten seconds or so while a higher resolution image processes – I’d much rather there was a progress bar and a cancel button. That one’s a substantial task, but I think it would seriously improve the user experience and the usefulness of Sprite Lamp, especially when you’re experimenting with different settings. I also have a few features that aren’t accessible to the command line interface yet that I need to add, namely anisotropy map and palette creation. Finally, if people want it, I’m still up for making a native-looking UI for the Linux build. I feel less urgency on this one, because the Linux implementation of Winforms is actually really stable and responsive as it turns out, but unless people overwhelmingly don’t care, I’ll get to it.

At this point, though, I think that as far as 90% of users are going to care, Sprite Lamp is feature complete, and for the other 10% of users, Sprite Lamp is very close to feature complete. For that reason, I’m going to focus on getting everything aligned for the Steam release and the mac port, and then dive into the more complete engine integration – the features I’ve just mentioned will come after that. I just wanted to mention them in case anyone was worried I’d forgotten about them.

Sprite Lamp release plans

This is the post where I talk about the near future of Sprite Lamp and releasing on various platforms. Yesterday I posted about Spine integration, and I’m also working on the tools for editing depth maps. There are a couple of other smaller features I’m hoping to have added at some point, such as loading of custom shaders, but when the depth editing is done, Sprite Lamp (the standalone application, for Windows) is getting startlingly close to finished. Given that, I’m going to try to make the next release a Steam release. Fingers crossed, I can make this happen in something like the next couple of weeks.

Questions of Steam early access

I’ve given a lot of thought to early access, because I have slightly mixed feelings on it in practice. I don’t want to be ‘one of the bad ones’ – I feel like there’s a certain amount of frustration going around with certain early access projects for various reasons, and I don’t want Sprite Lamp to be one of those.  On the other hand, betas are useful for various reasons, and a platform like Steam is a good way of carrying them out. There can also be hiccups in the implementation of being on Steam itself – it’d be nice to have a chance to make sure Steam-specific things work (for instance, upgrading from hobbyist to pro will be done using the DLC system, I need to make sure that works smoothly) before it goes to a bigger audience.

So I’m pretty open to suggestion on this strategy, but currently I’m thinking of trying to get the Windows build out as a closed beta (which will involve me trying to get Steam keys to everyone who has already got Sprite Lamp by Kickstarter or through PayPal). Once that’s sorted, we’ll go into early access – at that point, it’ll be at the current (slightly) discounted Kickstarter/early price of $35/$90. When it releases fully, it’ll be for $40/$100. I’m going to try to make this early access period as quick as possible, though. During the early access period, I’ll also try to get a maximally polished Linux build onto Steam. The current Mac build isn’t really Steam-ready, though – a fact probably known to those who have tried using it. That brings us to the next section.

Sprite Lamp for MacOS

For a while I’ve been in contact with a fellow I know by the name of Rob Caporetto who was potentially going to help me out with the native UI version of Sprite Lamp for MacOS. He’s got some experience with MacOS and C#, which isn’t the most common combination of skills, so it seemed pretty ideal. Unfortunately he wasn’t free to work on stuff until fairly recently, but I’ve been in contact with him and he’s had some time to look over the source code. We’ve talked about what needs to be done and how to do it, and come to some conclusions:

  • It’s probably not worth holding up the other releases to wait for this one. I didn’t make this decision lightly, because I had always wanted a simultaneous release, but at the same time, it seems pointless to keep a working build out of Windows and Linux users’ hands just for the sake of that (especially when those two groups are likely well over half the users).
  • There’s a small amount of work for me to do on the codebase to get it ready for porting, which I’m going to jump into as soon as the depth editing stuff is done.
  • It’s probably somewhere in the ballpark of a month of work. As such, I’m going prioritise doing as much as possible of the port stuff myself, especially the grunt work, and Rob can spend all his time on the hard bits. That way it’ll be in Mac users’ hands as soon as possible.
  • More than was the case with the rest of the development, we’ll be able to prioritise the adding of features so that the most commonly used ones are in first, and as soon as we have something pretty usable, we’ll put it out there (on Steam, if we’re at that point by then, or otherwise in a regular update).
  • More as it develops.

So, that’s that. I’m pretty damn excited to see the first build working on MacOS, but not half as much as Halley is (being the artist behind Sprite Lamp’s sample art, and a mac user).

More engine integration

The other part missing from this story is the future of engine integration. More than any other part of the development of Sprite Lamp, engine integration has taken me off guard scheduling-wise, because it’s hard not to get tangled up in small details when you’re working with unfamiliar tech. However, once this next release is sorted, I’ll be able to get into doing some of the integrations closer to full-time. First priority will be Unity since so many people use that, then I’ll look at rejiggering some of the Game Maker stuff, and then basically I’m going to go through the history of people requesting engine integrations and try to get as many sorted as I reasonably can. So far I’ve been including engine integration stuff with Sprite Lamp, but when there’s a bit more complete I’ll be making them all available for free download here.