Make menu buttons all visualizers

[Germanunkol]

We have menu buttons (only on the main and pause menus, I believe), which are not visualizers. I find this really annoying, because it means we need to handle these animations quite differently (We have an extra function updating the buttons, and we need to render them "manually", as images).

I'd like to switch these buttons to be visualizers (one "off" and one "on" animation) - what do you think? The animation might not be quite as smooth any more...

[michalove]

Yes, go ahead and make them visualizers.

I like the smooth animations, though. They would be possible with visualizers, too, because visualizers have all the features for scaling and offsetting (we can use relX and relY for an offset, and sx and sy for scaling). The only question would be, where do we put the animation code (which is currently in menu.lua in lines 1620 to 1662).

In a perfectly organized code, this part should be attached to the visualizer. We could add an optional parameter to the AnimationDB:addAni, which would be a function. If a function is given here, then the visualizer:update just calls this function (instead of the current animation code). Or we make a new function AnimationDB:addVectorAni, which does exactly this: Take one quad from the data base and one update function.

On the other hand, since we don't use this type of animation in the rest of the game, we could go the quick and dirty way and keep this animation code in menu.lua somewhere.

Or - Option 2 - we replace the animation by a spritesheet animation and simply draw the animation by hand with sufficiently many frames. That would have one more advantage: The animation is more flexible than just scaling, rotating and moving.

I am okay with either solution. What would be the most convenient one for you?

[Germanunkol]

I made the buttons visualizers. I'm still thinking about how to add the animations. I tried once to use a sprite sheet animation with frames for the start button, it didn't look that great. I think I will add the update function method you mentioned, I like that. For buttons where we want sprite sheet animation (toilet button, maybe?) we can still use a standard visualizer - for the outside world, it doesn't matter how the animation works internally. So I'll try to go for the "clean" method.

[michalove]

Cool.

I just thought, we could implement the animations this way: In the animationDB we add one table "vectorAnimations" (or a similar name), where we store a number of such animations. Each one has a name identifier. So we could have a function "spin" which does the animation for the restart-level option or "wobble" for the start button or "jump" for the exit door. This would be very similar to the images themselves, which also have a name identifier, each.

Then we allow an optional parameter for animationDB:addAni, which has to be one of the name of the vectorAnimations. The visualizer:update then simply checks if such vector Animation exists and applies is.

The only thing is: This is a little conflicting with some hard coded animation details. For example the Goalie stretches up and down, depending on its speed. We have to check that these hard coded animations are not overwritten by the new system.

Do you want to implement this, or shall I? I will probably have some time on the weekend.

[Germanunkol]

Uh, sorry, I was quicker. Already done :P

I did almost exactly what you suggested, except I put the animations into the AnimationDB namespace (your suggestion is better, I will change this) and I named them after the buttons they were made for (your names are better again - I started with something like squeezeLeftRightAniUpdate, and the names got too long :P )

[michalove]

That went fast. I won't complain.

[Germanunkol]

Should be done. New buttons to the menu must be added as visualizers.