Ok, what I am trying to do is animate the position and scale of a GUITexture to replicate the title card sequence from A Nightmare on Elm Street; what I would like to do is have the texture start below the screen and scroll up to the center from the bottom and stop moving. At the same time, I want to start the texture at 55% of it’s original size at the bottom of the screen, and as it is scrolling up, scale it to 100%. Can I key this sort of thing or will I need to script it, and if I need scripting, can anyone help me with an example? Attached is the texture I am using.
Note: not that it matters, but I did make this image from scratch, I didn’t yank it from the DVD I have
Store some variables, namely the texture’s scale and a vertical offset position.
Use a coroutine or an Update function to animate the scale and offset position values (from “bottom of screen at 55% scale” to “middle of screen at 100% scale”).
In your OnGUI function use the scale value to get the label’s current width and height, then use that data along with the screen height and your vertical offset to calculate the label’s left and top values (so you’ll then have left, top, height, width).
Sorry but I don’t have a script handy, but hopefully the above is enough to get you started!
Yeah, I actually figured out you can use the Animation Timeline to keyframe the GUITexture transforms in the same fashion, without scripting. The problem I have now is that the GUITexture appears to move faster when I increase the resolution of the view. It still takes only 4 seconds to move/scale (because I keyed it to take that long), but at higher resolutions, the object moves across the screen faster than it would at lower resolutions (I think because even though you are traversing the same percentage of the screen, there are more pixels). I’m not sure how to correct for this, anyone know?
One of the many reasons why simple component-based 2D stuff should not be tossed out. It’s just too useful.
Seems to me that if it takes 4 seconds at any resolution, the speed therefore must be the same? Presumably we’re talking about higher resolutions on the same screen, not different screen sizes? Since in this case you’re dealing with normalized screen coordinates (reason #264 why the simple component-based 2D stuff should not go away ), it’s automatically resolution-independent, no?
Here, I will post a Unity package, try running it at low and high resolutions, it seems to me that although the animation takes 4 seconds, at higher resolutions the GUITexture appears to move faster, as well as the scaling looking weird. This also is affected by using widescreen and fullscreen resolutions. Maybe it’s just my perception :?
I am animating Local Position and Local Scale on the Transforms of the GUITexture. Starting values are Local Position Y: -0.2, Local Scale X/Y: -0.25. Ending values are Local Position Y: 0.5, Local Scale X/Y: 0. For reference, texture width/height is 450x144, with a pixel inset of -225, -72 (this forces a 1:1 pixel dimension regardless of resolution, as well as autocentering the texture regardless of resolution).
I appreciate any help you can give, this issue is actually driving me batty :?
Looks like the problem is that you’re using a scale of 0, which makes the GUITexture be pixel-exact. So it’s not resolution-independent. If you do want it to be so, then make sure the local scale doesn’t get to 0. This way you can set the size by the scale, with a bit of code to compensate for different aspect ratios if desired.
OK, that makes sense, but my problem is that I would like for the textures to be pixel exact. If this were the case, would I animate the Pixel Inset X/Y and Width/Height values instead?
It’s just too useful.