Actually, its something I've been getting around to for a couple of years - the UI was always written with animations in mind. This was just a push to make it happen.
So here's a bit of a nothing video demoing the opacity target. This is two Background widgets, one inside the other, with an Image inside that. (Background widgets produce a nice background fill and border). There's a 10px margin between each element, so a tree of six widgets all up.
The bottommost background widget has a single animation on it: type=in/out, easing=sine, target=opacity, duration=4s, loop=true. So we can see that the opacity propagates correctly down the widget tree. Not shown is a further test where each widget has a different, non-synced opacity animation. They all get blended together properly.
It takes a single method call to add an animation:
c is the UI context and w is the widget. These are not strange concepts if you know how the UI API works, But via this, multiple animations can be added as you like, and they'll all just do the right thing.
So next up are positioning animations, which I think will mostly be offsets against the whole screen (technically the context) but might also have an option for draw offset animations within a widget's bounds, for slide-in or even auto-scroll effects. I think positioning will be easier than opacity because the layout engine is significantly more flexible than the draw stack (by necessity; layout is hard!).
I'm quite sure that positioning will cause problems with input and probably with layers as well, since it starts to bend the rule that a widget never appears outside the bounds of its parent. I think there's a couple of ways I could possible convince the system that this assumption holds even when it doesn't; we'll see.
Still to come are chained animations (when animation A finishes, run animation B) and completion signals (fire this event/call this method when an animation completes). They're both the same basic mechanism, and not particularly difficult to do.
Code is here:
As you'll see, its not particularly complicated. Most of the work so far is making the UI draw code able to mix in an opacity value without the widgets' draw methods having to know about it.
I like where this going!
First is just the Intro Menu sequence with the soft-mouse by : Pioneer Space Sim - Projected Closer Intro Screen
The second is of me nearly flying into a mountain because I'm not positioning the GUI/HUD quad correctly and it's offset... slightly, what really matters though is that the ingame UI is really being rendered onto that quad making it almost usable at last!
Pioneer Space Sim - Projected GUI/HUD
The same advanced technology and design also produced the mighty Vatakara freighter, the most advanced cargo ship of its class. The innovative internal layout gives the largest possible space for cargo of all kinds while minimising docking and loading times.
Both ships are now available from your nearest Mandarava-Csepel shipyard.
Pioneer is a space adventure game set in our galaxy at the turn of the 31st century.
The game is open-ended, and you are free to eke out whatever kind of space-faring existence you can think of. Look for fame or fortune by exploring the millions of star systems. Turn to a life of crime as a pirate, smuggler or bounty hunter. Forge and break alliances with the various factions fighting for power, freedom or self-determination. The universe is whatever you make of it.
Pioneer is under constant development and has a friendly community of players, modders and developers around it. We'd love for you to try it and make part of the galaxy your own!