Title says it all - am working on that dungeoneer demo and have it happily working and moving and what-not, but I noticed that if I change app in iOS and then come back to it, the OS zooms up the last shown screen correctly but then it goes black.
I know the game is still working however, because if I tap where one of the buttons is, the screen redraws and all is well in the world again.
This is probably an invalidation bug. Corona doesn’t think it needs to redraw, when it actually does.
Are you referring to snapshots? In the game where this happens I’m not using them 
This is probably an invalidation bug. Corona doesn’t think it needs to redraw, when it actually does.
Are you referring to snapshots? In the game where this happens I’m not using them
We have made several internal changes to the rendering code and I’m working to reproduce your case. Do you have sample code you could share?
I’ll download the latest daily build over the weekend and see if it still happens. If it does, I’ll see what I can come up with (but obviously the project itself is now quite large).
Thanks! Just a simple test case will work for us.
Yeah see that’s the problem, there’s no guarantee I can afford the time to hack out everything to narrow it down.
I still get this, but I must admit I have to force it.
For example, on android, I have snapshots nested in snapshots, and the inner ones don’t get refreshed (but I’m happy to accept this is something I’d need to do manually, unless there could be some way of specifying the update order of snapshots?
For example what I do now is:
Update the inner snapshots
Wait a frame
Update the top level snapshot
What would be nice is to be able to specify what order they draw in, as if I am sure the inner snapshots update first, I could update the top level snapshot in the same frame, secure in the knowledge it was done last.
Off the top of my head then, here’s a suggestion:
snapshot.renderPriority = <integer>
Where they render in order from lowest to highest.
So I could set the container snapshot to a priority of 1, and the inner ones to 2 so they all get updated first. Might as well make it count up for order instead of down, as you’d then have an unlimited system (rather than the opposite way, where 1 or 0 would be a logical ‘limit’).
We have made several internal changes to the rendering code and I’m working to reproduce your case. Do you have sample code you could share?
I’ll download the latest daily build over the weekend and see if it still happens. If it does, I’ll see what I can come up with (but obviously the project itself is now quite large).
Thanks! Just a simple test case will work for us.
Yeah see that’s the problem, there’s no guarantee I can afford the time to hack out everything to narrow it down.
I still get this, but I must admit I have to force it.
For example, on android, I have snapshots nested in snapshots, and the inner ones don’t get refreshed (but I’m happy to accept this is something I’d need to do manually, unless there could be some way of specifying the update order of snapshots?
For example what I do now is:
Update the inner snapshots
Wait a frame
Update the top level snapshot
What would be nice is to be able to specify what order they draw in, as if I am sure the inner snapshots update first, I could update the top level snapshot in the same frame, secure in the knowledge it was done last.
Off the top of my head then, here’s a suggestion:
snapshot.renderPriority = <integer>
Where they render in order from lowest to highest.
So I could set the container snapshot to a priority of 1, and the inner ones to 2 so they all get updated first. Might as well make it count up for order instead of down, as you’d then have an unlimited system (rather than the opposite way, where 1 or 0 would be a logical ‘limit’).