[All Versions] Platform::Sleep() not working
by Luke Lamothe · in iTorque 2D · 09/21/2009 (9:57 am) · 8 replies
For some strange reason, the "Platform::Sleep()" implementation in iTGB is commented out to do nothing. *That* is why there is such a huuuuuuuuuuge performance drop when "$pref::iPhone::UsesNetwork" is set to "true". Basically, the networking thread needs to sleep in between polls, and on iPhone in iTGB (but strangely, not iTGE...), the Sleep is set to do nothing.
So, to fix this, just simply remove the "// -Mat Need to fix this " portion of that line so that the function instead looks like the following:
This way, sleeping works fine and you can re-enable networking (for things like TCPObject to talk to game servers, etc.) for basically free :)
So, to fix this, just simply remove the "// -Mat Need to fix this " portion of that line so that the function instead looks like the following:
void Platform::sleep(U32 ms)
{
// note: this will overflow if you want to sleep for more than 49 days. just so ye know.
usleep( ms * 1000 );
}This way, sleeping works fine and you can re-enable networking (for things like TCPObject to talk to game servers, etc.) for basically free :)
#2
09/21/2009 (12:06 pm)
Haha, was that all? Nice, and probably not easy to find :) 
#3
09/21/2009 (12:16 pm)
Good Lord, I wonder what other things there may be lurking in the code that could be holding back the engine's true performance. Imagine we start jumping from 20 to 60 fps with particle effects and 100 sprites - one can dream, no?
#4
09/21/2009 (12:53 pm)
I have animated 200+ sprites with other engines, so let the bughunt start :) 
#5
Ronny: the restriction on that end is the missing batching, missing pooling and the physics.
Actually iTGB goes as far as sending each tile and single particle as a distinct vertex array, forcing the cpu to its knees as the driver will have to handle that mess.
With batching and pooling implemented and the physics replaced, I'm pretty sure that at least double if not even tripple/quadruple the current sprites are possible at the same or higher speed.
09/22/2009 (3:47 pm)
Nice find :)Ronny: the restriction on that end is the missing batching, missing pooling and the physics.
Actually iTGB goes as far as sending each tile and single particle as a distinct vertex array, forcing the cpu to its knees as the driver will have to handle that mess.
With batching and pooling implemented and the physics replaced, I'm pretty sure that at least double if not even tripple/quadruple the current sprites are possible at the same or higher speed.
#8
Sleep shouldn't be used unless you know what you do in detail as unresponsive applications tend to be rejected and sleep halts the whole process leading to exactly that
04/24/2011 (5:56 pm)
The network problem was fixed previouslySleep shouldn't be used unless you know what you do in detail as unresponsive applications tend to be rejected and sleep halts the whole process leading to exactly that
Associate David Montgomery-Blake
David MontgomeryBlake