Schedules and Behaviors not working in iPad3 - works in sim and iPhone4.

#1 Try executing the behaviors on your main.cs

#2 For behaviors, I already was.

This of course has no relevance to schedules.

NEITHER work on the new iPad, both work on the iPhone 4 and Simulator with the exact same code.

#3 sure they don't work and that it is not position related handling logic that simply fails absolutely flat? As the new resolution of the ipad3 is the only not natively supported in T2D

Did you make it output a debug output upon startup of the behavior for example to ensure its not bound to input response handling.

I am asking cause resolution stuff can bite ones back yet the scripting side should generally never fail as 3GS+ is ARMV7 cpus, they don't change to exotic stuff.

#4 I have two schedules, a global and an object method. The global one does nothing more than echo a debug statement. The method version does have game logic, but the very first line is also an echo. Both functions show that echo in the console when running in both the iPad and iPhone simulators and on the iPhone4 device. Neither shows any output in the console when running on the iPad3 device.

The behavior also has an echo as the first line in the onUpdate() method. It shows the exact same issue as the schedules.

function Tile::pulseAlpha(%this)
{
	echo("Pulsing alpha");
	%rate = 0.1; // rate of alpha change
	%timer = 50; // milliseconds until the next schedule
	%this.schedule(%timer, "pulseAlpha", 0);
	%glow = %this.glow;
	if (isObject(%glow))
	{
		switch$(%glow.alphaPulseDirection)
		{
			case "up":
				%glow.alpha = %glow.alpha + %rate;
				if (%glow.alpha > 1.0)
				{
					%glow.alpha = 1.0;
					%glow.alphaPulseDirection = "down";
				}
			case "down":
				%glow.alpha = %glow.alpha - %rate;
				if (%glow.alpha < 0.0)
				{
					%glow.alpha = 0.0;
					%glow.alphaPulseDirection = "up";
				}
		}
		%glow.setBlendAlpha(%glow.alpha);
	}
}
function test()
{
	echo("test");
	schedule(10, 0, "test");
}
schedule(3000, 0, test);
// ... code that creates this tile snipped.  It has a Class of "tile"
%tile.schedule(10, "pulseAlpha", 0);

#5 I can test this later today, but my gut is saying the device type should have nothing to do with this. This is usually caused by a change in the iOS or the sdk. Are those factors the same across your testing devices?

#6 Looks to be the same. My project is targeting 5.1, and both my iPhone and iPad are version 5.1(9B176)

#7 @John - Ok, very strange then. I'll investigate this.

#8 I agree, very strange. Anxious to see if you can reproduce the issue or not.

If not, then tonight i'll strip everything down to the barebones and see what is up.

#9 This is very likely something else. The testing I did previously to check compatibility showed no issues with schedules on the new device. While my quick compatibility check wasn't a very deep dive, what I tested it with made extremely heavy use of schedules.

#10 @John - We are going to test this code from your post:

function test()  
{  
    echo("test");  
    schedule(10, 0, "test");  
}  
schedule(3000, 0, test);

We'll let you know how it works out.

#11

Quote:
This is very likely something else. The testing I did previously to check compatibility showed no issues with schedules on the new device. While my quick compatibility check wasn't a very deep dive, what I tested it with made extremely heavy use of schedules.

I am inclined to agree with you. In my case not even the most basic schedule is working, which seems like something that would have been run into before now. I can't be the only one with a new iPad :)

If it is just me, I won't be surprised, but i'll be confused. I can't think of what would cause such an issue, and the only code i've changed is for the retina display.

#12 @John

We just finished testing the code Mich posted in a fresh install of 1.5. The schedule worked on the new iPad as expected on the new iPad. Check to make sure all your scripts are being executed, it's likely something isn't getting loaded for some reason. Also, since you were doing this in a behavior make sure that you've ran the game from the editor after making changes to those scripts before deploying to the device (behaviors run as DSO only on devices).

Let us know if that doesn't help and we can go from there. If it's not one of those two things then it's probably some custom code in your codebase that may be short circuiting something unknowingly.

#13 Well at this point i've completely dumped the behaviors in favor of the schedules. The files must be executing properly or they wouldn't be working on the other devices.

Tonight i'll strip things down to the bare minimum and see what I see.

#14 Try putting that schedule test code snippet in game.cs and see if your results are still the same. If you get the same results with it there then it's most likely something in the retina code change, though nothing obvious is jumping out at me there after going through your resource.

#15 Well i've tried putting the schedule test function in my game's logic CS file, in game.cs and in main.cs. In all cases it works on everything BUT my iPad. All the other script around it works.

:(

I don't know what could be the issue but it looks like I have some work ahead of me.

#16 This is really driving me crazy. I've downloaded and installed a 2nd copy of the stock engine, created a new project, and added the test code to main.cs, and i'm having the same problem. Schedule runs on simulator, not on iPad.

It works for you, doesn't work for me. I'm at a loss.

#17 So i'm starting to wonder if my iPad isn't somehow defective!

I've spent the last few hours stepping through engine code and comparing things between simulator and device (since i'm unfamiliar with "proper" operation) and i've discovered something disturbing.

My iPad apparently exists outside time.

It appears as though the main loop calls DemoGame::processTimeEvent() which in turn calls Sim::advanceTime() which finally calls Sim::advanceToTime()

It is in Sim::advanceToTime() that the even queue is popped and schedules (and presumably other things) run.

When running on the simulator, this series of events happens and I can see the various variables holding the present sim time and the time increases as you go through loops. When it increases to the right time, my schedule gets processed. All as it should.

On my iPad though, time never advances! It stays at 0 sim time the entire time, no matter what!

EDIT: Interesting. inside TimeManager::Process() when run on my iPad the line:

U32 curTime = Platform::getRealMilliseconds();

Always returns max SIGNED INT (2147483647)

Continuing to dig...

#18 Ok so i've fixed the bug. Frankly I don't understand why this wasn't broken for you guys or anyone else, because it was most definitely broken for me :(

In iPhoneTime.mm the function:

/// Gets the time in milliseconds since some epoch. In this case, system start time.
/// Storing milisec in a U32 overflows every 49.71 days
U32 Platform::getRealMilliseconds()
{
   // Duration is a S32 value.
   // if negative, it is in microseconds.
   // if positive, it is in milliseconds.
	
   Duration durTime = mach_absolute_time() * absolute_to_millis;
   U32 ret;
   if( durTime < 0 )
      ret = durTime / -1000;
   else 
      ret = durTime;

   return ret;
}

Was the culprit. Specifically the first line:

Duration durTime =mach_absolute_time() * absolute_to_millis;

This was overflowing every single time and returning garbage. One thing to note is that the time is stored on the platform as a SIGNED integer, so not sure why the engine thinks it can expand that to unsigned, but I digress.

Something about the math, multiplying all on one line was causing it to overflow when run on the iPad. When I broke it into two lines, suddenly everything was working fine.

Duration absTime = mach_absolute_time();
Duration durTime = absTime * absolute_to_millis;

Now my iPad properly advances Sim time and scheduled functions get called properly.

#19 I'll just chime in that I have a mystery bug plaguing my Cavorite apps. The game is reported to get stuck at the opening logo just playing music. The only way I've been able to repeat that symptom is to turn off the schedule(...) call that starts sliding the camera to the menu.

The solution for iOS users has been to power off / on their device. In which case, the game runs without a hitch. I've been scratching my head for awhile about it. I'm starting to wonder if John and I have run into the same bug?

#20 Having a second person confirm it makes me want to write some more in-depth tests. I'll let you two know if I come up with something new.