Animations And LÖVE (AnAL) - The animations replacement lib

[Lap]

How is it less powerful? They both are based on quads. Your tribes animation system looks to use the same basic method as AnAL without some of the extra code and helper functions.

I wanted to implement animations in my game so I downloaded AnAL and checked it out. I deleted the stuff that wasn't needed and added the features I wanted. From download to implementation in <10 minutes. I save time, bartbes gets credit for saving me time, and my game gets versatile animations. I'm not seeing a downside here. I can't even think of a good feature I couldn't fix with a minute or two in AnAL.

[bartbes]

Then use it.

See, discussion closed using 3 words!

[Robin]

Yay for bartbes!

[Lap]

Then use it.

See, discussion closed using 3 words!

I am, I was just wondering if Elvashi knew some terrible downside about it that I was missing. That's all I was asking.

[Elvashi]

Whoa there, Did realise I'd created such a furor!

What I mean is that AnAL is a recreation of a legacy API, and using it in new code is the love equivalent of writing a modern application using the windows 16bit APIs *. There's nothing wrong with it per se, it works...but they are legacy for a reason, there's better ways now. Using a legacy API holds you to the restrictions of prior versions, and bartbes had just made it clear that he doesn't intend to expand upon AnAL as a library in its own right.

Of cause, I suppose, you are free to modify and expand AnAL yourself, but I can't help but think it might be better to just make a new API from scratch, one free of the limitations of he original, and designed to take more advantage of love's newer features.

* Not in any way a slight on bartbes' coding skills, AnAL seems to be properly written.

[Lap]

Ignoring the actual legacy support (which isn't even on by default in AnAL and is something I immediately deleted anyways), what restrictions are you referring too? As of now, if I were to write my own graphics API from scratch it would work the same way AnAL does, minus that legacy function and + some stuff specific to my game.

With actual binaries and dll's using legacy versions is definitely a pain, but here it doesn't seem to be an issue. Not only is lua super easy to modify and self update, but I not seeing any new features that are left out. I guess I could use getViewPort for some of the helper functions instead of returning a stored value, but again, that's a 30 second change.

[Luiji]

You say that you feel you must modify it to fit your needs, at which point you are essentially using a new library since a legacy library is not perfect.

Pimp: Know what I am sayin'?
Butters: Yes I know what you are saying.
- South Park

[Lap]

My modifications aside, AnAL doesn't even use legacy unless you specifically turn it on. It has everything most players would want out of the box. Just because it was designed primarily to support the old animations doesn't mean that the other 90% of the code isn't perfectly good animation code.

A whole new library because I cut a couple of functions I didn't use and added a few new arguments to newAnimation? ok....

[bartbes]

That is not true per se, the entire lib provides legacy support, the var is just there to make code changes unnecessary (so, it's for porting games, really)

[Robin]

I think Elvashi explained it rather well.

A whole new library because I cut a couple of functions I didn't use and added a few new arguments to newAnimation? ok....

The thing is, we have to see it that way, because you can invalidate anything we've said by making minor adjustments to your own copy. Now, we can't judge that, we only see plain AnAL.