1.2.9 is out
Yup. QuadUI 1.2.9b is out. It implements a screen re-size messaging system to allow for easily constructed fluid UIs.
Enjoy.
==
06
Yup. QuadUI 1.2.9b is out. It implements a screen re-size messaging system to allow for easily constructed fluid UIs.
Enjoy.
==
I’ll be rolling out 1.2.9b within the next couple days.
The main feature will be a finished, integrated resolution messaging system; you will be able to reposition you UI elements with ease!
Stay tuned!
==
This has been a long time in the making, mainly due to just a complete lack of time.
I’m very close to version 1.3, and a full release, now as well as an Asset Store submission. If you read the Change Logs you can see many of the roadmap features are already implemented in this release. The next step is beefing up the editor and adding a few more features for doing some more complex UI components.
Give it a try, and report any bugs you find!
==
As you are likely aware, the talented folks over at Unity Technologies have announced a tentative release for Unity 3.5 and a rebuilt UI framework. I for one eagerly await the day in which my own solution for more efficient UI can be put to rest. But until that day comes, I’m going to keep developing QuadUI.
As for some features:
There is probably more, but I’d rather spend time working on QuadUI rather than talking about it.
Stay tuned.
==
Last week I released version 1.2 of Quad UI, a Unity game engine extension which allows for the rapid development of 3D quad-based user interfaces.
It was a relatively quiet release, thankfully. The reason I am thankful is mainly due to the fact that Unity 3.2 shipped that day as well, an update that broke 2 of the core features of the extension. Working fast, though, I was able to fix the problems created by Unity 3.2 and later that night version 1.2.1, a hotfix for 3.2 was released.
So where do I go from here?
The release was much more stable than I initially thought it would be (Unity 3.2 aside), as I have continued to develop content with it internally, I have not found myself making changes to the API or the Editor. Aside from a few known, non-fatal issues, I believe the product is close to an Asset Store submission. I would like to add a few more features before I get there, though.
The road map includes adding 2 new modes to the Editor, as well as some feature upgrades and additions to the API. You can expect v1.3 to ship in the very near future.
Thanks again the community again for the support.
Cheers,
==
Back in November I released a pre-alpha feature test video of a GUI tool I was building for use inside of the Unity 3 editor. If you haven’t read about it/seen the video you can do so here.
First and foremost I just wanted to say thanks for all of the encouragement both on the blog and on Twitter, without it this would likely have become vaporware.
Well, after some holiday season radio silence I can proudly say that I will be releasing the tool for public beta early next week under the name QuadUI.
Here’s what you can expect to see:
Stay tuned over the next few days as I’ll post some videos and documentation in preparation for the beta release.
Until next time,
==
[Edit 2-2-11] This project is now dubbed QuadUI. Read more here.
In the 5 Unity games I have worked on so far, there has consistently been one job that has always been, in a best-case scenario, tedious. What I am talking about is 2D UI. The current implementation in Unity (3.1) is less than efficient when doing the 2D elements of a game. Now, I love the ability to do immediate-mode GUI, but when developing for low-end hardware and mobile that isn’t really an option. So the other out-of-the-box option is to use GUITextures, which are not only bad for memory consumption and bandwidth, but eat up those ever-so-important draw calls on our mobile hardware.
A couple other issues with how things are currently:
Now there are some fantastic solutions out there for doing 2D in Unity, some of them free, some not so much. What I have seen (and used) though, are not very artist friendly, or very time-efficient for setup. I found myself punching in way too much data into 3rd party classes, which then generated my UI at runtime (On a mobile device that left me a marginal overhead around Awake and Start).
So the last little bit I have been working on a web game that is comprised of 11 different scenes (10 levels and a main menu).
To make the game extremely lite-weight on initial load we decided to bundle the music for each level and each level themselves separately. This resulted in 21 separate asset bundles. (2 bundles per level + the main menu’s bg music)
To make things simple for programming, a basic asset loader component was constructed and placed along side each scene’s main managing script. On initial load of main menu, the music is loaded in. The user will then be able to navigate around the main menu and eventually choose a level. Upon selecting a level, a bundle containing the level that was selected is loaded in and then the Application.LoadLevel(“levelname”) is called. This works, to an extent.
Continuously upon returning to a scene that was already visited once before I received this exception:
The assetbundle ‘file_name_here.unity3d’ can’t be loaded because another asset bundle with the same files are already loaded
UnityEngine.WWW:get_assetBundle()
Okay – so… I can’t load in this bundle because it’s already been loaded. That’s fine, I’ll just check if the bundle has been loaded before I load it. Sounds simple enough. – Famous last words.