From the release notes:
Removed Texture2D.frameCount and Texture2D.frame properties. Use arrays of textures and switch them manually.
So what does that mean in reality? The Fps example is broken at the rocketlauncher.mov:
var rocketTexture : Texture2D = rocketGUI.texture;
rocketTexture.frame = rocketLauncher.ammoCount;
I really cant see the logic of removing features, and code that will break projects. To me the release notes make as much sense as “take a cat and replace it with a fish”
Right so I cant work on this project until someone explains.
Pretty please?
I believe the logic here is that Unity now imports movies as Ogg Theora video. So trying to keep compatibility with old stuff in this case involves general yuckiness, and then you end up like Windoze. Anyway, what’s wrong with replacing cats with fish?
var rocketTexture : Texture2D[]; // Array of textures
// Switch manually
renderer.material.mainTexture = rocketTexture[rocketLauncher.ammoCount];
So instead of a movie, you use an array of textures. You can export a movie as a series of still images by any number of means.
Yes. Having the series of images be stored in a movie file was, I guess, a convenient way to “package” them, but it always seemed sort of hack-ish to me anyway. I mean, a movie is supposed to move. Plus the array technique is faster.
At times tough decisions need to be made for simplicity going forward. Working on Director we had a gazillion of left-over old, half-baked, non-optimal features we continually carried forward and that added a TON of weight to the code base. The end result was a lot of old crappy features that ate into our time in dealing with really important issues… In this case for Unity the tough call was made to sever the old functionality in favor of new functionality, you can either switch to an array of Textures that you manually flip through or use a playing video via our new video texture capabilities in 2.0.
Note: you may notice that we did NOT do this same tactic with GUI Textures and GUI Text as in that case the work required to update is quite a bit heavier so we wanted to allow a longer transition period by supporting both in 2.0 even though we want you to migrate to the new GUI tools.
We realize that decisions like this do cause some work for those transitioning from 1.x authoring to 2.x authoring, but we did this with the best long-term interests in mind, the pain level here just isn’t that high (although I agree, it’s non-zero and that’s not always optimal).
And FYI, to keep your distributed content behaving nicely, all Unity 1.x authored content requires the 1.x player (1.x web files cannot be loaded in the 2.x player so it will download and install the 1.x player in parallel to offer that support). Going forward we do NOT want that to continue (the 3.x player should play 2.x content), but given that we made these sorts of decisions we had to have a solution in place so we didn’t break published content out there in the wild. At least in this case it’s only when you choose to migrate the authoring process into the new version that work is required.
Hopefully it’s all reasonable to understand and accept when looking at the “big picture” and longer-term plan for Unity. If not then you can feel free to kick me in the shins the next time you meet me, that way I’ll feel a dose of your pain. (ok, not really, please don’t do that… :lol:)
Let me take this opportunity to once again state that I use both GUI methods, they are quite different, they both have their uses which in many cases are not overlapping, and I’d really hate to lose GUITextures or GUIText. For example: can you attach a rigidbody to an OnGUI function like you can to a GUITexture object? No, of course not. (And I’m not kidding about using that, either…it’s nifty. 8) ) I’m all in favor of eliminating cruft, but that’s simply not the case here. It’s not like eliminating texture.frame, since in that case the exact same functionality is still available; you just have to implement it a bit differently.
Yup, yet again I agree with Eric 110%. Being able to use both GUITexture/GUIText and the new Unity GUI functions -together- have allow me to to things that I would not be able to do if one or the other didn’t exist. I would very much like to see both in future versions of Unity.
I’ll be honest and say that GUI Text/Textures are on the way out, but not without resolving the functional discrepancies that exist today. Our goal/vision is to close those gaps and move the new GUI structure forward.
This could be a big problem for us, depending on when the “ax” finally falls. Are we talking during the lifetime of Unity 2.x or (hopefully) with Unity 3.x (which I’m guessing with be 10-12 months from now)?
As Nich said, the best we can offer is “not in Unity 2.x”. The plan today is to leave run-time support in so that the 3.x/4.x/5.x/etc. players can properly handle 2.x-authored content so you won’t need to rewrite your projects, but as time goes on GUI Text/Textures will not get continued development, instead we will focus on the new GUI system. And as I said above, doing that includes closing the functional gaps, whether that’s done and complete in 3.x/4.x/5.x/etc. is yet to be seen.
So please understand that the plan/goal for us is NOT to make you re-write your existing projects later on, rather we want all old content to “just work” in the new player versions. But for new implementation efforts folks will instead need to start using the new GUI tools more and more over time. Hopefully that reduces/eliminates the problems you foresee.
I’d much rather Unity continue to be the easy-to-use, awesome tool that it is, and just continue to do that itself, instead of making me do extra work for stuff that’s trivial with GUIElements.
The new gui system looks pretty flash but is so scary that I’d prefer to continue using the origional system for the foreseeable future. Im sure its a breeze for some code heads, but I’ve even had professional programmers comment that its a major major jump from the “traditional” method.
However Unity 3 is not just around the corner obviously and maybe there will be some incredible tutorials for the new system. I have noticed in most demos the tendency for gui windows to appear on top of each other-maybe that just happened by accident and can be avoided.
All that said, I thoughrougly appreciate all the hard work UT does, and I hope that you guys know that.
Whoa guys, I think Nicholas was being a bit tounge-in-cheek about you having to write it yourself. Sure, if you want to continue expanding GUI Text and GUI Textures then you will have to find a way to do that. We’re going to add to the new GUI system over time because our goal is to make the new GUI as easy (if not easier) to use and more capable than GUI Text/Textures, there is NO desire to move away from an easy-to-use tool.
It depends on what you’re doing…for complex GUI stuff, it’s WAY easier than trying to wrestle with GUITextures etc. I just think GUIElements have a place that isn’t covered at all by OnGUI, which is 100% coding and no objects (plus a few other problematic areas), and that’s sometimes just not appropriate. But since 3.0 won’t be out anytime soon, I’ll stop complaining.
Please forgive me if this is a slight bit off topic but it does seem to fit the theme that this thread is heading.
I too was a bit apprehensive about using the new GUI elements but I finally decided to take the plunge and I have to say that, while maybe not as easy as the previous drag and drop components, they are, IMHO much more powerful.
I’m currently developing a FPS and found the new GUI interface a godsend for organization. I was able to embed the HUD for each weapon into the weapon’s script. When a new weapon is selected and active it contains the code to display it’s reticle, ammo count, selection outline, etc. simply. I really like the “tight binding” between the interface and the script that acts upon it.
This is not to say that there aren’t a few issues still. Like it wasn’t the most logical choice to use a “LABEL” to display a graphic in the GUI (something that I know UT is working on).
I guess my point is give the new stuff a fare chance, in the end I think you might actually like it better.
Now more “on topic”, being a developer I do understand the tough choice that UT had to make in breaking backward functionality. I also understand the pain this causes users when a perfectly functional project is now broken.
Maybe in the future UT could be a little better at pointing out “Hey this release will break x and here is how you fix it”.
(ok, not really, please don’t do that… :lol:)
For example: can you attach a rigidbody to an OnGUI function like you can to a GUITexture object? No, of course not. (And I’m not kidding about using that, either…it’s nifty. 8) ) I’m all in favor of eliminating cruft, but that’s simply not the case here. It’s not like eliminating texture.frame, since in that case the exact same functionality is still available; you just have to implement it a bit differently.