[timdog82001]

It would be very handy to have a "reveal" or "cloak" animation. This would work exactly as it sounds...you have a control that starts out fully or partially hidden, essentially invisible, and then reveal all or part of it to make it visible.

I don't know if this would be a nightmare to code internally, but from the skinner's perspective, the easiest way to approach it I can think of would be to essentially have a texture that you could use as your cloak. It would essentially be a regular image texture, a transparent png or whatever, but the texture itself would be invisible to the end user, and where ever it was on the screen, it would hide that portion of specified controls below it. You could animated this invisible control to make stuff magically "reveal" themselves (or visa versa)

It is sometimes possible to achieve similar results with zoom, but the problem is that it stretches or squishes things and that's usually not an acceptable solution with anything but perfectly square or rectangular textures.

Were it to be implemented in the manner i suggested, I'm not sure if it would be better as a new animation or a new control...I'm thinking a new control might be better because you could then possibly associate the cloak with multiple textures on the screen rather than just one at a time.

Here's an idea of how it might look as a separate control...

Code:

<control type="cloak">
  <posx>200</posx>
  <posy>300</posy>
  <width>150</width>
  <height>40</height>
  <texture>shape1.png</texture>
  <controls>4,5,12,50</controls>
  <animation effect="slide" delay="400" start="0,0" end="320,100" center="200,300">WindowOpen<animation>
</control>

Thoughts?

EDIT: skunkm0nkee's post gave me the idea of expanding this...by adding a tag like <invert>true</invert>, you could allow the cloak to work in reverse, hiding everything NOT under the texture.

[skunkm0nkee]

I seem to remember having a discussion with JM a while back where he was considering adding a viewarea type attribute for controls which I think would do what you are requesting.

The idea (JM, correct me if I'm wrong) was that you could define the viewable area for the control. So if you wanted to have a control slide out from the middle of the screen, then you set it's viewarea then position the control outside of it and then slide it into the viewable area.

It would work in a similar way to the cloaking that you describe but instead of having to place a texture to cover up parts of controls you just need to define where the control is visible.

Hopefully this concept is still possible as it would mean that the blades and sub-menus in MediaStream could be transparent and would allow quite a few other interesting effects for skinners.

[timdog82001]

Well thats actually a very interesting idea too, but it wouldn't have quite the same effect - in a way they're actually opposites (but still accomplish similar things). In that case, the control you're trying to affect would itself have to move or slide, whereas in my idea i'm assuming that the affected control would be stationary and the viewable area would in effect be changing. Unless the viewable area can have animations associated with it, then you couldn't reveal stationary objects with JM's version. However, like I said, that viewable area idea would be nice to have too. It's technically something that could be accomplished with my idea like you said, but would be a bit easier to code with jm's implementation, unless my idea was expanded to include something like an <invert>true</invert> which would mean rather than hiding everything under teh texture, it would hide everything not under the texture.

[skunkm0nkee]

You could maybe reveal stationary objects by combining 2 animations - one which scrolls the hidden control into the visible area and another which scrolls a group (containing the hidden control) in the opposite direction. The result of that would (hopefully) be that the hidden control seems to remain stationary whilst it is revealed.

[timdog82001]

Good point. Though, if you're trying to reveal multiple things at once or even in succession, things could probably get messy pretty quick.

EDIT: erm, maybe not that bad though, I for some reason wasn't thinking of a single controlgroup per animated control

[jmarshall]

The problem (and the reason it hasn't been done, and is unlikely to be done in the shortterm at least) is that the cropping operation is done outside of the animations. i.e. animations are applied after something is cropped. So things like sliding something into a cropped area has no effect (it's either already cropped, so nothing appears, or is already seen, so it always appears).

To do it the cropping would have to be done at the animation level. i.e. all texture coordinates _after_ their animations are applied would need to run through a cropper. This cropper could be quite complicated as it would need to obey animations itself. In particular, rotations would be a pain in the arse - suddenly you're no longer dealing with quads. d4rk may have some ideas as to whether this is something that can be HW accelerated. Ideally all the anims should be.

Short answer: this is completely non-trivial

Cheers,
Jonathan

[timdog82001]

I had a sneaking suspicion this wasn't too simple otherwise it would have been implemented already. Well anyway that's a shame but it was worth a shot. Should I submit a trac request just so this isn't forgotten, or is it preferred that we avoid tracking stuff that isn't expected to be looked at seriously in the foreseeable future? I don't really know the policy/preferred behavior on this to be honest

[jmarshall]

Feel free to add it there if you wish. It'd pay to add my comments as well

Cheers,
Jonathan