I grew up with computer games in the early 90s. King's Quest VI, Street Fighter II, Doom, Lemmings, Monkey Island, Wing Commander, Ultima Underworld, Burntime, and so many more games cemented my eternal love for pixel art games.
Back in these days I was only allowed to play computer games for half an hour a day (with a later extension to an amazing 60 minutes!). This limitation made playing games even more interesting. When my daily 30 minutes were over, I wasn't sad. Instead, I felt like I felt the day before Christmas - excited that I get to play for another 30 minutes the next day!
This love for games later brought me to Counter Strike. You could create your own maps and import models created in 3D modeling software. At the time I was using Milkshape 3D. A year later I discovered Quake 3's modding capabilities, which started a never ending passion -- creating games on my own.
As a Warhammer 40,000 fan, I wanted to turn the amazing tabletop game Necromunda into a computer game. Learning C programming was required for modding, which soon led me to creating my own terrain engine. Back in these days, we would buy every book about OpenGL and download tutorials from flipcode.com and other tutorial sites onto floppy disks. We only had internet access at school, making this whole endeavour a little more involved than it is today.
All the math I learned at school suddenly became useful -- I had to program all the collision detection and response from scratch. As computers weren't as fast as today's, I had to learn about performance optimization. With programmable shader pipelines arriving on the market, I eventually learned how to program shaders (to make grass move with the wind).
Two years later, I started my university career. I was working on another terrain engine with a few friends. Naturally, the engine had turned into a completely overambitious RPG project. I was looking for ambitious programmers to join the team and got to know Mario - finally a friend with whom I could talk about graphics and game programming!
While at university, I started working part time at Joanneum Research as a C++ programmer. My initial focus was on graphics programming via OpenGL. Later I was mostly working on DirectShow and computer vision applications. I started a computer games company called Pixelcloud Games together with my friend Florian, another graphics programming enthusiast. We started by writing our own engine for a simple 2D game, which wasn't too crazy at the time.
Soon after, Unity (version 3.3 IIRC) had just become affordable. We gathered a few thousand euros and bought our first Unity licenses. Unity didn't support automatically generating colliders for 2D sprites, so I started implementing my own solution. I polished the interface and made the package "2D Collider Gen" available on the Unity Asset Store, which I still support and maintain.
Besides other Unity projects, I also created a brain-computer-interface based training simulation game for disabled people for Graz University of Technology, worked at a VR-startup for a crazy entrepreneur, and, until recently, was an engine and shader programmer at Bongfish GmbH, working on a yet to be announced game.
Mario approached me and asked if I would like to work on Spine. Being a practitioner of Chinese Martial Arts and hugely interested in the fundamental basics of movement and animation, and with the prospect of working on the industry standard for 2D animation for games, this was an easy question to happily answer with a resounding "Yes"!
Coming from a Unity background, I'm very happy to contribute my knowledge to the Unity runtime and C# core, improve performance through parallelization and optimization, as well as being a bugslayer and making customers on the forum happy. Apart from Unity, I will be helping out with Spine's Unreal Engine integration and the C++ core runtime as well.
A very hard question! If I have to pick only one, it'd be Privateer -- the first game I played where you could fly around freely, earn money, and spend it on all kinds of weaponry to equip your spaceship.
We're super excited to announce the expansion of our little team here at Esoteric Software! Erika Inzitari has joined our efforts. For this intro, we switch things up a little, interview style.
Welcome to the team, Erika! Tell us a little bit about yourself and your background
I'm a girl who happens to like Spine very much! Previously, I went to an art academy, later I enrolled in a communication design curriculum at university. But what I really like is the idea of motion and transformation! At the age of 3, I decided I wanted to do something involving animation when I grow up. Watching movies on VHS, my favorite parts would be all the moments involving magic: a mouse turning into a horse, or a monkey into an elephant, anything was possible! I also was a lucky child as my farther taught me how to use Windows when I was 4 years old. Since I didn't have many games, I'd play around with the .exe files in the system32 folder, developing an affinity for computers (and not destroying any in the process). Those were the days! This eventually led me to look into game development as well. I've since joined a few game jams and have worked with gaming companies as an animator/rigger. It's my dream to create an interactive children's story one day, and take a stab at animated films & cartoons.
What brought you to Spine?
This is actually a bit of an awkward story. I first saw Spine when my partner researched animation tools and stated that Spine was "THE BEST TOOL EVER (tm)". I watched him use it with suspicious eyes, opposing his every cheerful comment about Spine just for the sake of opposing, saying I don't like the fact that the animations were so fluid and puppet-like, and that the price was a bit too high to spend on software I didn't know and I wasn't sure was usable for me.
Sometime later, he started talking about Spine again, pushing it as the perfect tool for what I wanted to do. I bit the bullet and started watching videos about Spine, reading up on features, checking out comparisons written by other people, checking out (amazing) works of art others have achieved using Spine. Not wanting to give him the satisfaction of being right too quickly, I said, "OK, maybe I can give this a try". I started playing around with it on the side while working for a gaming company who hadn't yet adopted Spine. At my next gig, Spine was already a requirement, so I bought me that sweet sweet Spine Professional and got to work.
I invaded the Spine forums with my first questions. Not expecting a quick answer, I checked back 2 weeks later. To my surprise, my questions had been answered immediately! This made me feel so bad, I started checking the forums daily (because even with my amazing computer skills, I couldn't find the subscribe button, which I only discovered 2 years later...). Once I knew enough, I started returning the favor, answering other people's questions, since everyone was super kind. Suddenly I found myself being very passionate about the software and especially the community.
Which is when my partner started to get his revenge... He'd nag me once in a while with a well placed, "Oh, Spine again? Wasn't that that software with too fluid and puppet-like animations?". (I swear this happened again yesterday evening!).
I couldn't help but tell him I was totally wrong, and that I'm happy he proved me wrong! I fell completely in love with Spine and think it's the best software around for 2D animations in games.
What's your role on the Spine team?
As an animator and Spine connoisseur, my role is to assist people with their Spine Editor related questions. I love some good problem solving, especially if it helps others! I'll also be in charge of a workflow-oriented tutorial series I'll be in charge of. I hope you'll find it useful!
Question from the audience. What ingredients were used to summon you from your magical realm?
10grams of Rooibos, Vanilla, a couple dog hairs, pumpkin flowers, chocolates aaaand fried potatoes.
Hot on the heels of our recent 3.6 release, we're happy to announce the release of Spine 3.7.00-beta. This release focuses on audio directly within the editor, to make synchronizing animations to your audio clips easier.
The first difference you'll notice in this beta release is the addition of an audio node in the hierarchy view.
The new audio node works similarly to the images node. All audio files found in the specified path will be listed under the audio node (which is only available in setup mode). Spine currently supports the WAV, MP3, and OGG audio formats.
Once you've placed an audio file in the (sub-)folder the audio node's path points to, it will show up under the audio node. Selecting the audio file will allow you to create a new event from the audio file.
You can also drag an audio file onto an existing event.
Events now have an additional field called "Audio path", indicating which audio file they are associated with. When you key an event with an audio path set, the dopesheet will show the length of the audio file and, in future betas, the audio waveform. When you playback the animation, the audio will start playing as soon as the event key is triggered.
Note that the duration indicator for the audio file appears in the timeline only once the audio file has been loaded.
We'll expand on the audio feature in future 3.7-beta releases. The next step is to also display waveforms for each audio file in the timeline, which will help with lining up your audio and animations.
The audio feature is currently editor-only. At runtime, audio is handled as before: register an event handler with AnimationState, react to events and playback the audio you want for a specific event based on the event's data: its name, string, int, float, or audio path fields.
For discussion, feedback, and bug reports, please post on the forum thread for this release!
After a few months of work, we've finally completed Spine 3.6! The focus was mainly on things that have been bugging both you and us for a while, including hundreds of small improvements to existing features and bug fixes. On top of that, we managed to add a few great new major features, see below!
While the Spine Runtimes faithfully reproduce your animations in your games as you see them in the editor, it was previously only possible to review transitions in-game. In 3.6, you can now preview your animations using many of the same controls that are available to you at runtime, including modifying your setup pose and animations while the preview is running! The usefulness of seeing your animation at the same time you are editing that animation cannot be overstated.
The new clipping feature lets you define a polygonal area, similar to a bounding box attachment, that will mask other slots in the draw order. The clipping area can be any concave polygon without holes and self-intersection. You can also animate the clipping area vertices. Only one clipping area can be active at a time.
Clipping is implemented CPU-side in all runtimes, as most engines do not support direct stencil buffer access or masking. Clipping can be a very expensive operation, especially if you use dense mesh attachments. Always check the performance of your clipped animations on your target platforms.
This makes for more powerful tinting so you get more out of your images. You can do some nice effects, like the Super Mario invincibility star flashing, solid color outlines, inverted colors, and more. It can also look nice when using additive, screen, or multiply blend modes.
Tint black is supported by all runtimes except spine-ts Canvas, spine-corona and spine-sfml due to API limitations of the respective framework/engine.
Modifying vertices in a dense mesh attachment is now considerably easier with our improved mesh manipulation tools. You can now select multiple vertices through soft selection and then scale, translate and rotate the selected vertices as a group! Feathered soft selections will apply your transforms only partially.
In tandem with our new mesh manipulation tools, we've also introduced weight painting tools. The weight painting tools come with feathered brush support and different weighting modes, complimenting the existing automatic and manual weighting functionality.
This new type of attachment is a point in space and a rotation, which is transformed by parent bones like you'd expect. It can be used to spawn particles or do anything else that involves a position and/or rotation. Point attachments have one advantage over bones: a point attachment can go in a skin, so the position and rotation can change for different skins. For example, different guns may shoot from different positions.
Many workflows involve working in a handful of directories. We've introduced new file dialogs that show you recently opened project files and often used directories. You can explicitly favorite a file or folder for it to show up at the top of the list. Right clicking an entry will remove it from the list. The filter box allows you to quickly filter for files by parts of their name. We've also added a few hot keys to make your file browsing even more efficient. Pressing enter will chose the most recent file or folder, pressing spacebar will immediately open the OS file dialog if you can't find the file or folder you want in your recently used lists.
AnimationState is a part of the Spine Runtimes which controls applying and queuing animations, crossfading between animations, and layering animations on top of each other. With the 3.6 release, we've vastly improved on the previous implementation, ensuring that transitions between queued animations are always smooth, without bones snapping into place. You can read more about the inner workings in our blog post AnimationState: multiple mixing without dipping.
Alongside the improvements to the Spine editor, we've also put a lot of work into making the official Spine Runtimes better!
We've added support for clipping and point attachments to all runtimes. Tint black is supported in all runtimes except spine-sfml, spine-ts canvas, and spine-corona. The tint black feature requires additional vertex attributes which these engines currently do not support.
The Cocos2d-X and Cocos2d-ObjC runtimes have seen performance gains of up to 15% by removing all per-frame allocations. We've completely rewritten the rendering infrastructure and also added mesh debug rendering support!
The Unreal Engine 4 runtime is now using the excellent RuntimeMeshComponent instead of the built-in ProceduralMeshComponent. That also means that you have to copy over the RuntimeMeshComponent plugin to your project's Plugins folder! This change was required to implement the tint black feature, for which we need custom vertex attributes. We've also ensured that the runtime works with the latest Unreal Engine 4.16.1 release. Please note that Unreal Engine 4.16 had a regression which made it impossible to compile plain .c files with MSVC++. We've submitted a PR for this issue which is now in 4.16.1!
spine-unity now supports tint black via the UV2 and UV3 vertex buffers and special tint black shaders. This capability is now shared across all Spine rendering components via the new single Spine.Unity.MeshGenerator class. You can also set the initial flip state of your skeleton in the inspector. On the Unity Editor side, we've added several improvements and tools. The biggest change you'll notice is that [SpineAttributes] now show icons in their inspector dropdown drawers so your inspectors are more readable at a glance! They can also use sibling fields as data fields so you can limit your scope within your custom serializable structs/classes (previously, it only used fields your Component class). Two new windows were also added: SkeletonDebugWindow for seeing invisible skeleton parts in Scene View and runtime debugging skeleton states, and SkeletonBakingWindow for accessing specialized baking features.
Both the spine-ts WebGL and Widget backends now support WebGL context loss recovery out of the box! The feature is on by default. We've also increased performance of the WebGL and Widget backends considerably by being smarter about what data we move to the GPU and when.
The spine-ts Canvas backend now supports shear and alpha tinting. Full color tinting is sadly not supported as the Canvas API does not expose this feature.
For a full list of changes to all runtime, check out our new runtime CHANGELOG, which details API breakage, additions, as well as new features and improvements!
Up until this release, the master branch on our spine-runtimes GitHub repository was the latest stable release you should use. Starting today, we are removing the master branch and will henceforth use branches named after major Spine versions. The latest stable version will be the default branch on GitHub, e.g. 3.6 for the current release, while development will happen in the beta branch of the next version, e.g. 3.7-beta.
If you have scripts of continuous integration builds that rely on master being the default branch, now would be a good time to update them and explicitly specify your Spine Runtime version!
With our kitchen sink release out of the way, we plan on shorter release cycles corresponding to single big features. Our roadmap for 3.7 will bring audio support, which will be available as a beta version surprisingly soon. On the runtime side, we will focus on documentation, samples, and performance improvements, as well as adding support for more engines.
Thanks to all of our users who reported issues, tested the beta, and proposed new features. We couldn't do it without you!