Develop Reference

Loading Multiple Scenes Additive Makes Compositor kicks in (Steam VR Unity)

I am having a issue where i suppose to load a large number of objects in my scene on an event,
so when ever i start loading these Scenesmy Vive/vr goes to compositor screen and it kinda flickers between my main scene and compositor screen
until my loading of Scenes is finished.
So my question is how to stop this flickering, i am happy to call the compositor screen till my Loading is completed and then it switch back to my Main scene or something like that which can solve this flickering issue
i have been searching around that how to call compositor screen on my own or how to stop it being called when my Loading is in progress but in vein.
any help would be much appreciated because i am out of ideas.
Thanks...

Flickering and showing compositor screen is generally caused by Unity not being able to Render a frame. I'm sure you will be able to find which object(s) (if any in particular) is causing a lag in the Profiler Tab.
I assume by "Loading" objects you mean Instancing them. If so, it depends:
a) If you instancing multiple identical objects - look up into GPU instancing methods
b) if the objects aren't unique, you may try to:
Load scene asynchronously
Place all (deactivated) objects on the first scene and instead of instancing or
loading new scene, just activate them. This will only increase initial loading
time.
Another things that you can use is:
Single Pass Stereo Rendering
use of ONLY or mostly baked lightning - which will SIGNIFICANTLY increase performance (that let me display in real time VR scene with model that counts more than 40 million vertices)

By default, SteamVR fades to grid whenever an app hangs. While of course it's ideal to keep your framerate above the threshold that would normally trigger this, there are many cases (such as loading scenes) where all the optimization in the world won't keep Unity from hanging long enough to trigger this issue.
Fortunately, this behavior can be disabled entirely! SteamVR Settings -> Developer -> Do not fade to grid when app hangs. This setting can be also be changed in the steamvr.vrsettings file which can be found using vrpathreg.exe. There, set steamvr.doNotFadeToGrid to true. This file is modified by the SteamVR Settings interface as well, but accessing it via the file directly allows you to modify settings for your target devices from within a game installer, for example.
Unfortunately as of now there isn't a way to configure this on a per-app basis, meaning the behavior will be turned off for all SteamVR apps on a user's machine. Tweaking this setting comes with the caveat that low framerates make users feel sick and the fade-to-grid feature prevents this from happening. However, in my experience, the feature is a nuisance that detracts from immersion far more than a temporary dip in framerate as long as you're following performance best practices, and if framerate is dropping anyway, this fade to grid feature causes intense flickering that's just as uncomfortable as low framerate.

Is Unity limiting my fps on Android and what can I do about it?

I'm planning to benchmark the graphical performance of the Unity engine on Android.
To do that I want my application to run without any fps-limits. The problem is that I have possible encountered such a limit when using the Unity engine.
I think that Unity is somehow limiting the framerate because I've been able to run native benchmarks on my device with well above 100fps whereas an empty Unity app can't get beyond 60fps.
I have already tried setting Application.targetFrameRate to -1 and setting the project-quality settings to "Fastest". Setting the quality settings to the fastest settings should have disabled VSync which in my experience often caused a 60fps limit.
Thanks in advance

Is it possible to update more than 60 times per second with the XNA 4.0 Game class?

I'm having a problem with timing in XNA 4.0, writing in C# and using Visual Studio 2010 express.
I'm not writing a game exactly, but I'm trying to use XNA for it's simplified content pipeline, drawing, and timing. What I'm trying to do is write a program that can time a user's response to onscreen stimuli at very fine resolutions - less than 5 ms, ideally.
To do this, I need to call the update routine (so I can poll the keyboard) no less than once every 5 ms. Even in variable step timing, I can't get the timing below about 16 ms per call. This doesn't appear to have anything to do with the amount of processing that I do in my update and draw routines. I can comment out everything in both routines and the program still spends roughly 16.66 ms on each iteration.
In fixed step timing, I can set the target to about 60 iterations per second (16.66 ms between updates), but if I try to go any faster than that, the IsRunningSlowly flag is tripped, and the game seems to try to compensate - several iterations will run faster than 60 iterations per second, and then 1 iteration will run slower.
So I guess my question is this: is the 60 iterations per second the upper limit for XNA? Is it possible to circumvent it? Should I just ditch XNA altogether?
I really appreciate your time and knowledge. Thanks in advance.

The problem you are having is due to VSync. Disable it in XNA by adding this line to your game's constructor (assuming you have the default GraphicsDeviceManager graphics):
graphics.SynchronizeWithVerticalRetrace = false;
This will allow your game to run "fast as possible". This should be "good enough" for your purposes.
See this blog post for a description of timing in XNA.
If you wanted to get more fancy: For XNA on Windows I would consider using the Windows event loop and a high resolution timer directly. Note that Game in XNA (on Windows and Xbox 360) is entirely optional.
You'd want to move as many slow operations (eg: update and draw) and blocking operations (eg: vsync) off the main thread. Note that input in XNA can only be handled on the main thread. I think you can create the graphics device on a separate thread - although I have never tried it.
You should note that, if you are measuring reaction times, there is lag in between sending a "present" command to the GPU, and that content actually appearing on screen.

I'm not expert to XNA development, but, I know I have already similar "problem" in windows phone. (slowly problem).
When you have a lot of treatment, use multithreading programming,,
msdn : "Applications that use multithreading are more responsive to user input because the user interface stays active as processor-intensive tasks execute on separate threads. Multithreading is also useful when you create scalable applications, because you can add threads as the workload increases. "
Hope I help you...

multiple realtime graphics forms in own threads, global 60fps limit?

I'm using XNA and creating a bunch of forms that roll their own 'game loop' to handle drawing and such. Each new form is opened on its own thread, with a subsequent Application.Run(form) to make the thread handle the messages for that form.
When I started I noticed that despite me not implementing any kind of frame limiting timing, the window drew at 60 fps. This was the number I was aiming for anyway so I left it at that.
However now I discovered that when I open multiple windows, the original 60 fps gets divided evenly between them: 2 windows 30 each, 3 20 each, etc.
I also tried a loop with Application.DoEvents instead of Application.Run, but with the same results.
Anyone know where this 60fps limit coming from, how to overcome it?

Go to your graphic driver settings window. Turn off VSYNC.

I'm not an XNA expert, but it sounds that you're being limited by vsync, did you check that?

You say "forms" which leads me to believe you are running in windows on the desktop and not using a dedicated full screen display?
I believe that with Vista and Windows 7, the desktop compositor ("dwm") handles all of the actual drawing. It probably runs at 60 fps (or less when on battery). I am not sure why it divides the FPS between the two windows, but it could be some interaction of locking between graphics calls.

You can't benefit from multi threading drawing calls to the GPU. The GPU, although very good at parallel processing in it's own right, interacts with the CPU one thing at a time only and everything is blocked until it finishes the task at hand. Two draw calls on one thread will take just as long as two Draw calls on separate threads. Actually slower because of threading overhead.

Play sounds with the Symbol Developer Kit in C#

We are developing a mobile application, which targets devices manufactured by Symbol. On these devices, Windows Mobile is the system.
Our application play sounds (simple beeps in fact) : we use the developer kit provided by Symbol to access the device sound card in order to play sounds.
Here is the code we use:
Symbol.Audio.Device MyDevice = (Symbol.Audio.Device)Symbol.StandardForms.SelectDevice.Select(
Symbol.Audio.Controller.Title,
Symbol.Audio.Device.AvailableDevices);
Symbol.Audio.Controller sound_card = new Symbol.Audio.StandardAudio(MyDevice);
int Duration = 15;
int Frequency = 3000;
sound_card.PlayAudio(Duration, Frequency);
With duration in milliseconds and frequency in Hertz.
Almost always, the sound is correctly played (I mean the sounds is played with the right duration).
But sometimes, the sound is played much longer (it is played during about one second).
We would like to avoid such a thing, because it is quite disturbing for users' ears.
I have no idea why this behavior exists: nothing change in the application between a short sound and a long sound. The application data is the same, no other task and no background task is executed by the application.
This beep is played when a particular screen is displayed to the user (I mean a Form object is created, and during its initialization, the beep is played). So I think that, maybe, the sound is played when the device cpu is strongly used. And because the cpu is busy, it does not succeed to play the sound for the right duration.
Maybe this problem is specific to the Symbol Developer kit?
How can I avoid such longer beeps?
Edit
I implemented the ctacke solution: I play the beep in a separate thread with high priority. Also, I increased the duration of the sound (I put 30 milliseconds instead of 15: maybe the longer the duration is, the better the system achieve to play the sound during the correct amount of time).
I don't know yet whether this implementation solve this problem or does not; because of the indeterminism of the bug, it will take some time to ensure the problem is solved.

My guess is that you're getting a GC while the audio is playing and that is playing havoc with the on/off (though without knowing exactly how Symbol implemented the call it's hard to say).
As a first stab, I'd toss the sound playing into a separate thread and crank it's priority way up using a P/Invoke to CeSetThreadPriority (not just the managed Thread.Priority property). THis would rule out you losing quantum to a driver or something, though the length of the pause suggests that it's not a quantum issue, but more likely an app issue.
If it turns out that it is related to GC (RPM would probably help you determine that), then I'd create a native library that does the audio and P/Invoke it. The GC can't mess with nati8ve threads, so you'd keep your determinism.

Make sure you're using the latest SDK. As you might already know Symbol is now part of Motorola and their Symbol Developer Kit is now renamed to Enterprise Mobility Developer Kit. The latest version of the EMDK is v2.3 and was released in January.
Maybe the problem you're experiencing has already been fixed if it was a bug in their SDK (you find release notes of all SDKs on their support website).