iTorque 2d 1.5.1 Release??

#61 I have no idea why it multi-posted my post!

#62 When can we expect to see all those amazing performance improvements?

#63 @Scott - I guess that's the big decision I'm facing now that I'm back from paternity leave (which was 2 weeks, btw). A considerable amount of work got done while I was out. I'm trying to decide if we put out a preview with a few bug fixes and light QA, or if we aim higher and get the really amazing stuff + bug fixes in a release.

I have to get approval either way, so I'm writing up those e-mails.

#64 There are some things that would be really nice to get a hold of sooner rather than later, even if its in the form of a resource.

The two big elephants in the room I think are iPad Retina and root view controller. Both are major issues for anyone using 1.5

Essentially stock 1.5 won't work on a new iPad if built with XCode 4.3, which I think is a requirement for app submission. Updating the engine to properly handle the new display fixes the bug, and only took me a few hours so a resource could probably get others through this.

Root view controller is a bit harder to fix I think. I have tried twice and each time I do I totally break my app :p I don't know if Apple has started denying apps based on this but I imagine it would happen anytime now.

#65 @John - The iPad retina fix can be a resource, but the root view issue needs to be apart of an actual build. It's a new Xcode project and new sources. I'll see what we can do to push a preview build out with just those changes to unblock people from submission.

#66 Michael, I think the important bug fixes must take a higher priority, especially as the performance changes will probably break backwards compatibility?

Can you not branch 1.5.1 and release/bug fix and put out a preview of 1.6?

#67 I agree. I need the compatibility fixes to be available soon, as it's getting harder and harder to work around them on projects. While I am pretty excited about the new features, I can wait for those.

#68 I also agree that performance isn't critical at this point, so a minor update with the root view controller (fixing orientation issues) and New iPad retina support would be great, as these are currently blockers for release.

#69

I agree. I need the compatibility fixes to be available soon, as it's getting harder and harder to work around them on projects. While I am pretty excited about the new features, I can wait for those.

^^ i second that!

#70 I just posted this in the bug report thread for the new iPad touch issue:


I can go ahead and tell you the exact area of code that the touch offset is busted. This might help you get further along until I can push 1.5.1 out:

1. in platformiPhone/iPhoneOGLVideo.mm, go to line 366:

iPhone4 = false;
    if([[UIScreen mainScreen] respondsToSelector:@selector(scale)] && [[UIScreen mainScreen] scale] == 2)
        iPhone4 = true;

As you can see, the previous assumption was that if retina is disabled, then the device is an iPhone 4. Well, my assumption has backfired (like all assumptions do). Still, that's not the main problem. Detecting if the device supports retina is important, but now there are two devices (iPhone 4 and new iPad).

The real problem is located in the same source file, at line 482:

ConvertToIPhone4(&point, platState.portrait);

That function will changes the touch offset:

void ConvertToIPhone4 (CGPoint *p, bool portrait)
{
    p->x *= 2;
    
    if(portrait)
        p->y = ((p->y - 480) * 2);
    else
        p->y = ((p->y - 320) * 2);
}

Doh! The code assumes that if retina is on, it must be an iPhone 4, so make use of values related to the iPhone resolutions (480, 320, 960, 640). While I have not coded it out fully, since there are several other areas where assumptions are made about retina, the basic idea for a fix would be this:

S32 landscapeResolution;
S32 portraitResolution;

// This can be either 480 or 1024
landscapeResolution = currentDeviceWidth;

// This can be either 320 or 768
portraitResolution = currentDeviceHeight;

void ConvertToIPhone4 (CGPoint *p, bool portrait)
{
    p->x *= 2;
    
    if(portrait)
        p->y = ((p->y - landscapeResolution) * 2);
    else
        p->y = ((p->y - portraitResolution) * 2);
}

I know the above code is incomplete, but you see where I'm going with it. We know we can detect the device type (iPhone or iPad) and whether it has retina enabled. It's just a matter of setting landscapeResolution and portraitResolution to the appropriate values. Again, there are other areas of the code I need to check, but that is where I will start.

#71 I have a preview build ready for a brief QA session. Our internal cycle will be extremely short, so I thought I would let a few of you get hands on before we post it publicly. First five people to reply to this post will get the build delivered before it is posted on the site.

#72 ME ME ME ME ME ME ME ME ME ME ME ME ME ME ME ME ME ME!!!

#73 @michael - this preview build is just bug fixes?

#74 @Johnny - Yes, specifically supporting the new iPad and addressing the root UIView issue.

#75 Me please

#76 booya!

#77 Me? Or am I late to the party?

#78 can you squeeze in one more :)

#79 @Joe - You're in.

#80 @George - You got it.

@All - Ok, that's it for the list. If these guys report back with positive results, we can roll out the preview publicly.