I’ve thrown together a simple game to test a new dev box and the latest Monogame. I’m using VS2013 community and the dev branch of Monogame (downloaded about three weeks ago), and I’ve used the WP8.1 template to create my game.
Every now and then, the game freezes completely, with no exception thrown. This locks the back button too, and the only option is to close the game (or stop debugging when running from VS).
Is this a known issue?
I haven’t encountered this.
I encountered (maybe) the same issue: a complete freeze of the game. But in my case I can unfreeze it by turning the device so that the screen flips, by going to the taskmanager and resuming the game, or by locking and unlocking the phone.
I think the problem lies within
touchCollection = TouchPanel.GetState();
foreach (TouchLocation tl in touchCollection)
{
If I remove these lines, my game won’t freeze. May related topic:
How do you get touch input without this? Or is it the foreach loop?
I won’t get touch input without these, so my problem is not fixed yet.
The test I made was:
Stating the game with these lines of code and simply putting two fingers on the screen where they don’t influence the game. After a while the game freezes.
Then removing these lines (now the game don’t react to touch) and putting my fingers at the same spots. Game won’t freeze.
I’m not sure if this will work, but you could try to lock(…) the collection while you are using it… Are you maybe updating the input state in the foreach loop?
Knowing where we can find those lines would be useful as well
To reproduce the error:
-MonoGame 3.3
-New Monogame WP8.1 project
Add/replace following lines in game1.cs
protected override void Update(GameTime gameTime)
{
// TODO: Add your update logic here
TouchCollection touchCollection = TouchPanel.GetState();
foreach (TouchLocation tl in touchCollection)
{ }
base.Update(gameTime);
}
-Start and play with your fingers on the device. After a while the game will freeze (multi colored block won’t rotate anymore). If you flip your device, lock and unlock, or taskmanger and resume the app, the app will unfreeze.
Thanks, I was running into that issue and figured it was the touch input as well.
Not at my computer, but I imagine wrapping it in a try-catch loop and changing the for each to a for statement should work… it’s just not as pretty looking.
Changing from “foreach” to “for” probably won’t make any difference.
Since my game only need so worry if there’s a touch in progress or not, I just have:
var tc = TouchPanel.GetState();
if (tc.Count > 0) { UpdateStateForTouches(tc[0].Position, millisecondsSinceLastUpdate); }
else { UpdateStateForNoTouches(); }
… and it still freezes.
Going to try wrapping it into a try-catch and hope that this issue is so sporadic that it won’t cause a problem - as opposed to it causing a condition when it happens that input is no longer received at all.
Hate to say it, but with this plus all the other problems I’m beginning to lose confidence with Monogame for trying to build anything production-ready…
Hi Ben,
can you post the whole minimal project?
I’ve tried to reproduce but I haven’t been able to… but I can’t use the WP8.1 template because my monogame installation is a mess right now 
I have encountered this problem too. Has anyone figured out a fix for this issue?
Unfortunately the test solution I put together seemed to behave itself for @KakCAT, so it’s proving difficult to replicate.
For the time being, I’ve stepped back to Windows Phone 8 - partly because of this, but mainly because admob doesn’t support WP8.1, and even if I could get pubcenter working, its fill rate and eCPM leave a lot to be desired… and it also means I don’t have to write platform-specific storage code (IsolatedStorage for iOS/Android,WP8.0 vs whatever the new thing is in WP8.1)
Hi,
I think that I could make it crash.
p.s. I don’t understand how I tested it the first time, because it really is easy to reproduce… Shame on me
EDIT: removed some bits unrelated to this bug to avoid confusion
removed: unrelated to this bug
This can’t be the foreach loop because GetState() returns a new array copy every time.
It has to be GetState(), perhaps a new touch event comes from a different thread while GetState() does some work on the internal list.
I’m having some problems, sorry if a message is duplicated.
I didn’t read the github message, nkast is right, the problem stated is a first chance exception and has nothing to do with this. Unfortunately the freeze persists.
Hi,
the bug does not require TouchPanel.GetStatus to freeze.
I posted a bad quality video here: Basically sets up default spinning cube WP8.1 example, changes to render 5000 cubes , runs, touches and freezes
the 5000 cube loop is because it seems a lot easier to freeze the device when it’s under heavy CPU usage
p.s. the video also shows the bug where the landscape is not applied until several frames after the game starts drawing (it usually takes more time to switch)
I can confirm the new insights by KakCAT. The problem is not the touch but something else.
While under heavy load the game freezes but if you turn the device, use taskmanager or lock unlock it, the game will unfreeze. So I think this is the same bug.
I can replicate the bug. No exception is thrown, the event CompositionTarget.Rendering just stops firing. Pausing the thread shows there are 3 threads, the main thread is in natinvespace while the other two dont run.
Switching to ‘native only’ debugging.
Still no exceptions and tryng to pause execution disconects the device from the debugger. Also geting a lot DX errors that might be irrelevant / seperate issue.
D3D11 WARNING: ID3D11DeviceContext::DrawIndexed: Index buffer has not enough space! [ EXECUTION WARNING #359: DEVICE_DRAW_INDEX_BUFFER_TOO_SMALL]
http://xboxforums.create.msdn.com/forums/t/106599.aspx
One interesting find was that touch events were still firing.
What i think is happening is that CompositionTarget.Rendering is not firing anymore because nothing has changed on the XAML, not sure why this ocurr only when there are touch events and/or heavy load.
Placing a breakpoint in InputEvents.PointerPressed() and calling target.InvalidateArrange() from the intermediate window kickstart CompositionTarget.Rendering again.
(target is the swapChainBackgroundPanel element in XAML)
Then i put target.InvalidateArrange() at the end of InputEvents.PointerPressed() and couldn’t replicate the bug anymore. But this is far from a solution…