In this tutorial we'll show how to compose multiple Coherent UI views simultaneously on the main player camera.
Some example scenarios when you would like to achieve such an effect are:
1) Having both the HUD and a browser simultaneously active on the player screen - both camera-aligned
2) In a strategy game all the unit's portraits could be in one view (using the on-demand view feature for perfect gameplay synchronization) and all other HUD details (unit construction, menus, etc.) in another view
3) If you want to keep some sort of logic separate between views - for instance having the HUD and the menus in different views
These are only a handful of use cases, I'm sure many more can be invented. Keep in mind that most of the the time you could use just one view and separate the content with divs or iframes. For all the cases when this is not possible - here is a quick tutorial.
As it turns out achieving the composition is super easy in Unity3D and requires no code at all.
We'll use as a base the "MenuAndHud" sample available in the Coherent UI package.
In essence we'll render the two views on two render textures and then compose them on the Main camera via "GUI Textures".
1) Create an empty project
2) Import the Coherent UI package
3) Run Assets->Coherent UI->Install Coherent UI
4) Now navigate and open the scene we'll modify - Assets/CoherentUI/Samples/Scenes/Sample03_MenuAndHUD/Game/game.scene
5) First remove the Coherent UI View component that is currently on one of the faces of the cube
6) Remove the Coherent UI View component from the "Main Camera" (under "First Person Controller")
7) Add a Camera Game Object and set it's position to (0, 0, 100) or any other position where it won't be able to 'see' any of the scene or just use the culling mask of the camera
8) Add a Coherent UI View component to this new camera
9) IMPORTANT: Remove the 'GUI layer' component from the newly created camera.
10) Create a Render texture to hold our rendered view
11) Rename the texture to 'browser' and set it to 1024x512 pixels
12) Set the 'browser' texture as Render target for the new camera
13) Repeat steps 6-11 - create again a new camera, remove the GUI Layer component, create a new render texture but this time name it 'hudTex'. Set the Coherent UI View component on the second camera to be 1024x570 pixels and set it's 'Page' to 'coui://UIResources/MenuAndHUD/hud/hud.html'. Make sure the view has also "Is Transparent" and "Support Click Through" set to true.
14) Create a "GUI Texture" Game Object
15) Rename it to 'HudGui', set it's texture to our 'hudTex', it's position to (-512, -256) and it's size to 1024x570
16) Create another "GUI Texture" Game Object
17) Rename it to Browser, set it's texture to our 'browser', it's position to (-512, -256) and it's size to 1024x512. Note that the result will also be tinted by the GUI Texture 'Color' property. This could be used to achieve some neat effects.
18) Play!
That's it! With this technique you can compose as many views as you like anywhere on the screen. Try Coherent UI now!
After our previous showcase of a minigame that opens a door, we're continuing the series on Unity3D with Coherent UI. This time we've chosen a more social scenario - you're playing a game, finally manage to kill the big bad boss that's been troubling you and now you want to brag to your friends! Let's see how you can do this easily using Coherent UI!
Goal
Show an in-game notification when the player kills an enemy mech, take a screenshot of that glorious moment and upload it to Facebook.
Here's a picture of the mech's ashes after I killed it:
Achievement yay!
Sidenote:
If you noticed the little avatar icon in the top left corner, that's the profile picture of the Facebook user I've logged in with. Before the player logs in, the Facebook logo is displayed instead. When she clicks the logo, the Facebook login page is displayed and she's prompted to grant the sample app permission to post on her behalf. This is what the game looks like before logging in:
Avatar icon before logging in Facebook
After completing the login procedure, the image changes to the profile picture.
Prerequisites
The AngryBots scene that comes with Unity3D
Coherent UI for Unity3D (we'll also assume that you've already imported the package in the AngryBots project)
Scene setup
First, we'll have to find a mech that will act as our archnemesis and have it send a signal when it dies so we can activate the achievement logic. This is the one I chose:
The innocent mech that will soon find its doom
Fortunately, the mech GameObject already has a script that emits signals upon death, so the only thing we have to do is add another receiver and configure the action name. Since all the HTML content we need is displayed similar to a HUD, we'll add a CoherentUIView component to the Main Camera and that will be the receiver of the signal. The action name can be anything meaningful for you; I went for "OnEnemyMechDeath".
Note: you can see the last paragraph explained visually in the picture above.
We've got the death notification all sorted out, now we have to configure the receiver, i.e. the Main Camera GameObject. We've already added the CoherentUIView component and you can see its configuration on the next screenshot:
Configuration of the Coherent UI View component
Adding logic in the Main Camera GameObject
The component in the Main Camera GameObject that will be doing the hard work is the SignalReceiver. I'll first show you the whole code for the class and then briefly describe the methods.
The Start method does two important things: first, it enables URL intercepting on the view and second, adds a handler that processes URL requests before they are completed. The handler itself (OnURLRequestHandler) checks the requested URL and if it starts with a bogus address that we defined as a placeholder ("http://www.coherent-labs.com/sample.html") it redirects the request to a local resource, passing all the parameters to the local URL. If you're not sure what's going on, here's a sketch of the flow:
Login flow
That's all that the engine script has to do for the login. The other part is done by JavaScript, which will be discussed shortly.
Next, OnEnemyMechDeath. This method is executed when the mech dies and sends a signal, as we have previously seen. It triggers the JavaScript "ShowAchievementPopup" method and takes a screenshot of the kill site. The screenshot data is collected asynchronously as this article describes so the game doesn't hang for a bit. The sample still has noticable lag so you can apply more sophisticated methods for avoiding that. This data is then forwarded to the JavaScript "UploadImageOnFacebook" function.
The HTML/JavaScript side
We'll start with the HTML code for the page:
There's nothing fancy about it, it just defines the achievement element and its animation and also subscribes for various events sent by the engine.
Note: You can examine the stylesheet file at this URL if you're interested.
The facebook.js script
This script does most of the heavy lifting on the JavaScript side. It provides Facebook login functionality and functions for posting messages and photos on your wall. I'll review the initialization and uploading only, but you can check out the whole script here if you're interested.
The first thing that the script does is checking if the user is logged in Facebook. This is done by checking the anchor portion of the page URL - if there is none, we assume the user is not logged in (not the brightest, most secure way of determining that, but it does the job for the sample :)). If the user is not authenticated, a button element is appended to the HTML body that leads to the Facebook login dialog. Upon successful login, Facebook redirects the page to the same local resource that initiated the request (as we discussed previously in the login flow part). This time the window.location.hash.length property is greater than zero and the page assumes the user is logged in.
Changing the avatar icon is done by simply subscribing to the "auth.statusChange" event using the Facebook API:
Now that the user is logged in we can finally post messages and photos on the wall. Let's see what happens when we kill the mech! As we've already seen from the engine code part, the UploadImageOnFacebook JS function is called, supplying the image as a byte array and a message. That's half the parameters we need to upload an image; the other half are the user ID and the access token that allow us to form the correct URL and we have those from the FB initialization so we're good to go. An asyncronous request is sent and the result is logged.
If the AJAX request goes as planned, you should see your victory over machines documented :)
Coherent Labs is happy to announce that after a few months of hard work weare releasing a new version of Coherent UI for desktop platforms. The new things are official support for Mac, performance improvements and many bug fixes. For a complete list check out our changelog.
Coherent UI will be available in the Asset Store There are good news for Unity3D developers as well. We have submitted Coherent UI for both Windows and Mac platforms to the Asset Store and soon enough you will be able to purchase our game ui middleware directly through it. We are also going to keep the option to buy it on our website. License and pricing options The update comes with some changes in our pricing and license options. We have created two product suites:Coherent UI native and Coherent UI for Unity3D. Both of them support all desktop platforms and come with 32 and 64 bit versions.
1. Coherent UI native - for C++ & .NET projects on Windows/Mac/Linux
We provide 3 types of licensing options:
Indie - $99/seat
This version is available for game development companies with teams of 5 or less employees with annual gross revenue of $50 000 or less for the previous fiscal year.
Pro - contact us
The Pro version is designed for larger studios and has no limitations.
Trial
We allow developers to try Coherent UI by downloading a trial of the Pro version. As in the full version you are allowed to take advantage of all features and you don’t have any run-time restrictions. However, it can’t be used for commercial purposes.
2. Coherent UI for Unity
Basic - $150/seat
Basic is limited to only 2 run-time view and has to be purchased per Unity3D Pro seat as is the official asset store policy. This is ideal for users who want to integrate either only an in-game browser and/or an HTML5-based UI.
Standard - $350/seat
Standard has a no limits whatsoever. It is the best option for a team of one or several people that need a bit full freedom with their UI - you could have both an in-game browser and an HTML5 UI as well as UI + video, etc.
Pro (per title) - contact us
Pro is designed for larger studios using Unity3D as a game engine that want to take advantage of all of Coherent UI's features and need other licensing options.
Trial
We also allow game developers to try Coherent UI for Unity3D for free. The trial is based on the Standard version and can't be used for commercial purposes.
All versions come with extensive documentation, sample projects and quick-start guides so you can start implementing your new UI right away. For those of you who are looking forward to try our game UI middleware, please don’t hesitateand download it here for native and here for Unity3D.
Stay tuned for our new releases coming very soon. We continue to improve Coherent UI, to add new features and platforms. We need your feedback to make it even better. Try it and let us know what you think!
When measuring the performance of some code, a critical point to get right is having an accurate and reliable method to get some kind of timestamp at exactly the moments we are interested in.
The obvious way to measure how much time (or maybe cycles) a piece of code takes is:
start <- timestamp
*** code to measure ***
end <- timestamp
delta <- end - start
Pushing aside context switches, interrupts and other sources of error in modern systems, this is pretty straight forward IFF you have a reliable way to get a 'now' timestamp. I'll deal with context switches as a source of error for performance measurement in another post and will concentrate on just getting the timestamp right.
A ton of articles, blog posts and threads have been written on this subject. However people are still confused, so I'll try to make an overview of the possible approaches and at the end of the post there is an extensive list of references. Keep in mind that I'm looking only at ways to get timestamps for performance measurements and I'll concentrate on Windows, although some of the techniques are not OS-specific.
Timing alternatives
1. GetTickCount(), GetSystemTime(), timeGetTime() etc. The resolution provided by those is abysmal and they should not be used for any measurement. The best frequency I achieve with GetSystemTime() is 5 milliseconds. There is way to increases the resolution via timeBeginPeriod() however this also increases the pressure on the Kernel for thread scheduling and the best resolution is still too low - 1 ms.
2. QueryPerformaceCounter() - This is the preferred way according to Microsoft as stated here. The resolution is system dependent but on modern systems my observations show that it uses the RDTSC instruction and the overhead compared to 'raw' RDTSC, although significant, is not that bad unless you profile very small functions. The resolution is very high - in the nanosecond range.
3. RDTSC (Read Time-stamp counter) - Here the fun begins. Modern CPUs implement a time stamp counter that starts at 0 on processor reset and steadily increases. There is some misconception around this instruction and indeed it is kind of tricky.
It returns a 64-bit value with the counter in the EDX:EAX registers. You can access it with in-line assembler in C/C++ or with a compiler intrinsic (__rdtsc on VS).
The counter counts the processor cycles which used to be a problem as processors might throttle their frequency or the counter might even stop in some circumstances (low power mode, sleep etc.). As of Pentium 4 processors however the time-stamp counter increments at a constant rate. This is well documented in "Intel® 64 and IA-32 Architectures Software Developer’s Manuals" Volume 3 section 17.13. The feature is called "Invariant TSC" and guarantees a constant increment rate of the counter, so you should not worry about the dynamic change of frequency. This also means that you can no longer measure raw instructions performed - the TSC is now effectively a point in time. The feature can be queried as documented in the manual.
Another concern is that if a thread is migrated on a different processor between two measurements, the counter might skip too much or even "go back". There are several ways to cope with this issue - you could use SetThreadAffinityMask() on your profiled threads to lock them on a particular processor. The newer RDTSCP instruction can be used to detect such situations - it atomically returns both the TSC and the processor id it has been taken from. On my i7, on any logical processor I run it, it returns the same processor id which makes me think that it's implemented as one TSC shared by all cores, however it is not stated clearly in the documentation or I can't find it so, I wouldn't count on that. The system might also have more physical processors.
Another issue is related to the fact that the processor might not execute all instructions in the order they appear in source (and I mean the assembly too). It might so happen that instructions are moved before/after the measurement which introduces error. If a small piece of code is profiled this error can be quite significant. To 'serialize' the instructions we can use CPUID - it works as a of a fence (technically speaking it's a serialization instruction).
RDTSC actually does something like that - "The RDTSCP instruction waits until all previous instructions have been executed before reading the counter. However, subsequent instructions may begin execution before the read operation is performed" - as stated in the Intel manual.
A correct implementation on how to take measurements is given here.
Serialization instructions are quite slow and might bias the measurement too much, the profiled code will also probably run slower. If you use them you must subtract their cost from your profile. An explanation is given here.
The out-of-order execution problem applies to QueryPerformaceCounter() too, so beware.
With proper care RDTSC seems the way to go for good and fast performance profiling. Depending on the use cases however, if the added price is not a problem, I'd go with QueryPerformaceCounter() - it does offer many guarantees that RDTSC doesn't, and getting the frequency if you need to transform the abstract counters to real time is trivial. If you profile many small pices of code however the overhead might add-up.
Chrono
C++11 introduced chrono in the standard library - it's a family of classes and functions for time manipulation and measurement. I find the library to be very elegant but it has it's own very serious problems - or to be more precise, the VS 2012 has serious problems. The high_resolution_clock in VS 2012's std is NOT high resolution at all! It isn't steady either. This is because it is just a typedef for system_clock which is implemented with GetSystemTimeAsFiletime().
But it doesn't end here - the steady_clock & monotonic_clock are also implemented via the system_clock; even though they report is_steady==true && is_monotonic==true - it's a lie.
If you change the clock on your machine - bang! all 'steady' clocks go back/forward in time.
There is a bug on MSDN about the high_resolution_clock here and I hope they fix the implementation soon, because now it's almost useless now.
Boost's implementation does not suffer from these problems and can be safely used - it calls QueryPerformanceCounter on Windows for the high_resolution_clock.
I didn't check other std implementations on Windows but libstdc++ does it right on POSIX.
Event tracing for Windows
I'll talk more about using ETW for profiling in some other post - a great series on the subject was made by Bruce Dawson here.
If you do your own tracing sessions you can specify the way timestamps are captured and reported. The default is reported as system time, captured with QPC (Win Vista+) which might not be what you want.
Changes can be done by adding to the mask EVENT_TRACE_LOGFILE.ProcessTraceMode the flag PROCESS_TRACE_MODE_RAW_TIMESTAMP and then in the EVENT_TRACE_PROPERTIES.Wnode.ClientContext you can set:
1 - QPC
2 - System time
3 - RDTSC
The long post confirms that getting accurate and fast timestamps is not trivial on current computer architectures and is easy to get wrong and not notice.
Game Developers Conference 2013 is where game industry veterans are going to be in a few short weeks. Besides the networking possibilities this event is a wonderful opportunity for developers to expand their knowledge as well.
The best of the best are going to speak about how they’ve built their successful project, what technology and approaches they used to do so. New GDC talks are added daily and it could be overwhelming for some of you to choose which you would like to attend. This is why we’ve decided to pick up and share 7 talks we believe programmers should consider going to.
Here are the sessions that our team is planning to attend and we recommend you see too:
Speaker: Mike Boulton, Principal Engineer, 343 Industries Date: March 27 Time: 11:35AM - 12:00PM Location: Room 307, South Hall
Halo 4 is one of the best looking games ever so an insight into the lighting techniques used is always very interesting. Especially GPU acceleration of static light calculations is a fascinating topic with many added aspects.
Speaker: Gavin Freyberg, Director of Engineering, NetherRealm Studios Date: March 28 Time: 11:30AM - 12:30PM Location: Room 2018, West Hall
In modern multiprocessor programming environments a good architecture is extremely important in order to gain the maximum performance from the hardware. As our product is also heavily multithreaded I look forward to gather insight about the approach taken by other companies.
Speaker: Emil Persson, Head of Research, Avalanche Studios Date: March 28 Time: 4:00PM - 5:00PM Location: Room 2004, West Hall
All of Emil Persson’s talks and articles are gems. This particular one touches a topic very interesting to me as I've always liked the low-level optimization work usually required in graphics programming.
The many topics covered in this talk (SSS, eye shading, AA etc.) geared towards character rendering will give a very good overview of the current state of this particular field in games rendering. Jorge Jimenez as presenter is a guarantee that we'll see interesting and powerful algorithms.
Speaker: Jason Yao, Senior Software Engineer, Crystal Dynamics Date: March 27 Time: 2:00PM - 3:00PM Location: Room 3001, West Hall
Game editing tools define the workflow, dictate the tempo of the development process and make game development entertaining. I am especially interested in this C++ and WPF mix as I have been working on similar project in the past.
Speaker: Blaine Whittle, Senior Software Engineer II, Team 1, Blizzard Entertainment Date: March 27 Time: 3:30PM - 4:30PM Location: Room 303, South Hall Having added 30 minutes build time for a game like StarCraft II is more than enough to make this a “must see” presentation. I hope to get ideas on how to at least cut down our build time in half.
Speaker: Joe Rumsey | Principal Software Engineer, Blizzard Entertainment Date: March 28 Time: 11:30AM - 12:30PM Location: Room 2004, West Hall
I have asked myself many times about how WoW networking works.I hope I'll find the answers here. Code generation for serialization is also a personal favourite of mine.
There are many other GDC talks we are looking forward to as well. It seems like this year HTML5 games and apps development is going to be well covered as a topic as it’s becoming more trendy among indie developers. Game streaming is something else we’re also interested in as it’s going to be available as a feature in the upcoming PS4. In other words this means streaming games and playing them across a network of devices - smartphones, tablets, etc.
One more thing. If you’re going to the Game Developers Conference this year, let us know. We’d love to meet developers interested in game user interface programming and we will be glad to chat and share our vision with you. Also you will have the chance to check out live the possibilities of Coherent UI and how it could help improve your game development workflow. You might book a meeting straight from the GDC’s website or visit us directly at our booth #241.
What are the talks you will not miss and why? We will be happy to hear from you which ones would you recommend.
