Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

1287017 Posts in 57031 Topics- by 47995 Members - Latest Member: crocidb

March 29, 2017, 04:50:07 pm

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsFeedbackDevLogsBasis 2d Toolset
Pages: [1] 2
Print
Author Topic: Basis 2d Toolset  (Read 5100 times)
Scott
Level 2
**


View Profile WWW
« on: May 07, 2014, 05:56:33 am »



Basis 2d Animation Toolset

Under much consideration we are resuming work on Basis.

It's been in development for 3+ years, prior to Spriter, Spine, and the many other wonderful tools becoming available lately. After these were released to fill the niche, combined with the lack of awareness of Basis, we all but gave up on it. However, through the encouragement of a few certain people, we are resuming development. Stay tuned!
« Last Edit: August 28, 2014, 10:01:06 am by Scott » Logged

migrafael
Level 3
***


Making games, two at a time


View Profile WWW
« Reply #1 on: May 07, 2014, 06:32:00 am »

If it makes you happy keep working on it. :D
Logged

On Kickstarter ยป
Scott
Level 2
**


View Profile WWW
« Reply #2 on: May 10, 2014, 10:49:50 pm »

Sprite export added! Finally!


^ Animated gif


^ Vari-size sprite sheet


^ Constant-size sprite sheet


^ Options
« Last Edit: May 12, 2014, 06:53:57 pm by Scott » Logged

Scott
Level 2
**


View Profile WWW
« Reply #3 on: May 14, 2014, 06:31:12 am »

Sprite-export meta-data! (okay maybe not the most exciting of topics)

Even though the focus is on in-game Basis animations (bones, attachment points, easing curves, physics interaction and collision, memory consumption, etc), sprite export will be very important to some.

Because there are a variety of purposes for sprite export, the next release will include gif/avi export, image sequences (1 frame per file), and sprite sheets, all with configurable sizing and padding parameters.

The other half of sprite export is the meta-data. This is easy to gloss over.

Instead of forcing users to do it this way or that way, we want the same type of flexibility as is available in the image output. So, the meta data is user-configurable. Included are examples for XML meta data, JSON, LUA, and an arbitrary Binary format. You'll be able to edit these, or create your own (Yaml, something made-up, etc).

That's why we put off the sprite export for so long though... it's not integral to the animation features, but it needed the time put into it to try to be perfect for any viable use (and not just here-it-is-use-it-our-way).

Now, back to more animation improvements!
Logged

Scott
Level 2
**


View Profile WWW
« Reply #4 on: May 22, 2014, 07:16:42 pm »

Implemented licensing.



Goals:
1) Simple to crack/reverse engineer.
2) Typical name-key generation. Key contains combination of randomness, validation, and expiration.
3) Extra time put into smooth experience. Customized edit control logic, etc.
4) Never cripple the software, in any way, under any circumstances.
« Last Edit: May 22, 2014, 07:22:40 pm by Scott » Logged

JobLeonard
Level 10
*****



View Profile
« Reply #5 on: May 23, 2014, 05:29:45 am »

Simple to crack/reverse engineer?

Anyway, this looks interesting. Following!
Logged
Scott
Level 2
**


View Profile WWW
« Reply #6 on: May 23, 2014, 06:39:36 am »

Simple to crack/reverse engineer?

Anyway, this looks interesting. Following!
I'm not interested in implementing any form of copy protection, but we do need a way to license it.

At best, it can be difficult and/or time-consuming to crack software. So with respect for the skills of the reverse-engineering community, if we do put effort into making it hard to crack one day, it'll be fun and interesting for them. Messages in code. Amusing or funny side effects for each level the software detects as being cracked. Etc. And no nasty surprises!

Besides if you want to use it in defiance to our licensing terms, it's not like you need a potentially harmful crack to unlock the software if we don't cripple it in the first place.

In the meantime, we're more interested in developing Basis  Wink
Logged

JobLeonard
Level 10
*****



View Profile
« Reply #7 on: May 23, 2014, 07:22:00 am »

 Hand Thumbs Up Left I like your attitude and it will certainly affect my judgement as to whether or not I will obtain a license at some point Tongue
Logged
Scott
Level 2
**


View Profile WWW
« Reply #8 on: June 03, 2014, 09:39:01 pm »

@JobLeonard - Even just the thought is much appreciated Smiley

A friend in Kiev has been testing.

Boring stuff:

He found a couple bugs that we missed. This led down a dark rabbit hole of issues. Spent a lot of time fixing these issues, and now subtle changes that are barely visible have made a huge difference in the feel.

More boring stuff:

Added context-aware copy and paste. This is surprisingly tricky to get right, functionally sure, but more so practically. I'm glad it was requested though. We were putting it off for a very long time but it is such a basic feature - it is good to be there.
Logged

Scott
Level 2
**


View Profile WWW
« Reply #9 on: June 05, 2014, 08:23:09 am »

We're super excited to release, and I can't wait to share the new features we're wrapping up! So naturally, our to-do list has tripled with stuff totally unrelated to these new features, and not very interesting to talk about.

See, it's not enough for us to add feature after feature (ex. we have planned FFD for a long time and could have added it long ago... but we decided not to even start it yet).

Major work has gone back into ... the basics. Workflow. The most basic actions of building and animating a character or object. Something we've revisited more times than I have fingers in the last 3 years. (I have the typical number of fingers.)

We made many small but important tweaks this last week. A couple days ago it seemed finished. After more testing, it's become clear that more and bigger changes should happen. It's not much work, but time is such a precious resource right now.

  • Will this add anything cool to a feature list to compare with other software? No.
  • Will it make Basis stand out without having to actually try it? No.
  • Is it at least worth a screenshot? No. Sad

It's not shiny, it's not something you brag about in conversation, but this is what sets Basis apart.
Logged

JobLeonard
Level 10
*****



View Profile
« Reply #10 on: June 05, 2014, 10:52:25 am »

Major work has gone back into ... the basics. Workflow. The most basic actions of building and animating a character or object. Something we've revisited more times than I have fingers in the last 3 years. (I have the typical number of fingers.)

We made many small but important tweaks this last week. A couple days ago it seemed finished. After more testing, it's become clear that more and bigger changes should happen. It's not much work, but time is such a precious resource right now.
I just finished my masters in Interaction Design. All I can say about his is: excellent!
Logged
Scott
Level 2
**


View Profile WWW
« Reply #11 on: June 05, 2014, 06:06:10 pm »

@JobLeonard - Congratulations! That is a very interesting choice you made. And thanks Smiley
Logged

Scott
Level 2
**


View Profile WWW
« Reply #12 on: June 27, 2014, 03:02:36 pm »

Basis now has inline easing curves.


Notice the linear motion


Edit the easing curves


Much nicer motion

The initial working implementation took a day... the user interface details took a couple weeks. Along with some refinements on general workflow mentioned above, things are going even nicer than before!

As for the SDK implementation, it's pretty inefficient to evaluate f(x) = y for a 2d bezier curve, because there are potentially > 1 answers. Even with artificially imposed limitations (x is always 0 to 1, y is limited in a similar way) it can be somewhat slow. So, the SDK will allow a configurable level of detail and splice the curve into multiple linear functions for in-game speed.

Also - we are looking for example art and translations. Send me a message if you are interested, and we'll discuss terms.
Logged

CasePortman
Level 1
*



View Profile Email
« Reply #13 on: June 27, 2014, 04:27:57 pm »

I am extremely interested in this tool, and that new addition looks glorious!
Logged

Soundcloud | Twitter

Freelance Music Composer, hit me up!

Website: caseportman.com
Scott
Level 2
**


View Profile WWW
« Reply #14 on: July 01, 2014, 02:31:57 pm »

@CasePortman - Thanks! PMed you to clarify something...

Usability experience, especially in the details, has been a primary design goal from the beginning.

A French tester can't get their license to work. But it does work. Why did they have trouble? Did they try it once, copy/pasting an extra space (let's handle that)? Did they type their name and not capitalize the first letter? I do not know what happened... but it will be good if we can tighten it up a bit.

This reminds me of licensing Reaper. I always wondered why they send you a text file with the key - which you must import - instead of using the traditional register dialog. For me it is faster to enter the name and key, but for someone else it may be simpler to import a file.

So, we will support both. We'll attach a license file in the registration email after purchasing. Even better, perhaps it will be a special file type to just download and double click, registering for the currently logged-in user.
Logged

Scott
Level 2
**


View Profile WWW
« Reply #15 on: July 06, 2014, 05:29:32 pm »

Added stretching on the bone-aligned axes.



This was a hard decision to make at first, because if the bone is not exactly aligned to one of the texture axes, we no longer are blitting a rotated rectangle, making some frameworks and SDKs incompatible. However, almost everything these days includes some form of mesh output, so it is worth the much needed freedom to stretch along the bone axes for more elastic animation.

Once we introduce FFD, that limitation will be set in stone anyway.
Logged

Scott
Level 2
**


View Profile WWW
« Reply #16 on: September 04, 2014, 07:59:50 pm »

Basis is finally for sale!

From this point on, releases will be much more frequent and incremental. We are currently wrapping up the first SDK, and the next release is well under way as we speak!
« Last Edit: September 05, 2014, 05:55:31 am by Scott » Logged

JobLeonard
Level 10
*****



View Profile
« Reply #17 on: September 05, 2014, 01:36:33 am »

Link is broken, remove the quotes.
Logged
Scott
Level 2
**


View Profile WWW
« Reply #18 on: September 05, 2014, 06:51:00 am »

@JobLeonard - Thanks.

Now that we've released publicly, I would like to mention the biggest challenges we have faced. I'm sure everyone has heard these before but its worth reiterating from time to time.

1) Feature creep
Whether it's games, tools, or other software, feature creep is hard to avoid. There were numerous features in Basis which were cut (for now) so we could release. It's easy to add a tool or feature experimentally and get it working in a general sense. However, ironing out all details, interface issues, bugs, and the way it interacts with the rest of the software to make sure it fits takes an enormous amount of time and iteration. Once you have that new "thing", it's hard to imagine life without it, so it becomes another critical feature which must be completed before release.

This happened over and over, until we realized we will never release by continuing in this manner. These features were cut, known bugs and some interface issues were tied up, and we released! From here on out, releases will be often and incremental. Hopefully we can mostly avoid this problem in the future.

It's called creep for a reason. We were well aware of the danger, and it still snuck its way in there...

2) Usability design
Most of the time spent developing Basis was spent, not necessarily on pretty UI, but on useful UI. You want your production pipeline to go as smoothly and efficiently as possible. Tools are meant to make that process easier. I can't count how many times we've changed major design points in the name of more efficient workflow.

It gets very tiresome at times, but the end result is something we can always be proud of.

And finally...

3) Going online and Paypal
  • Web design - Not too bad. I would eventually like to hire or contract this work out though. Do not underestimated the amount of work involved - we estimated a couple days and it took a month (lesson learned).
  • PHP - Not too bad. Like most languages, quirks had to be learned to track down bugs. Enough can't be said about online testing such as http://writecodeonline.com/php/ or http://sandbox.onlinephpfunctions.com/.
  • HTML/CSS - Hardly needs learned; you can usually look up what you need as you go. But please validate your code! We had some serious bugs that would have been avoided had we validated. HTML: http://validator.w3.org/ CSS: http://jigsaw.w3.org/css-validator/
  • MySQL - Love it. Super easy.
  • Paypal - Not so fun to integrate! It's not that hard, but it is tedious to get up and going and debug, especially if your internet connection isn't the fastest. I can help anyone with basic questions about PDT or IPN. Just PM me.
« Last Edit: September 05, 2014, 07:02:17 am by Scott » Logged

Scott
Level 2
**


View Profile WWW
« Reply #19 on: September 08, 2014, 10:42:31 am »

Runtimes

In developing the public SDK (aka runtimes), a lot of decisions have to be made that will hopefully not have to be retracted down the road. We have had runtimes for a variety of frameworks for some time, such as Unity, SDL, SFML, Hollywood-MAL (Amiga scene), LibOGC (Wii homebrew), and more. However, we have learned a lot since writing these and need to make some implementation choices and changes that will be solid ground for future work.

I believe instead of going for an totally object-oriented design (OOD), we will be aiming for a more data-centric design (DOD). Naturally, we want the interface to be intuitive and powerful from an object mindset, but internally I'm shooting for something more efficient, yet flexible enough for future changes and additions.

What is the difference?

For instance, instead of:

starting with an animation and skeleton -> composed of timelines -> each timeline interpolated and data applied to skeleton -> each bone's previously calculated total transform applied to attached textures -> these rendered in a certain order.

we have:

starting with animation data -> composed of keyframes -> composed of arrays of data -> interpolate 2 keyframes to single keyframe -> repeat if necessary (many blending options) -> calculate transform from keyframe (which implicitly defines bones) to attached textures/bounding boxes/etc directly -> render in certain order

Each method has certain advantages and disadvantages. However, the same interface (API) can be designed on top of either one. In the second case, due to the non-object-oriented-design, direct access to data can be provided but may not be as straightforward. However, functions can be provided which handle any need, and a user could certainly become familiar with the data structures to manipulate them by hand if necessary.

Advantages

If we can nail this at design time, we can structure the file format very near to the internal representation, and thus ensure load times are kept at a minimum during parsing. While it probably wouldn't be noticeable in modern systems, it is still an issue in some of the older environments which we have been asked to support.

So for the first public release of the file format (actually it's version 4) and SDK (actually it's internally version 2), I think we are going to aim for a somewhat component based approach. This allows us to ensure cache locality, at least per object, and allows us to focus optimization efforts on each step of processing as a unit (step one interpolate keys, step two transform to renderable data). Separating based on data also makes it far more straightforward to separate logic processing (events etc) from rendering. Basically we are designing for computer processing instead of human intuition internally.

The interface, whether it be for Unity or SDL or something else, will be designed with the same care and thought for the user, but we hope to flesh this out first and build on top of it.

I've decided to log details like this, even if they turn out to be bad decisions, so they can either be justified or documented when revisited in the future.
« Last Edit: September 08, 2014, 10:49:38 am by Scott » Logged

Pages: [1] 2
Print
Jump to:  

Theme orange-lt created by panic