TIGSource Forums

Basis released!
http://www.basis2d.com (http://www.basis2d.com)

What is it?
Basis is a tool for creating 2d animations and integrating them into games. It is designed for 2d skeletal animation. We plan on implementing very specific features for traditional animation (hand-drawn, pixel art, whatever), and eventually, level and world creation.

(http://achild.wdfiles.com/local--files/basis/LightScreen1.png) (http://achild.wdfiles.com/local--files/basis/LightScreen1.png)  (http://achild.wdfiles.com/local--files/basis/DarkScreen1.png) (http://achild.wdfiles.com/local--files/basis/DarkScreen1.png)

Features

• SDK
  • Full documentation
  • Working examples
  • Growing for more frameworks, libraries, and languages
• Textures
  • Auto detection
  • Packing
  • Multiple atlas support
• Game Interaction
  • Event triggers
  • Markers/attach points
  • World unit to pixel calibration
• Animation
  • Hierarchical IK with unlimited depth and multiple locks
  • Traditional, simple, FK
  • Inline easing curves
  • Sprite export supporting animated gifs, avis, sprite sheets, and image sequences
• Editor
  • Full undo/redo
  • User themes
  • Fully localized
  • No external dependencies, small footprint
  • 3+ years of iterations on workflow efficiency
• Much more to come!

All feedback is welcome. And thank you to everyone for your support! A lot of our encouragement came from here.

This post will continue to be updated as Basis progresses. For more in depth progress see later posts.[/list]

This sounds interesting...can it do anything with Sprites?

Can you give me an example of what you mean?

You can certainly create a single bone and attach a sprite to it, and then everything available can be done to that sprite in a sense - rotation, scaling, stretching, etc. It would allow you to create attachment points and hot spot to the sprite.

There was also the thought to also do bendables... a single skin attached to a series of bones so that when you bend and rotate them there is no seem at the joints.

[edit] There will also be a frame based image export (png, tga, whatever) as an example (with code) once it supports import/export plugins.

This sounds really efficient! I would love to see more so I can ask more questions :D

re: ripple mode in the timeline/frame control.

Note to self - when you realize that eventually accumulating floating point errors are going to absolutely break functionality regardless of clever workarounds, and that you will need to use integers internally at some point, don't try to "get away with it until later".  :facepalm:

(This is in relation to the arbitrary length of time between any 2 keyframes, for anyone wondering. On playback it really won't matter. In the editor it will be a problem.)

Yeah I also have to say this is really intriguing, and it'd certainly help to solve my problem of trying to figure out the most efficient way to attach various items to a character.

Do you have any kind of time frame for when it might be released, even if the release is a beta or some such :lol:?

I'm hoping for mid-June for a public alpha. This, of course, depends on how much time I can find to work on it. Self-motivation for it is very high, but there are simply other areas in my life that must get higher priority  :tired:. (church, family, job, ...)

It is curious though - are more people finding interest in this for what it can add to a more traditional sprite creation workflow? (versus using the 2d skeleton to aid in animation)

Stickimator is being developed iteratively. Ie once a feature is implemented, it gets tested for how it "feels" and how efficient it is, and then it is improved upon. Sometimes this is a simple tweak. Other times I realize I went about it all wrong, and perhaps other parts of the software even need re-examined. I don't believe a single feature has been "it" the first time around heheh.

I've hit one of those snags where something should honestly take you, like, a day, but 3 weeks later you're still a day away and getting a bit demotivated/frustrated. :screamy:

Hm well stay with it for sure it seems like it could be really cool! I say sprites because I find that animating sprites has never had a standalone product for it. 2-d Bones, IK, are in other programs already.

Alright!  :) So I'm finally making some headway here. I hate being stuck on the same thing for a long time. I recently was able to find a multi-hour time slot during the daytime (read: not already mentally exhausted) to just work on this and it made a huge difference. Thank you to God, my wonderful wife, and my kids.

It's funny after 15 or so years of programming the things one can learn - sometimes for the 4th or 5th time. For example - the most recent design issue Stickimator has faced is how to handle keyboard modifiers to mouse actions.

Let's say you're holding down ctrl + some mouse action. This does something different than it would without ctrl. You have completed you action, and you simply let go of ctrl and the mouse button to complete the action. However, it triggers the action that would have occurred without control!

Okay so the first issue is if, in the middle of an action, you press/unpress ctrl, do you
1) change mid-action what you're doing? (yes - every software I can think of does this)
2) does the action-change (a) apply immediately (needing visual feedback immediately) or (b) does it wait for a mouse move so that users who let go of the key fractions of a second before the mouse button don't get any unexpected surprises? Not to mention it doesn't really feel wrong to have to move the mouse again after pressing a different modifier in order to see the difference.

I'm in favor of 2a over 2b because, again, that's how most other software works. Maybe it seems like a no-brainer, but you honestly don't realize it's even a thing requiring thought until you have come to the situation. When you have logic for I'm-doing-something handled mostly in mouse-move, it requires extra thought, design, and code to ensure keyboard modifier press/release is visually represented immediately so there are no surprises and so it "feels" right! That's the hard part - which one did you expect to happen without actually having to think about it?

----- The latest list of completed tasks
- ADDED: Tools->Split command
- ADDED: Ctrl+alt+drag to move any pin without moving children with it
- ADDED: Ripple edit support in timeline control (global command 'R' key)
- ADDED: Tooltips to toolbars
- ADDED: *Version 2 of file format. Complete overhaul of internal data representation to
  support more advanced features in the future
- ADDED: *Time unit overhaul. Arbitrary integer tics used instead of floating point seconds
- ADDED: Load files through command line (drag-n-drop file to app icon)
- ADDED: Right-click cancels all timeline actions correctly
- FIXED: A number of bugfixes not listed here since it's not really public yet
- TWEAK: Internally, no more concept of "joints" and "bones". Everything is a "pin".
- TWEAK: Many other usability tweaks not listed here

(*) These required a great deal of internal changes that were very time consuming

So one completely useless cosmetic "feature" in Stickimator is the custom windows gui wrapper. The deal here is to have flicker free everything-controls as well as transparency where stuff is see through. But I also want native controls when possible.

We start with every control having the "clip children" property to knock out many flicker issues. Problem is now some of the in-built ways to get transparency won't work, because the parent isn't drawing that part normally.

So the next step is I actually have an explicit "copy background rect to dc" command that can be triggered by any child control. Also we hope for it to work on everything from XP up. Note this isn't the only method of doing this, and I'm sure it's not the best.

Now, for windows controls, consistency is an issue. Usually it's just a matter of googling the right combination of key words to find the correct method. For buttons we use WM_NOTIFY, NM_CUSTOMDRAW, and CDDS_PREERASE. Slider control is the same except we use CDDS_PREPAINT, and CDDS_ITEMPREPAINT if we want to remove those tics (though there are other issues with a Slider control because it seems to cache a bitmap internally too...). Toolbar is the same as Slider control, minus the caching issues.
---
For the combo box though! Starting in Windows Vista I think, the combobox has been updated. See the new problem here:
(http://img841.imageshack.us/img841/4898/combobad1.png)

Every combination of WM_whatever did not seem to fix this. Finally there was a method that seemed to show promise. It involved taking control of the drawing process in WM_PAINT as suggested by some places and passing a DC to wParam in a little chain command. Results:
(http://img685.imageshack.us/img685/919/combooops.png)
The main issue there not being losing the border (we were gonna redo it... or something) but losing the uniformity (sp?) of the drop-down button and the text display! It's old style white box background!

After attempting many other things, it turns out combobox handles drawing the background different than any other control I've dealt with thus far. It actually sends WM_PRINTCLIENT to the parent in order to get background information. Huh! Nothing else would work here... so the final solution seemed to be to handle WM_PRINTCLIENT in any parent (all come from the same base class) and copy it's own background. Finally!
(http://img856.imageshack.us/img856/5029/combogood.png)

[edit] Oh yeah - the other issue is wanting all this native control drawing with transparency where it should be, PLUS still allowing the newer OS's to do all that fancy shmancy animation and fading. So far success  ;D

Hardly worth a new thread IMO, but there was a challenge on another site (http://www.christiandevs.com) I frequent to make a game in 2 hours. Well I spent 6, so I didn't pass the challenge. It's a 3d procedural tunnel-of-dots race-against-the-clock. Your speed is directly related to your distance from the tunnel wall, however touching the wall will bounce you back towards the middle, slowing you down. Acceleration is impl. with sideways movements but not forwards and backwards so it's a bit clunky. Also it's my first game ever that works on Windows and linux. All binaries are in same zip here (https://dl.dropbox.com/u/3330000/OnWeb/062112SpeedCode/062112SpeedCode.zip).
(http://img51.imageshack.us/img51/2861/hsracescreen.png)

As for Stickimator, here's the to-done since last time.

- ADDED - Timeline ripple mode replace gives yes/no/cancel instead of just yes/no
- ADDED - Timeline undo/redo impl. for all actions
- ADDED - Combobox background correctly transparent on windows 7 (it stopped being square!)
- ADDED - Slider controls can disable showing tics (wanted for timeline panel)
- ADDED - Loading support for V2 files (could only load V1, save V2)
- ADDED - Background image path is saved to document if from file and not clipboard
- ADDED - Background source is shown in props
- ADDED - Consistent tooltip text for all sets of controls that might need them
- FIXED - Regression: Couldn't hide skinned bones
- FIXED - Regression: Memory leak if load ske file with skins
- FIXED - Regression: Skin editing completely broken
- FIXED - Background prop window's enabled status fixed when undo/redo a background change
- TWEAKED - Internal overhaul of Gui subsystem. Far more consistent inheritance hierarchy (and about the only thing in the entire project using actual inheritance). Finally has shared tooltip functionality and usage. Almost ready to refactor into a standalone library.

Finally back to work on this.

Fixed the UI shadow algorithm. No more seams at the corners. The top one is the corrected version, the bottom is the old version. Yeah it sounds like a boring update, but it has really crawled up my skin for some time!
(http://img515.imageshack.us/img515/961/shadowfix.png)

I want to get back into making games, so Stickimator was used to help start a simple game. It turns out a very crucial detail was overlooked on my part. There must be a way to trigger events! Things such as:

- A foot hit the ground - do a sound effect, shake the screen or something
- The animation is done 'enough' - Think of a brawler game. When you punch, you don't want to be able to trigger a new action (except taking damage) until the punch animation is a certain amount finished (such as when it is meant to connect). On the other hand, the animation may continue past the "connect" frame in some way if the user didn't input another action, probably while "tweening" back into a stand-and-breath-really-tough-like animation.
 
Stuff like that. On the other, other hand, it would be nice to have an animation graph for what can lead to what after what action .. when .. but that's looking further down the road of potential features.

But we must have events.

It's about ready for an extra early alpha release of what is done thus far. Following that, I shall plan to implement events, frame-by-frame sprite support, multiple texture sources, and more. Also will need to finish help docs and examples. And an example game. Yeah. :)

Lately
- Been doing a lot of work polishing the texture edit mode (where you define skin(s) in a texture)
- Per-animation speed implemented so an animation can be sped/slowed without having to change the timing of every. single. frame.
- More polishing on timeline editor
- C++ reference library for loading sticki files and producing renderer-independent output

I'd love to make a quick video or something demonstrating the work flow but I lack reasonable looking textures. Once I can get a hold of some, I intend to put something up.

YES! :screamy:

I like the premise of this tool!

This seems really interesting (and technical!)...I'm one of those programmers who is clueless about art  :)

Did you decide to create this to help you with your own games?  How goes the game you started using it with?

Getting good games out is basically dependent on your tools right? So off I go searching for a good 2d skeletal animation program more than a year ago, and I finally found... nothing! What? Nothing? Must say I was very surprised.

I mean there were a couple - but they were very rough imho. The problem of course is these types of tools take a lot of time, and much more so to get them right. Most people just want to get on with making their game when their tool is "good enough". And understandable so.

So yes it was basically to help me make games that consisted of characters that aren't based on spheres and circles haha. It'd be ever-so-much cooler if one day I even found an artist to work with.
---
Aside from this, I think that many people besides myself could use it. With a good work flow and polished, thought out interface (this part takes so much time), and well-debugged, hopefully less people will spend the weeks or months creating their own "enough-to-get-by" version and use this and get on with their game.

It should make animating things, regardless of your(or my) approach, much smoother, quicker, and enjoyable.

Also, with the reference library that comes with it, it should be fairly easy to just plug it into your renderer and voila your game supports smooth 2d skeletal animation and more.
---
Anyway hopefully the technical details, while accessible, are reasonably abstracted so an artist can feel like they are working with a powerful tool, and a non-artist can still work with it and not feel lost. For instance, the last 2 days have been devoted to handling:
What happens if you are using texture(s) for skinning, and you replace the source image of those textures?

In a game one will have already orchestrated texture-swapping to just work, but the editor can't assume that. What if the image is a different size? Specifically, what if some textures which are currently used as skins don't fit on the new image?

Plus, there is texture(s) auto-detection when you load a new image (based on alpha or color-key). It must integrate well into the replace-texture functionality too.
---
The solution being tested is to analyze all textures (both used and unused) in the image, see if they fit, then present the user with options on what to do. Assuming anything here on the editor's part would be bad. Even if they all fit, just the image being a different size can be a red-flag, so we still ask.

From the user's perspective, they only know something is going on if there is a potential problem, and then they are only asked a quick question with a very small number of sensible choices.
---
Next: Apply the same safety check principles to re-autodetection and to deletion of textures in an image which are currently used as active skins. Make it all transparent and not annoying to use.

This looks very accessible, dig the framework. How is it with Flash/AS3?

I've never used it before, but assuming one can texture map an arbitrary quad in flash (right?), it would just take converting the reference c++ library to flash. It is a single file with just a few hundred lines of code, and should be easy to convert to any language or framework if you know it (and c++) reasonably well.

Also the file format will be openly available, even though one could deduce it from the code.

It's insane just how much time one can spend polishing an application - whether it is a game or a tool. So, the last few weeks have been spent (amid general family, God, and life things naturally) doing just that. I have quite the all-done list of bug fixes and polish (we need a sparkly emoticon), as well as some optimizations where needed.

The todo list for releasing a more public alpha is down to the last 10 items :tearsofjoy: (including 2 bugs) so it's very, very close.

Future things once this gets out the door, in no particular order:
- IK
- Multiple image texture sources (right now all textures must be on 1 sheet)
- Frame-by-frame animation (need to think this out a bit more to integrate nicely into the current workflow)
- Export/import stuff (export image frames, import/export Spriter's scml, etc)
- Event triggering
- Hit box/sphere/hull support and animation
- Attach objects to each other
- Other surprises!
- (This is a completely free software by the way)

Almost a year and a half in the making. I'm excited.  :lol:

Okay I have a question that I would love to get feedback on if anyone would mind:

If you've worked with something like this before, when does z-order matter for you?
1) Do you basically just set it once, globally, and you're good after that?
2) Do you need it to be changeable? And if so - under what situations?

It's not a matter of implementation, so much as it is of workflow and fitting in the tool at the right place.

The only case I can think for changing z order mid-animation is if it is spinning along the x or y axis to fake some 3d-ness. It seems that would actually be a very rare thing to want though, even for a character that can turn left or right. What is your experience?

Wow I feel as if I'm working on my very own hobby vaporware!~

Seriously though, here is the latest update to prove it is not:
- ADDED - x64 support
- ADDED - Unicode support
- ADDED - Multiple improvements to SKE file format
- ADDED - Skin rigging - you can move bones/pins in skin mode without changing sprite placement
- ADDED - Drawing optimizations
- ADDED - UI improvements
- ADDED - Calibrated texture scaling

Currently working on:
- Drag a skin to the workspace to automatically create a bone and attach it to it
- IK

It turns out IK is more important than I thought for artists. One wants to move an entity into place, not rotate a bunch of bone until they get it right. Currently, you can freely move a pin by ctrl+drag, but this also changes the length of the bone it is connected to. One artist kept resorting to this to place body parts and it just ended up scaling the skins in and out. Eek!

The other "duh" issue we ran into was that you would create a bone, then try to skin it. The skin's scale would be based on the bone size, always. You could then adjust, but you never knew what the actual size of the skin was supposed to be, relative to the other skins. In fixing this, we also address how to determine a texture-pixel's scale relative to world units.

I am not a good artist but here is my flamingo in a bite animation. (Looks nicer in motion - I suppose it is time jump on the bandwagon and learn how to record videos and upload them to youtube!)

(http://img811.imageshack.us/img811/4936/biteshot.png)

FINISHED: Dragging a skin to the workspace creates a bone and attaches the skin to it, using uniform scaling
WIP: IK

I can't believe how easy IK is!!!!! I never really spent much time looking into it and just assumed it would be a huge pain, but well worth it. It turns out to be so easy. After creating a new source file and header to match, ready to fill it with hundreds of lines of code, a working implementation popped out 30 some odd lines later - including comments, blank lines, and includes!

Excuse my excitement. I'm just ... excited.

Seriously though, the main algorithm is like 6 lines of code in a loop.

For those interested, my first attempt involved a brute force approach, testing every angle for each bone, resulting in an n-dimensional array to analyze and determine the best solution. Even optimized using an n-dimensional pyramid, it was usable but could be flaky at times. The main problem was that even with just 16 initial angles to test, once you hit more than 7 or 8 bones you have to analyze tons and tons of memory. Working with an n-dimensional array easily got complex.

My second attempt uses a CCD based algorithm. It works very well. The only times this one really flakes out on me is when both the pin being moved and target are at or very-very close to a joint somewhere in the chain of bones. This makes sense because the angle formed here can be very big even though the distance is minute.

Will test at least 1 other algorithm as well, and then Stickimator will need the ability to easily lock an arbitrary number of pins in place, and we will have a very nice system indeed!

If you've always wanted to add IK to your engine/game/whatever, but have been putting it off, give it a shot! You may be pleased with the results!

This looks interesting.  What sort of data does it output?

Uses an open binary format for data, keeping all texture sources externally referenced. The plan is to have reference libs/plugins in different languages/frameworks. Definitely looking for anyone interested in implementing this in their language or framework of choice once it is a bit more mature, or really, to even experiment with it now if they'd like.

It will also support a plugin system - at the very least for file format import/export. I intend to write one for SCML (an XML based format) as an example, so others can write custom export/import plugins if they wish.

Also it will include export per-frame to PNGs in a variety of ways with some sensible options.

Well, what is the idea here-- that it generates animation data, and you load up the various images that make up your figures, then you can just animate them according to the data given when you have, say, 'make player A do this thing'?  I'm a bit confused what one does with this.

Pretty much. It generates animation data. Basically there are 2 ways it can output animation data:

1) Frame by frame sprites, usable as you would in any other sprite-based solution.
2) Natively - interpolating pin animation data (basically 2d bones). It maps various textures/skins to the bones, and your character is animated through this hierarchy.

#2 is especially nice (this method is used in more and more games these days) because you get so much more freedom. You can blend 2 different animations together. You can make one part of the body do one thing, and another part do another. You can even procedurally generate animation data blended with the recorded data (Inverse-kinematic, rigid body physics, whatever).

You can animate whole characters, objects, or even your whole world/level this way.

When I set out to start this project, gee, almost 2 years ago, there was absolutely no mature tool that I could find to do this - even though in many 2d game studios it had become the norm. Anyway, Stickimator has recently really started to come together so I have been putting more time into it (it was nearly abandoned for a while).

You might compare it to Spriter, if you've heard of it. They are very, very similar.

I'll look forward to the finished thing when it's out then. ^_^

I'm working in HTML5 for the foreseeable future, I could really see bone-based 2D animation being helpful, with the limited toolkit that Canvas offers -- it could be a big saving in bandwidth and resources over sprite sheets.

So, after my initial excitement of getting IK working and some days more work, adding other features blew it up from 30-some to over 500 LoC. And that was after using a 3rd different algorithm, 2 structural redesigns, and lots of R&D.

I also made the bones prettier. They are implicit, since everything is called a "pin" in this software, and eventually there will be other types of connections between pins besides straightforward bones (which are skinable btw). Visualization of bones will probably end up customizable as well (triangle, diamond, or plain line).

Anyway, check it out!
(http://img138.imageshack.us/img138/442/testrj.gif)

Looks awesome!  I'm guessing there's a meaning behind each stick having a fat end and a pointy end?

Simply shows parent/child relationship. The arrow points to the child. It matters less with the IK solution, where any pin(s) can be locked and any pin can be moved.

It matters more with Forward Kinematics (IK off) where bone parenting really comes into play when setting a pose for your entity. In this case children always rotate around the parent.

Can you (or will you be able to) make spritesheets with it?

Exporting sprite sheets is planned.  ;)

What are you developing this program with? What language, what software?

It's just C++ :)

Finally! We're in full motion on this thing, after over 2 years of development, and a couple other developers starting and releasing similar products in that period of time. However, I think there are still some unsolved problems which we shall address.

Also, it has been renamed "Basis" for Bone and Sprite Integration System. I have a lofty goal of knocking out a major feature per night for the next 7 nights prior to our imminent first real public release.

Night 1:
(http://imageshack.us/a/img198/9806/packboom.gif)

(notice the automatic detection of textures on this next one?)
(http://img96.imageshack.us/img96/9071/packmonk.gif)

Render to sprite (export)
So, is there anything missing here someone will be sad about? Comments in general?

(http://img221.imageshack.us/img221/3578/exportscreen.png)

For sprite sheet export, what kind of file name wildcards do people want? Currently have, depending on context:
<animname>
<animnumber>
<sheetnumber>
<framenumber>

What else will be important to you all, if anything?

So, 17 days later (I know!), naive lofty goals aside, here are a couple of the latest additions :) This is really exciting!

This actually shows 2 very major features: animated OBB collision types, and per-frame events triggering (events can be anything you make them)
(http://imageshack.us/a/img29/7743/basiseventsobb.png)

And these show, using a totally differently tuned workflow, animated AABB collision types for those who prefer a more traditional sprite based environment.
(http://imageshack.us/a/img716/1752/basisaabb1.png)
(http://imageshack.us/a/img689/781/basisaabb2.png)

A new bone type - "attach bone". Used to, you know, attach things. They function quite differently from a normal bone in the editor. They are not a simple "bone parent" either because they can be used for many other purposes than that.
(http://imageshack.us/a/img202/1769/basisattach.png)


Oh yeah, also, z order is animated, but there is no gif animation for that yet. That was a huge thing to get in there, and we're still crushing the bugs that resulted from that, though it seems quite stable by now.

It feels so good to be making some tangible progress after developing for so long!

Someone is sponsoring the integration of Basis into their game/multimedia creation software of choice. Previously mentioned software is not particularly known outside of the UK and Amiga scenes... so it will be nice to give it some love anyway!

How EXCITING! I'm surprised how exciting an email such as that can be!

 ;D

This is looking great! Is there any release planned?

Yes. Soon. For free.

However, I think we will have to attempt to raise some (kickstarter?) money in order to continue working at the pace we have been the last couple months. Without that it is going to have to become a side project that gets worked on once or twice a week.

Either way, we definitely want it to stay free.

Z order animation in action.

(http://imageshack.us/a/img17/948/basisz.gif)

Yeah baby 90% !
It's hard to define when a solid "1.0" version is for something like this that may keep evolving over time, but I think we have narrowed it down to certain sets of features which are for 1.0 and which are for after. Here are some latest features done and/or being worked on...

(http://achild.wdfiles.com/local--files/basis/BasisScreen.png)
One day we will refurbish all icons to, you know, be more consistent with each other.
There are a lot of cool features here. Micro-timelines, interpolation curves, etc. The coolest is the repeat functionality: Do an action, then repeat that action in one of many ways on other frames/animations. There have been a few times when working on this software that when I tested the feature for the first time I was surprisingly excited. This was one of them. An entire, complex, animation was quickly edited in a drastic way with this. That 6 months of NO-PROGRESS time almost seems worth it now since it was spent re-building the action/undo system, which opened the door for this baby.


(http://img12.imageshack.us/img12/4162/h9q.gif)
One big drawback with skeletal animation is trying to make things BEND that don't exactly have clearly defined joints. If the textures are drawn right, things such as arms or legs are even workable - people do it all the time. However, things like tentacles, tails, giraffe necks, etc are much harder. This is where the "tails" feature comes into place. It is heavily WIP but super exciting so far. This animation also shows the context sensitive "quick keys" help dialog.

Also, we have come up with a couple reference implementations with source+binary. Right now there are examples for Amiga, Linux, and Windows in a couple different frameworks, with more to come soon.

Honestly, I think this is to the point that I AM ready for others to start trying it out and get feedback and it can even begin to be used in games (one friend created a simple game in 3 hours on his first look at it - THAT was encouraging!). It feels SO GREAT to be satisfied with where it is at so far after 2.5 or 3 years, though still WIP, for others to try out... just waiting for a friend who is wrapping up the example animations to come with the program, and we'll be able to release!

Yay for it not becoming another dead project!

Looking good! :)

Can it export spritesheets?

@Indecom - Thanks! :)


It is in the works. A couple other things get priority, then we will impl. sprite sheet export, and possibly other types of pre-rendered export.

We have found many tools used in 2d skeletal animation are desired for sprite artists. So, Basis is meant to provide a fast and helpful workflow even if you do not plan to use skeletal animation in your game:

Texture packing, frame-by-frame animation with varying speeds, hot spot marking, AABBs for collision, sprite export with meta data, and the list goes on. It all fits very well into Basis' workflow, and most of it is already there and ready to use.

Thanks! I hope you'll release it soon. Anyway, could you put some current build on dropbox or somewhere else where you can update it without changing link? I'd love to help with testing, love tools like this.

@darkhog - PMed you

So my friend is still wrapping up his example animations to come with Basis. Busy with other things this week (silly real-life world), he only really got into it starting last night. I've taken the opportunity to implement some reference examples that use Basis animations. We hit up SDL, SFML, Allegro, HGE, .... that plugin for Hollywood (esp. for Amiga)...

Then for fun I hit up http://devkitpro.org/ (http://devkitpro.org/) and messed with a Wii build. Maybe... more than 2 nights of research and work and just forget it...

... surprisingly, after a few hours and becoming friends with GX, it was working! How fun!!

(http://imageshack.us/a/img594/7836/g5dv.jpg)
(the family Wii)

Tell me about how it exports...

Will I be able to make a customer Game Maker extension for it, via XML or what's the format looking like?

The animation data is in a binary format. Soon it will export sprite sheets with user-definable meta data (xml, json, whatever and however you want - it's fully configurable). Eventually we plan to allow import/export plugins.

There is reference code though to load animations and play them. It is implemented in a few different frameworks and platforms. It would be very easy tweak one of these to create a gamemaker plugin. Maybe a night's work (I say this from experience).

[edit] We hope to release tonight. We'll see!

Cool! I'll certainly try it out!

Well, the first version is ready! We have a kickstarter page here (http://www.kickstarter.com/projects/1457278266/basis-bone-and-sprite-integration-system) with links to the download site.

Basis is completely free, but we have decided this is really the best chance we have of taking the software where we want it to go. It's explained on the page better than I could here, really. Anyway, anyone that is interested, keep in mind it is a very early release with some incomplete features and surely some bugs. If you find anything, we would be so grateful if you could report it on the Basis webpage forums, or even here if you'd like.

Even in this early version, it is quite capable of being integrated into a game. A friend was doing a 3 hour challenge and managed to figure out Basis plus use the plugin for his system and complete his game in that time. :)

All feedback is welcome. And thank you to everyone for your support! A lot of our encouragement came from here.

I may try to make working Pascal source based on Allegro version of C source to include with samples. Interested?

Interested. Let me know if I can help in any way :)

@achild, will try to do that after I'm finished with Super Heli Land. Need to focus on that one now.

Anyway, too bad I'm completely broken and have debt collectors over my head (fortunately legal ones, wasn't involved in any loan shark business so I don't have to worry about "accident"), otherwise I would certainly give some money.

It's been a while!

Basis released!
It's a beta and some features are not complete, but hopefully we'll get some feedback/testing/usage! It is completely free and available at http://achild.wikidot.com/basis (http://achild.wikidot.com/basis).

Kickstarter failed
We realized some things that probably contributed to such a massive failure. Maybe we try again some time, perhaps on IndieGogo next time, maybe. In the mean while, due partly to the need we had for the funds, development has been very slow. :(

SDKs updated
Oh yes. SDKs have full documentation and will continue to from here on out. Also, we have re-implemented most of the framework/plugins as testing the in the real world has highlighted certain issues. All changes should be uploaded shortly.

Also, SDK build system is less cross-compiler-from-windows based, and is more centered to the systems. We build Amiga builds from Amiga, etc. Now we can support WarpOS and hopefully fix some AmigaOS4 issues we were having!!

Theming in Basis!
Old
(http://imageshack.us/a/img29/7743/basiseventsobb.png)

New
(http://achild.wdfiles.com/local--files/basis/LightScreen1.png)
(http://achild.wdfiles.com/local--files/basis/DarkScreen1.png)

My wife goes "Oh okay... NOW it looks professional!" :-X

What next?
So it is clear more games need to be developed as this develops to get some of the SDKs right, and make them as useful and easy-to-use as possible. First, we'll make something small and easy in http://hollywood-mal.com/ (http://hollywood-mal.com/) since it was sponsored by someone to me - ensure that the plugin integrates well and is very simple yet flexible.

Then... it's been a while since I've really had fun and I'd like to make a Wii game. There is already a running demo in the SDK but it would be such a nice change of pace to work on an actual game, and on the Wii at that, and take a break from all this tool development.

Then, back to Basis and more SDK stuff  :lol:

Can it export to spritesheets now?

Also I'd like to be able to turn off antialiasing for rotation/scaling, so you could easily from parts make oldschool, pixel-art like sprites.

cool I've been watching this for a while, will give it a go when I get some free time.  in any case it looks sweet, love the feature set
& thank you

edit: quick test. yea this is rad