Never seen it. Does it happen right at the beginning?
That means that somehow we've stacked more than 32 touch/accelerometer events in the main thread before processing them in the worked thread.
It sounded like a pretty safe number per frame but maybe events got processed before the app is initialized?
I can make the code more robust in that respect and simply not accepting any events before init and dropping overflowing events after instead of simply asserting.
Yes, it happens when the game is launched. If it's launched from the device (not the Xcode debugger) it exits immediately before any graphics are displayed.
The problem doesn't happen in the "orxTest" bounce app included with orx.
Thanks for making the chance. I will try it this evening when I get home.
Thanks for taking a look. I updated the iPod to iOS 6.0 last night, so now it is same iOS as the simulator.
With the change, the assert no longer fires and the games loads. However, the log fills with the warning messages for about 13 seconds while the game is loading. When everything is finished loading and the title screen shows, the messages stop. Then, when I switch between scenes again (delete all objects and create a lot of new ones) the messages flood for several more seconds until the next scene appears.
If I place a breakpoint in my orxEVENT_TYPE_SYSTEM handler, it isn't reached at all while the flood is happening. This is, I guess, as you said.. the events are stacking up without being processed.
This doesn't happen in the bounce demo, but it loads much faster than my game does, and it seems the problem occurs while loading.
Mmh yep, that would be the accelerometer sending 30 events per second while the main thread is busy.
Those messages are only in debug and you can filter them out if you want to (orxDEBUG_ENABLE_LEVEL is your friend ).
Also, if you don't need the accelerometer, you can simply turn it off by explicitly setting the config property iOS.AccelerometerFrequency to 0. That will also help saving the battery.
Did you use an old version previously?
That couldn't happen before we fixed the thread safety on iOS for touch/accelerometer events, but that was done earlier during this summer.
Comments
That means that somehow we've stacked more than 32 touch/accelerometer events in the main thread before processing them in the worked thread.
It sounded like a pretty safe number per frame but maybe events got processed before the app is initialized?
I can make the code more robust in that respect and simply not accepting any events before init and dropping overflowing events after instead of simply asserting.
The problem doesn't happen in the "orxTest" bounce app included with orx.
Thanks for making the chance. I will try it this evening when I get home.
With the change, the assert no longer fires and the games loads. However, the log fills with the warning messages for about 13 seconds while the game is loading. When everything is finished loading and the title screen shows, the messages stop. Then, when I switch between scenes again (delete all objects and create a lot of new ones) the messages flood for several more seconds until the next scene appears.
If I place a breakpoint in my orxEVENT_TYPE_SYSTEM handler, it isn't reached at all while the flood is happening. This is, I guess, as you said.. the events are stacking up without being processed.
This doesn't happen in the bounce demo, but it loads much faster than my game does, and it seems the problem occurs while loading.
Those messages are only in debug and you can filter them out if you want to (orxDEBUG_ENABLE_LEVEL is your friend
Also, if you don't need the accelerometer, you can simply turn it off by explicitly setting the config property iOS.AccelerometerFrequency to 0. That will also help saving the battery.
Makes sense about the accelerometer events, but why didn't I see it happen until recently?
Did you use an old version previously?
That couldn't happen before we fixed the thread safety on iOS for touch/accelerometer events, but that was done earlier during this summer.
Thanks again for the tip about suppressing the logs and disabling accelerometer.