You can clone with
This issue was already reported once (http://code.google.com/p/sharpdx/issues/detail?id=424) and is reproduceable on a windows phone device, even with a very, simple application, like a single, rotating image drawn on a plane.
If IsFixedTimeStep is set to true, old frames are drawn whenever a draw call is surpressed.
I am not familiar enough with DirectX to identify the bug in the SharpDX code, but I an provide a sample project where the error occours, if needed.
Note that this issue DOES NOT occour with the SharpDX samples, since they do not make use of the Game class.
Please attach the test project where the issue can be reproduced so that I can test is right away.
Btw, there are plenty of Toolkit samples that are using the Game class - take a look at the SharpDXToolkitSamples.sln solution.
It is likely that this issue only regards Windows Phone 8 devices.
You can download the sample project here: http://eex-dev.net/WindowsPhoneSharpDXFixedTimeStepIssue.zip
The issue can be seen if the program runs for a few moments. If you look closely, you can see the rotating arrow jumping back and forth. It can be seen best on a device.
It is also much more observable if bigger or more objects are rendered.
If IsFixedTimeStep is set to false, the issue disappears.
I reproduced the issue on a Lumia 620 and on the WVGA 512MB Emulator.
The issue reproduces both on emulator and on a device (Lumia 920).
I've tried to implement a copy of of previous frame if the current one is suppressed but this didn't help - looks like the WP8 runtime requires to draw a frame every time the callback is invoked.
Curretly, the only workaround is not to use a fixed timestep (set the property to false).
Thank you for your efforts.
I am aware of this workaround, however, it took me a few work days to identify the problem (I first thought my code was faulty).
I would suggest to change the default value of IsFixedTimeStep to false when compiling for Windows Phone, to avoid this problem.
I guess we can set isFixedTimeStep by default to false for all platforms. This is not a huge break, most of the time, people are more annoyed by a fixed time step than the opposite (as you can be called several times on the Update method, unlike when using no fixed time step)
[Toolkit.Game] Changed the default value for Game.IsFixedTimeStep fro…
…m true to false (github issue #160).
Now, the default value is false for fixed timestep on all platforms.