indielib.com

Hi, I've been searching for this for a while and found nothing about it.Has anyone implemented a gradual fade function in IndieLib (fade-in/fade-out)? Or maybe other transformations, like gradual scaling, I've managed to do it, but it is not as good as I wanted, so I'm just curious if anoyone else did this, and how they did it.

Thanks in advance.

Hi,

The fade in / out part I don't know about, - but a big wish (mine ) is that Indielib supports the Spriter format ( read more here: ) The support of this format should as far as I see it support gradual scaling, rotation etc.

Haven't seen anything regarding this subject in the forum

I have personally chipped in, regarding the crowd founding of Spriter on kickstarter. ( with a little hope, maybe we can bribe Javier to implement support for it hehe ).

_________________
Cross-platform repository: https://github.com/DarthMike/indielib-crossplatform
Cross-platform roadmap: http://www.indielib.com/wiki/index.php? ... eloper_FAQ

I think "Spriter" and "Alpha" animation is a different matter. I implemented it but putting on top my own system, as it needs to have in place a 'run loop' to 'update' alpha value over the time, and give impression of fade in and fade out.

Download source code from my games, there you can see what I did ().
I just varied alpha value overtime on my game loop. You would call repeatedly setTransparency(..) with increasingly lower or higher values till reaching 0 or 1, depending if you want to do 'fade in' or 'fade out'

I don't think we can implement alpha animation easily, because Indielib depends on the run loop of the game to be implemented outside the library. Let's say that kind of things is up to the user to implement.

Well, yes - it depends upon how you look at it.

Spriter works by having multiple image "parts", and for a given interval moving + rotating these + (z-order and a lot of other things). What is important is there is also a alpha value, and since all part images are only loaded one time, you could double your animations by copying each animation and setting the alpha value, so you have 2 sets: normal animations and fade out animations. And yes if the fadeout is longer than the animation then we have a problem ( we get a blinking animation instead ).

If we supported Spriter, we could probably make an global alpha value (+ a step value ) for each compound sprite, or for a group of sprites, this may in the user would only have to set the value once.

But again in the big picture you are right DarthMike, the easiest way is probably that the user handle it himself.

oh well, Im rambling again.

_________________
Cross-platform repository: https://github.com/DarthMike/indielib-crossplatform
Cross-platform roadmap: http://www.indielib.com/wiki/index.php? ... eloper_FAQ

I've been thinking about this, and it think it could be achieved. But anyway we would have to design another part of library which could be used or not.

What I'm thinking is, from user of library point of view:
1. Create entity, add surface to it
2. I want to animate properties of this entity:
- Position
- Alpha
-... ?


If I don't want to animate them, or animate them myself, just use library as it is now. If I want to use the property animation system, then I use new object/group of object like:
IND_PropertyAnimator->addObject(myEntity, animating, ...)

Then, the main problem is that we need external code to call us, but we can compute the time ourselves with internal timers, as we do with IND_Animation. Actually external code should be calling us by every frame calling "renderEntities2d(..)".

So I think it could be doable.

We could add this a a 'wish' feature, and input it somewhere in the milestones list.

I think that the Spriter format can handle your ideas:

Here is the implementation guide:



here is the full specification of the format:



here is the kickstarter page (project is ongoing and beta versions of the editor is allready avialable for linux, mac and windows) :

(look under updates to see current status)

I was actually thinking of a IND_SpriterAnimationManager, IND_SpriterAnimation... etc .... what do you think? ( btw: I have already created a branch for it .. to avoid messing up the stable code).

_________________
Cross-platform repository: https://github.com/DarthMike/indielib-crossplatform
Cross-platform roadmap: http://www.indielib.com/wiki/index.php? ... eloper_FAQ

And for the "gradual" part, you can use a timer (LOV_Timer()) for example, so it would be time dependant

Then, the main problem is that we need external code to call us, but we can compute the time ourselves with internal timers, as we do with IND_Animation. Actually external code should be calling us by every frame calling "renderEntities2d(..)".

_________________

http://www.amazon.com/s?ie=UTF8&page=1& ... _27%3AIIBA
http://en.wikipedia.org/wiki/Internatio ... s_Analysis
http://www.youtube.com/user/PMInstitute
https://www.facebook.com/PMInstitute

Yes I agree that external code needs to call us, but it's the same with animations, so we could implement it in library code.

@kaauz - by the way, did you manage to make it work in your app?