Upgrading Code changes

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:

Code (csharp):

1.     var rocketTexture : Texture2D = rocketGUI.texture;
2.         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?

AC

 

For once, I agree with AC.....


...how odd.

 

Yep, this should have been left, so projects that worked fine in 1.6 continued to work fine in 2.0

 

Heh, I cant decide if thats funny or helpful or both Ray...

:?:

AC

 

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?

Code (csharp):

1. var rocketTexture : Texture2D[]; // Array of textures
2.     // Switch manually
3.     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.

--Eric

 

Thanks Eric, you're a good man..

I replaced the code with what you wrote but I guess the idea is to ditch the quicktime for a series of images? I'll go over it tommorrow..

Thanks again...

Theres a certain mantray swimming around that might find itself gobbled up by a fish..

 

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.

--Eric

 

I ran into the same issue and opted to use this script instead:

http://www.unifycommunity.com/wiki/index.php?title=Animating_Tiled_texture_-_Extended

Fortunately, my video was pretty short, looped and I still had the source images I used to create the video in the first place

 

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... )

 

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.

--Eric

 

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)?

 

Not during 2.x

And I'll leave it as an exercise to the reader to try and implement old-style GUITexture/ GUIText themselves

 

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.

--Eric

 

>echoes...

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.

AaronC

 

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.

--Eric

 

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".

 

Like so many other things in Unity, it sounds like many people have been using GUI textures in creative ways that aren't strictly GUI (ie, having images appear in 2D pixel correct, etc.)

So I think that's where the request to keep GUITextures is coming from -- not a resistance to migrating code for actual GUIs (where I'll say I LOVE GUI class GUIs!) -- but having used that mechanism for other stuff (not that I know what it all is).

Maybe there's a way to consider what that functionality does that's worth keeping as a special class.

 

Second--

It's not a resistance to migrate, but some (non intended) features we need and like (2d graphics support that easily accepts components-- I too have added physics colliders to GUITextures, and it's freaking cool)

As soon as there is a better system in place, I'm all about killing old features to keep the program light.

 

Steve, Brian and others: quoting myself to be sure it's seen and clearly understood:

We have every intent to close those gaps and be sure that the net result is a gain, not a loss in functionality.

 

I have to admit that I could have been misreading things, and I understand about the intention to close the functionality gap that exists in some cases, but I was getting a little bit of an impression of, "Hey, we've got this cool new GUI system; let's get rid of the old GUI objects because they're, well, old," possibly without considering all the implications.

My other concern is speed, though. I don't always need or want OnGUI functions running 2+ times per frame just to get some basic GUI elements on the screen. For example, with a project I'm doing right now, with no GUI elements, it gets 370fps. I have a GUI script that has a modest amount of code that makes a window with <10 buttons, which, when activated, drops it to 220fps. By contrast, about a dozen GUITextures, each with its own OnMouseDown script, only drops the fps to 330.

Of course, when the fps is that high, it hardly matters, but I'm thinking about cases where I am pushing the limits a lot harder, and want everything to run as fast as possible. In these cases I may well be using a pretty simple GUI anyway, which wouldn't need the complexity of the new GUI system.

To repeat, the new GUI stuff is great and I like it a lot. But I was still kinda seeing a little bit of loss in functionality in the future that I wouldn't want. Naturally, I realize that without knowing what's going on behind the scenes, I don't really know what I'm talking about, but those are just my thoughts, and now I really will shut up on this subject.

--Eric