Just wondering, if there has been any talk / thought into releasing your tween library to the masses? I’d like to animate some particles, and, well… :)

Great work to you both.

Yes it is a common mistake to see something produced with GoASAP, which is just a set of core classes, and mistake the end product for what Go is. It’s like if you saw a Cairngorm app and decided that you didn’t like that framework because of someone’s application build.

Everything in Go is involved in *not* duplicating things that happen in every single animation system. There is a synchronization class at its core, for example. If 3 animation systems that use Go are used together they run incredibly efficiently even though they can all be entirely different in implementation because they are not fighting each other for performance, they can all be synchronized via the same timer.

GoEngine is just a little bit of Go of course, it also provides other common elements that should not have to be redone every time like basic event types, play controls, etc., and it has a completely extensible manager layer that is unlike any other system out there because it does not encourage developers to “bake” management into code, instead keep it entirely “decoupled.” :-)

thanks for the reply — when I am talking about core modifications I am more talking about integrating it into our framework. All of our instances using some kind of clock are synchronized with a special class. So the tweens are also synchronized like that and I would have to change your whole clock part afaik to get it to work with ours because I see no need why a tween should be updated differently.

Actually the Go framework could have done the same job of what I wanted. I had a chat today with Sebastian, the author of tweego and he definitly changed my perspective of Go because when I saw tweego I thought it is completly untyped — but in fact its not, which is great.

I think you could tweak Go in a lot of directions anyways. Making use of smarter data structures. The pool I have in the example is a really poor example but I just wrote it down quickly for the post. Making use of a linked list is again better in that case.

If you want you can contact me at j(?)je2050.de to share some ideas.

Cheers

GoASAP is certainly not another open tween engine like the others; it is far more like what you are talking about here – an extremely small and memory-efficient core system. It strips everything down to the barest of bones. One of its goals is to be universal, meaning that if you could not find a way to do what you wanted with it then it has failed to a degree. Another thing Go proposes is that we would all work together to figure out what the ultimate core system would be, and build systems from that, so that more systems would work together.

Actually, the pooling class you show here could very easily be used with Go.
When you say heavy modification of Go’s core… what are you specifically referring to? Please elaborate!

(Thanks, and sounds like you’re doing really interesting work!)

ickydime: I did not start with it at all. I think the open tween engines are all great for different purposes but to me I wanted to do it in a way that is clean in my opinion and not dependent on another developer outside of the office for such a simple thing. Since it is an in-house engine I could make use of a lot of other different tools that we have here which would not be possible without heavy modification on the core of GoASAP.