I am working on a research project which needs precise timing/synchronize between the on screen display and a trigger from parallel port in Unity.
What I am trying to do is to flash the screen to white while sending a trigger to the parellel port at the same time (desired difference is within 10ms).
I mesured the screen flash with a photodiode to determine the exact time it turns white, and synchronize it with the trigger from parellel port. I always observed a delay of 40 - 70ms between the trigger and the flash (the flash arrived slower) which is my main problem.
What I have tried so far:
- Update the flash and send the trigger in the same frame (bigger delay)
- Update the flash -> WaitForEndOfFrame() -> send trigger (lower delay but still big). Below is a sample code:
IEnumerator UpdateParallelPort()
{
while (true)
{
yield return new WaitForEndOfFrame();
if (flashed == FlashState.ToWhite)
{
parallelPort.SendTrigger();
}
}
}
I also tested if the flash take multiple frames to be rendered by using ReadPixels to determine at what frame the screen turn white, but it was not the case, it was in the same frame when I issued the command. So I guess the delay comes from the time the buffer being sent to screen ? If that is the case, is there anyway to determine/synchronize the exact timing, or to minimize it ?
This is my first post in Stackoverflow, hope that I explained it clear enough. Thank you in advance for your help!
which needs precise timing
I have bad news, completely forget it.
Unity is a game engine through-and-through.
The whole entire raison d'etre, the most fundamental aspects of it, is that it lets you render mesh of dinosaurs etc, with "total compromise" of granular time, and reasonable overall perceptive time.
Unfortunately, you literally could not choose a worse milieu for the project! Sorry! :O
Related
I need a main 'home' video (full screen HD) running in a loop, and then at some point (say the user presses a key) another short movie plays (one of twelve selected at random), and then back to the home movie loop.
I'm using the mediaElement in WPF from my C# code - Is there a way to load the next movie into memory so that it's ready to play instantly? It currently takes about a second or so...
(I'm actually using two media elements with the triggered movie on top - I was doing a cross fade but have taken that out now until I can buffer the next clip. Not sure if this is the best way of doing this, any ideas? Many Thanks.
I figured out a way in case anyone is interested.
You can just specify a bunch of mediaElements on top of each other (can have different z index but not essential). Then did
video.Opacity = 0.0;
video.Play();
video.Pause();
for all of them, then when you want to play one you just set the opacity to 1 and play it and it'll play instantly.
Don't know if that's the best way, but works well. Now going to implement a cross fade to finish up. Happy days.
Okay, so I started developing a game. The first thing I wanted to set up was an extensive Debug viewer, which can ultimately show things like buttons pressed (only those that I want to listen to of course) and a graph containing information about frametime, a histogram of sorts. However, I wanted to do this the correct way. It occurred to me that I wanted to use the DrawableGameComponent class for the debugviewer, and draw the debug information there. However it seems that it can't measure the Update and Draw times correctly, as I start the update timer at the beginning of the update and end the update at the beginning of the draw. However, I shortly thereafter realized that first the main game is executed (update - draw - wait) and then are all the other components executed (update component 1, draw component 1), so they aren't intertwined. This means that I can't calculate the elapsedtime (for both Update, Draw and overhead). As we can read in this blog it's better to measure frametime as opposed to frames per seconds.
So enough with the back story and on to my main question: How do I measure the frametimes needed for both the Update, the Draw and the overhead from the main game in another DrawableGameComponent, or should I just use a class and update that in the game?
I hope that everything is clear, have a great day.
i found this http://gamedevwithoutacause.com/?p=876 which explaines exactly what you need.
If you can't measure the Update and Draw times correctly, using the update timer, can't you simply use DateTime.Now? You get it at the beginning of your Update, then every next cycle (after Update, Draw and overhead) you just subtract the DateTime.Now measured previously.
As shown in the image below, every time when I press F5/debug my app this line of messy numbers will appear at the right side of the emulator screen. Everything goes correctly as expected except this.
can anyone tell me why this strange thing happens? Thanks!
There are not quite messy.
Here is their meaning:
First three numbers: Render Thread FPS
Second three numbers: User Interface Thread FPS
Third six numbers: Texture Memory Usage
Fourth three: Surface Counter
Fifth three: Intermedia texture count
Explanation:
Render Thread FPS: The number of frames per second that the independent simple animations and rendering thread is using. Keeping around 60 will provide a great experience, while a number of 30 fps will begin to show a poor experience to the end user.
Under 30 fps this counter will turn red in post-beta builds.
User Interface Thread FPS: The number of fps that the primary user interface thread is experiencing. Property change notifications, data binding, primary managed code execution, and animations not handled on the render thread use this threads’ resources.
Turns red when the count is at or below 15 fps.
Texture Memory Usage: A specialized memory counter indicating the video memory used for storing application textures.
Surface Counter: A count of the number of surfaces that are passed to the graphics chip.
Intermediate Texture Count: The number of intermediate textures created for compositing.emphasized text
Reference: http://www.jeff.wilcox.name/2010/07/counters/
There is an article on MSDN titled "Frame Rate Counters in Windows Phone Emulator" that explains what the numbers mean and how to turn them off.
Basically, I have an application witch is 8000px by 8000px. We can zoom in to view a specific part, example on the radio, or we can zoom out to view everything.
Each part of the car is a control that we can manipulate with fingers, on a dual touch or multitouch monitor.
My problem is: for manipulating a control, for example the Volume button, the user needs to move the mouse exactly like in real life, so with a circular movement.
With the mouse everything is perfect, it responds instantly without any delay. I use the OnMouseLeftButtonDown, OnMouseMove, etc.
With the touch, it seems to be very difficult for the computer to get the touch position and there is a huge lag, especially when the user move 2 different button with 2 fingers at the same time. I use the OnTouchDown, OnTouchMove, etc...
The only difference between the mouse and the touch is when we need to get the position, with the Mouse I use: (e is a MouseButtonEventArgs)
Point currentPosition = e.GetPosition(this);
With the Touch I use: (e is a TouchEventArgs)
Point currentPosition = e.GetTouchPoint(this).Position;
Everything after this is the same.
I don't know if it's because I have too many control in the my application (over 5000 that we can manipulate, but when we zoom in on only 2 control it's the same thing) or because it is really difficult for the computer to get the position from a touch event....
Can someone help me with this? I need to find a solution to eliminate the lag.
I use Visual Studio 2010, Blend 4, .NET 4.0
Windows 7 64-bit
7 Gb RAM
Xeon 2.13 Ghz, 2 core, 8 thread
Screen: ELO technology, in a NEC 2490WUXi2 screen
This seems to be a bug. Take a look at this post.
http://social.msdn.microsoft.com/Forums/en-US/wpf/thread/756a2ccf-6cf1-4e4a-a101-30b6f3d9c2c9/#ed51226a-6319-49f8-be45-cf5ff48d56bb
Or
http://www.codeproject.com/Articles/692286/WPF-and-multi-touch
it's hard to say why you have such an issue - may be OnTouchMove is triggered more often than MouseMove and you should create some additional processing to smooth the touch positions data.
I'd try to comment all the code under the
Point currentPosition = e.GetTouchPoint(this).Position;
and look at the performance.
Another approach is to count how much OnTouchMove is triggered.
The problem is the touch device, try another one to see if the lag is still there.
I'm working on a real-time WPF/Silverlight (and soon WP7) visualization component and I'm looking for the best solution to force a redraw of the entire component in a Game-loop style. Redraw should be on-demand, but I don't want to back up the message pump with re-draw calls. Most of the drawing in my component is done using non-WPF primitives (e.g. Bitmap Interop, Direct2D) so my code does not use InvalidateVisual, and as a result, currently looks like this
// Pseudocode, doesnt compile, just to convey the meaning
public void InvalidateElement()
{
if (CurrentlyDrawing)
return;
Dispatcher.BeginInvoke(() =>
{
CurrentlyDrawing = true;
DoDrawInternal();
CurrentlyDrawing = false;
}
}
Ok so this is great. If I call InvalidateElement lots of times I get good responsiveness. However, what I want to do is ensure I can push data to my visualization component as fast as possible but only draw when the component is able to draw, and not keep drawing to catch up with the data once the input stream completes.
No I can't override OnRender, I'm using non-WPF drawing inside WPF ;-)
Basically what I want is something like the old Invalidate() / OnPaint in WindowsForms, or better yet, a game loop in DirectX.
At the moment I get the situation where if I have an external thread that pushes data to the visualization component at a high rate then if I Stop pushing data I get another 20 seconds worth of refreshes to get through before the component stops drawing. I want to stop drawing as soon as data has gone in.
Another idea I had was to handle CompositionTarget.Rendering in the visualization component then implement some sort of rudimentary Queue to push data to and the Rendering event consumes this data as fast as it can.
In Summary
Given a WPF visualization component, V, and a datasource which pushes it data every 1ms, D, how can I ensure that no matter the datarate of D, V draws data at 30FPS (or whatever it can do) and updates itself in chunks, sort of how a game render loop does in DirectX?
When the data stops, V should redraw everything it has up to now in one go. When the data is too fast, V draws larger chunks at a time to compensate.
If you need more information I'd be happy to share it. Right now I've just posted a synopsis to gauge if there are any quick fixes but a fuller Q with code examples can be provided on request.
Best regards,
You might want to consider rendering on the CompositionTarget.Rendering event and throttling on the invalidated state.
Silverlight game loop example (F#):
/// Run game
let runGame () =
let state = gameState.GetEnumerator()
let rate = TimeSpan.FromSeconds(1.0/50.0)
let lastUpdate = ref DateTime.Now
let residual = ref (TimeSpan())
CompositionTarget.Rendering.Add (fun x ->
let now = DateTime.Now
residual := !residual + (now - !lastUpdate)
while !residual > rate do
state.MoveNext() |> ignore
residual := !residual - rate
lastUpdate := now
)
Play the game: http://trelford.com/blog/post/LightCycles.aspx
Read the source: https://bitbucket.org/ptrelford/lightcycles
You can listen to the CompositionTarget.Rendering event, which is triggered right before WPF renders the UI, and do your drawing in there.
Another tidbit.. InvalidateVisuals() is nothing like Form.Invalidate(), as it also causes re-layout which is expensive. If you want something like Form.Invalidate(), then create a DrawingGroup (or bitmap image) "backingStore", place it in the DrawingContext during OnRender(), and then update it whenever you want. WPF will automatically update and repaint the UI.
Have you thought of using a dispatch timer running at 30FPS, then take a snapshot of the current data and rendering it at each timer tick? If you want to avoid redrawing if nothing has changed, you can simply keep timestamps for LastChanged and LastRendered, only performing an actual redraw if LastChanged > LastRendered. Basically updating the data and rendering the data are decoupled from one-another; the main trick is making sure you can somehow get a coherent snapshot of the data when the rendering thread wants to render it (i.e. you'll need some sort of locking.)
I was recently working with a project that required a game loop like style. Although my example is purely in F#, you can figure it out how you can do that way in C# too, may be use some interop code to initialize the timer and hooking up events as given in this below link,
http://dl.dropbox.com/u/23500975/Demos/loopstate.zip
The sample doesn't show how to redraw, it just updates the underlying stock data for every 500ms, It should pretty much work for any kind of drawing mechanisms with WPF. The core idea is to use composable events, in F# an event is a first-class citizen + an IObservable (reactive extensions for C#), so we can easily compose functions that in-turn return a set of events or a single event. There is a function Observable.await, which takes in an Observable and also has a state to return.
eventSource
|> Observable.await(fun (t:State.t) e ->
// return the modified state back on every check or in the end
match e with
// start button click
| Choice1Of3(_) ->
{t with start=true}
// stop button click
| Choice2Of3(_) ->
{t with start=false}
// timer tick event,
| Choice3Of3(_) ->
if t.start = true then
handleStockUpdate(t)
else t
) (state)
I just used some of FP terms here, but it should work just fine with normal C# (OO) way of doing things here.
Hope this helps!
-Fahad
I'm not sure why you would use WPF for your front-end if you're drawing using non-WPF elements and require the Invalidate() method that was provided by WinForms? Can't you just switch the UI to use WinForms?