FourthWorld wrote: ↑Wed May 18, 2022 8:07 pm
Those tools are costly to maintain.
We can lament their passing, but if we observe that none of us have been able to justify the maintenance expense the cause of their dormancy becomes self-evident.
Animation Engine is open source I believe.
I don't think the Dormancy cause is self evident, could be caused by many things... if library doesn't get better, if it's not improved on, in addition to being maintained, it's not going to attract users, and so with a tiny audience, in an already niché market, it's hard to justify the expense, a chicken/egg situation.
On top of that if there's other libraries out there that do what you want, such as basic 2D animation functions plus a LOT more (Physics, Hit Detection, etc.), and already have a lot of active development, then why reinvent the wheel? Specially a 'wheel' that can get as complicated as animations can.
But you know, there was already a really powerful, resolution independent 2D vector animation library, with an xTalk inspired (originally) scripting language and a 'timeline' interface, and it was supported by a huge corporation, and permeated the web for about 20 years or so... Flash!
On the other hand if you worked really hard at a library continuously, you could possibly eventually produce a library that really does things in uniquely better ways then the other existing 'wheels, perhaps at a higher level, abstracting away complex stuff from a casual script author.
The two 2D engines that are now included, Cairo and Skia, can do a lot more than what are exposed to our xTalk. Some things did get added in the last 10 years, like (incomplete) SVG support.
I'd rather keep stuff like that as eXtensions, that wrap APIs included with OSes, preferably, but there's tons of great 3rd party libraries available too. Then there's only a wrapper to maintain, that benefits from improvements of a foreign library with little to no effort. Moreover, with extensions you can include multiple versions of a library and bind to them conditionally, so if for example you're wrapper needs to use on library for USB Device but a different library for a Bluetooth, you could include both libs and then a Builder handler load the one that fits the bill.
I would like to try to wrap some 2D and/or 3D engine at some point.