Wednesday, March 20, 2013

Coherent UI with new release 1.1.5

Coherent Labs is happy to announce that after a few months of hard work we are 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 hesitate and 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!

Monday, March 18, 2013

Timestamps for performance measurements

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.

References:

1. "Intel® 64 and IA-32 Architectures Software Developer’s Manuals", Volume 3
2. Game Timing and Multicore Processors
3. rdtsc in the Age of Sandybridge
4. Using the RDTSC Instruction for Performance Monitoring
5. How to Benchmark Code Execution Times on Intel® IA-32 and IA-64 Instruction Set Architectures
6. High Performance C++ Profiling
7. Time Stamp Counter

Monday, March 11, 2013

7 GDC talks programmers should not miss

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:

Stoyan Nikolov, Software Architect at Coherent Labs

Static Lighting Tricks in Halo 4

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.

Job Graph: Task Graphing In Mortal Kombat

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.

Low-Level Thinking in High-Level Shading Languages

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.

Next Generation Character Rendering

Speaker: Jorge Jimenez, Researcher, Activision Blizzard
Date: March 27
Time:  3:30PM - 4:30PM
Location: Room 304, South Hall

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.

Dimitar Trendafilov, Technical Director at Coherent Labs

Horizon and Beyond: A Look into Tomb Raider's Tools

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.

Under the Hood of Blizzard's Internal Build System

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.

Network Serialization and Routing in World of Warcraft

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.  

Thursday, February 21, 2013

Adding a HTML5 minigame in Unity3D with Coherent UI (Tutorial)

Today, we're starting a new series of blog posts with educational purposes. These posts will essentially be short tutorials for some cool new usage of HTML in your game. Let's get right to the point and see what this first tutorial has to show.

Goal


Embed an existing HTML5 minigame that opens a door upon completion.

For this demo we've chosen a minigame called "Memory Box" - you can try it out on this URL. All credit for the game goes to its authors. There's only one change in the code - we added an inline CSS style style="background-color:rgba(0,0,0,0);" to the <body> element and removed the background-color: #000; line from the CSS at the top of the HTML file to make the background transparent.

If you're very eager to see the final result, the video is at the bottom of the article.

Prerequisites


  • The AngryBots scene that comes with Unity3D
  • A cube mesh (the Unity3D box has flipped texture coordinates and shows Coherent UI textures upside down). We used this one.
  • Coherent UI for Unity3D (we'll also assume that you've already imported the package in the AngryBots project)

Scene setup


The first thing to do is to pick a door that will be opened when the user completes the minigame. In the AngryBots scene most of the doors are prefabs that have pre-attached scripts. I picked an internal door near the hologram around the entrance. It uses the TriggerOnPresence.js script and I'll refer to it throughout this article, so keep that in mind if you choose another door (external doors use a different script, for example).

Now that you have picked a door, add the cube-textures mesh somewhere around the door. It will be used as a surface where the minigame will be rendered. You don't need the whole cube, just the front face will suffice, so feel free to delete the unneeded ones. It's helpful to rename the new GameObject to something meaningful such as "CoherentSurface". That's how we'll be referring to the object from now on.

After you're happy with the placement of the object, add a CoherentUIView component to the surface so we can display HTML on it. Configure the URL, the resolution and make sure to tick the checkbox for transparency (you might not need it, depending on the minigame) and "Click to focus". The latter redirects input to the CoherentUIView after you click on the surface and is useful if you can't be bothered to write input forwarding code :).

If you hit play now you'll already have the minigame up and running, but it won't open the door yet. The setup so far should look like this:

CoherentUIView setup for the minigame

Short digression: if you tried playing the minigame, you'll notice that the player is firing when you click the dots. This can be distracting, so if you want to stop the firing you can add this code to TriggerOnMouseOrJoystick.js's Update method:

This will toggle the functianlity of the script (which is to fire bullets only) when the user presses the spacebar. Feel free to add any other logic, such as toggling firing when the CoherentUIView gains or loses focus or anything else that you might like.

Door opening logic


The door's opening logic defined by the TriggerOnPresence.js script does the following: when the user enters the object's collision volume, the OnTriggerEnter function is called, which in turn notifies all the subscribers for the specified signal. When the user exits the volume, the OnTriggerExit function is called and notifies the subscribers for the exit signal.

When inspecting the prefab, you'll find out that this signaling breaks down to sending the "OnPlay" and "OnPlayReverse" messages to the "AudioSource" and "slidingDoor" sub-GameObjects. Now that we know how to open and close the door, we can start making changes.

We won't need the proximity triggers anymore so just disable the TriggerOnPresence component from the sliding door GameObject. We'll also need to be able to identify the door's "AudioSource" and "slidingDoor" sub-objects, so we have to rename the door to something unique, such as "interiorDoorSlidingMinigame". After we have this we can open the door with the following one-liner:

GameObject.Find("interiorDoorSlidingMinigame/slidingDoor").SendMessage("OnPlay");

Great!

Wiring the minigame completion to opening the door


First, we want to have means for sending messages to the game from JavaScript. To do that, add the coherent.js script that comes with the Coherent UI Unity3D package somewhere in the top of the HTML like so (the location of the src property may be different):
"<script type="text/javascript" src="coherent.js"></script>".
This will define the "engine" object, which you can use for communication with the game.

Next, we have to find the code that's executed when you complete a level. That's at the bottom of memorybox.js, in the "if(this.isLastCorrectSquare)" conditional. If the script is totally unreadable to you, you can process it using jsbeautifier.org or some other service. Add the line "engine.call("OpenDoor");" at the end of the if block. This will send the message "OpenDoor" to the corresponding ViewListener. That's all for the HTML/JS side - just 2 lines of code!

Last, we have to handle the message sent by JavaScript in the game. To do that we make a new script, MinigameDoorOpener, and add it to the GameObject with the CoherentUIView (the CoherentSurface object). This helper script will subscribe for the View Listener's ReadyForBindings event and bind a handler for the "OpenDoor" message. The handler will simply open the door as we discussed previously. Its code is as follows (the sample script is written in C#, but you can use anything that Unity3D allows):

Now everything is wired and ready to use! After opening the door you can continue playing the minigame if you like it. You can also enhance the demo by enabling the TriggerOnPresence component of the door so it behaves like a normal door after you unlock it instead of just staying open.

Here's the video of the final result:



That's all for today's tutorial on adding big value to your game in 10 minutes. Stay tuned for more!

Friday, February 1, 2013

CryEngine 3 minimap made with Coherent UI

This is just a small update on our demo in CryEngine 3. We added a minimap using OpenLayers giving us all sorts of cartography goodness.

It's bird! It's a plane! It's a map alright!


Update: an interactive visualization of the map in your browser! (the marker uses the default OpenLayers marker image)



Move marker

Rotate marker
The movement and rotation are done automatically in the demo of course :).
[End update]

Our sample barely touches the surface of the possibilities offered by OpenLayers but it's enough for our purposes.  For simplicity's sake, I used a single non-tiled image for the map (which presents artifacts when enlarging the map). The image I used was the one I found in Game\Levels\Singleplayer\Forest\ - Forest.tif (which I converted to a format that doesn't take 16MB). The image isn't fabulous per se (it's blurry and has a lot of discontinuities) and if you want something really cool you can use an orthographic camera in the Editor and take snapshots of different tiles at different zoom levels. When you have the snapshots you can follow this tutorial to make OpenLayers use your local tiles and have a map with real zoom.

Most of the work for the map is done in JavaScript/CSS. You can toggle it by pressing Tab. The C++ part is basically just firing events for the player position and orientation.

The other C++ part (that's not actually related to the cartography) is forwarding the input to the HUD view - I made a new class (CCoherentHUDViewListener) that does the job. You can examine it if you're interested. As a side note, when forwarding input to transparent Coherent UI Views make sure that you set the ViewInfo::SupportsClickThrough to true when creating the view.

The interesting bits of JavaScript for the map are in Bin32/TestPages/hud/js/map.js. There's actually not much to it - we create an OpenLayers map, add a marker representing the player and wire some events that will come from the engine. Here's the whole script (stripped down to the essentials)
Just a few notes about the code - I found the bounds of the area depicted in Forest.jpg by flying around in the Editor and writing down some approximate numbers. You'll notice that I used negative coordinates on the Y axis - that's because it allows easier conversion from the CryEngine coordinate system to the OpenLayers one. If I used positive numbers, I'd have to write a fully fledged linear transform (a number and a minus in this case) instead of just the minus :).

The second note is about the orientation of the player marker - OpenLayers does not provide means for rotating the marker image so we have to use CSS. Fortunately, the marker object gives us all the information about the DOM element that contains the marker so that's no problem.

The HTML code for adding the map is simply <div id="map" class="smallmap">, where the smallmap class defines the size of the div element.

If you want to make the map circular you can clip it using a simple border-radius trick like so:
Here's an example of what this does (may not work on all browsers):
Original

 
Using border-radius

Or you can use some more advanced HTML/CSS technique that fits your needs.

That's all for today's update, the updated code is on GitHub so feel free to try it out and extend it. We'll be preparing the CryEngine3 showcase for GDC this year, so if you're in the Bay area at the end of March feel free to visit as at booth #241 and check it out live!