A fast, easy to use, free, and community supported 2D game engine
Hi,
Finally v0.99.5-beta3 is available for download:
cocos2d-iphone-0.99.5-beta3.tar.gz
Release Notes:
http://www.cocos2d-iphone.org/wiki/doku.php/release_notes:0_99_5
HighLights::
- The API uses Points instead of Pixels (Retina Display friendly)
Full Changelog::
- CHANGELOG
How to create Retina Display Games:
- Programming Guide: Creating Retina Display games
If you find any bug/issue, let us know! Thanks.
Thanks a lot riq :) We were waiting for that ! Merging it with our games now
--
BUG BUG BUG BUG BUG
Anyway, there's something that I think might cause a serious bug in this release, we stumbled across it a few days ago...
Basically - the method that checks for Retina display support is broken
This:
if ([UIScreen instancesRespondToSelector:@selector(scale)])
[director setContentScaleFactor:[[UIScreen mainScreen] scale]];used to be good and fine in iOS 3.2 times, but... It will lead to troubles on iOS 4.2 !
iPad will also respond to this selector... and the scale might be set improperly
We have this problem with current version of Tiki Totems Premium available on the AppStore, and it works like this:
When you run a game on iPad, press the 2x mode, quit the game and turn it on again - the game will load with graphics in HD mode but logic in SD mode. Result - all is broken, touches received in wrong places and general mess. We're not sure why it happens, but we tested it multiple times and it was always leading to the same result. iPad somehow remembers that the game was run at 2x mode, tries to do the same again, game recognizes the display as hi-res
We fixed it (update waiting for review) by adding a simple line that checks the device and if it's iPad - ignores the retina check
I strongly recommend adding this check ASAP
np, we wanted to write about it here anyway ;) just you were first
that's the code we use, with quick anti-ipad-hd fix:
if([[UIScreen mainScreen] respondsToSelector:NSSelectorFromString(@"scale")])
{
if ([[UIScreen mainScreen] scale] == 1.0)
{
// sd device
}
if ([[UIScreen mainScreen] scale] == 2.0)
{
if([[[UIDevice currentDevice] model] compare:@"iPad"] == NSOrderedSame)
{
// iPad ! no retina
}
else
{
// enable retina here
}
}
}Ok, not sure if it is a bug or intended behavior.
We have converted images in one of our spritesheets to HD - works perfectly
Rest of images stayed as SD and unfortunately - they appear at half their size on the screen
Shouldn't SD images in Retina mode be scaled twice ? Or we are responsible with providing each and every asset in both versions ?
ah, ok then :)
another thing I noticed - when doing any intersection checks, it is necessary to use contentSizePixels instead of the old contentSize (when checking the rect). Also when checking touches it's needed to multiply by CC_CONTENTSCALE (not on Mac now, sorry for wrong spelling)
I found both those things in the CCMenu/CCMenuItem classes, but there's no mention of it in the Cocos2d Retina guide. Just think it would be worth adding it there ;)
Other than that - it works beautiful ! Kudos to you :) Took maybe an hour to get from pure SD version to HD, no artifacts at all, and the only changes in code I listed above :)
Great update and almost a painless one, that's the great thing about Cocos2d :)
is there any way to make it so that we can have some -hd and some without the -hd?
In my game, which is universal, i just use the ipad graphics scaled down for iphone. this isn't for all of them but some. I would like to add -hd to only some of the graphics, not all of them.
dafire
Member
there is a major bug in the ccDrawPoints and ccDrawPoly functions when you use content scaling.
void ccDrawPoints( CGPoint *points, NSUInteger numberOfPoints )
...
// convert to pixels
for( NSUInteger i=0; i<numberOfPoints;i++)
points[i] = (CGPoint){ points[i].x * CC_CONTENT_SCALE_FACTOR(), points[i].y * CC_CONTENT_SCALE_FACTOR() };this actually changes the values in your application so with every frame your points will move away :)
Maybe it would be better to define the function as
void ccDrawPoints( const CGPoint *points, NSUInteger numberOfPoints )which will make an error pop up when you try to alter the array.
@ dafire - here it is: http://code.google.com/p/cocos2d-iphone/issues/list
@ riq - will do it tomorrow. never edited wiki before ;) any wiki that is :P have a good weekend :)
@riq: Good job!
I updated my current project to the new beta and nearly everything works now.
I stumbled upon one strange thing with transforms, which I think are buggy:
- (CGPoint)convertToNodeSpace:(CGPoint)worldPoint
{
return CGPointApplyAffineTransform(worldPoint, [self worldToNodeTransform]);
}
- (CGPoint)convertToWorldSpace:(CGPoint)nodePoint
{
CGPoint ret = CGPointApplyAffineTransform(nodePoint, [self nodeToWorldTransform]);
ret = ccpMult( ret, 1/CC_CONTENT_SCALE_FACTOR() );
return ret;
}I think convertToNodeSpace should multiply the value with CC_CONTENT_SCALE_FACTOR()...
I updated also and my game doesn't work in iPhone 4 now. I was using the latest develop branch previously and everything worked. I thought it had to do with convertToWorldSpace but just found out moments ago that it's bounding box that is making my game not behave. This is what I have in my update
CGRect rectPlatform = CGRectZero;
rectPlatform = [platform boundingBox];
rectPlatform.origin = [platform.parent convertToWorldSpace:rectPlatform.origin];
if(rectPlatform.origin.y < -rectPlatform.size.height)
[self resetGamePlatform:platform];
Like I said this worked with the latest develop branch yesterday but today it doesn't. Here are the difference I found in cocos2d source
CURRENT:
- (CGRect) boundingBox
{
CGRect ret = [self boundingBoxInPixels];
return CC_RECT_PIXELS_TO_POINTS( ret );
}
- (CGRect) boundingBoxInPixels
{
CGRect rect = CGRectMake(0, 0, contentSizeInPixels_.width, contentSizeInPixels_.height);
return CGRectApplyAffineTransform(rect, [self nodeToParentTransform]);
}
PREVIOUS(The one that works fore me):
- (CGRect) boundingBox
{
CGRect rect = CGRectMake(0, 0, contentSize_.width, contentSize_.height);
return CGRectApplyAffineTransform(rect, [self nodeToParentTransform]);
}
So I just changed the bounding box back to the previous way and everything works again.
Well done Riq! Keep up the good work.
There's just one issue that we're seeing, and it just appeared today when we upgraded to 0.99.5-beta3 (we upgraded from beta1). At first I thought I was going crazy, and it's definitely hard to nail down the circumstances that trigger this problem. It seems that all our sprites which have multiple frames of animation are getting offset by 10-20 pixels... sometimes? It seems that if flipX == NO then the offset is to the right, and if flipX == YES then the offset is to the left. I think that the size of the offset might have something to do with the width of the frame.
Is anyone else seeing this issue? We're using Zwoptex-generated spritesheets. It's possible that our (by now quite byzantine) character display code has had a bug all along, I suppose, and that beta3 has just exposed it. But it's such a bizarre problem that I thought I'd check with everyone else first.
Great release @riq look forward to final release.
Will switch to this for next project, we made our own hack for retina and iPad.
We use retina GFX for iPad ghowever our backgrounds are full screen so they required additional iPad only GFX for the universal binary.
Points by default sounds good, we originally made our app for 480x320 then needed to add Retina support followed soon after by iPad. So we applied a scaler hack to all co-ords based upon Current Device H,W / iPhone 3G H,W
I agree the scaleContentFactor should be set to 1 for iPad.
When scaleContentFactor=2 emulation is added to cocos2D (see this http://www.cocos2d-iphone.org/forum/topic/8511/page/7 ), you should activate it on iPad (that will display HD graphics in x2 mode (also in x1 mode but you will not see the difference in this mode)).
Hmmm was making some checks and I think odinseye is absolutely right...
- (CGPoint)convertToNodeSpace:(CGPoint)worldPoint
{
return CGPointApplyAffineTransform(ccpMult(worldPoint,CC_CONTENT_SCALE_FACTOR()), [self worldToNodeTransform]);
}looks to be a better choice than current implementation which ignores CC_CONTENT_SCALE_FACTOR()... it would also be more logical as convertToWorldSpace uses it
of course this requires making some changes in the rest of cocos2d, for example in the CCMenu code - lines that multiply x and y of the touch by CC_CONTENT_SCALE_FACTOR() need to be removed
I have tested it and it works for menu and for my own intersection method (which is based 100% on the menu item intersection method)
not sure about boundingBox as we don't use it for anything atm
hmmm
well, the problem is that now some parts of the cocos2d use points, some other pixels, sometimes you see multiplication by CC_CONTENT_SCALE_FACTOR(), sometimes you dont although you'd expect it...
I played around and tried to remove CC_CONTENT_SCALE_FACTOR() from collision and conversion as much as I could, but the outcome is that I still have to use it here, but cant use it there. sometimes only bottom-left quarter of a sprite would react to touches... then I know that this specific thing needs to use contentSizeInPixels :/
overall what works for me (cocos2d classes, not my custom ones):
CC_NODE:
- (CGPoint)convertToNodeSpace:(CGPoint)worldPoint
{
return CGPointApplyAffineTransform(ccpMult(worldPoint,CC_CONTENT_SCALE_FACTOR()), [self worldToNodeTransform]);
}CCMenu - removed the lines that multiply touch lcoation by scale factor
I think that since cocos2d now should use points, then references to contentSizeInPixels should not appear in any of the [rect] or [bounding box] methods. also the CC_CONTENT_SCALE_FACTOR really shouldnt exist in CCNode transformations ?
Dunno really, need to experiment a bit, will try today or tomorrow
The CC_CONTENT_SCALE_FACTOR thing is really cool since it simplifies delvelopment but I think the main gloal for the next beta should be to get the complete API back into a consistent state.
Most functions I use work for me because I do collision detection with Box2D and most parts of my game work in meters (Box2D units).
well, from what I understand "API uses Points instead of Pixels", it's written right there as the most important part of this update
However, that's not the case in many, many cases...
If I understand riq's intentions correctly, pixel sizes should only matter when you want to access some very specific data (eg accessing a specific pixel), but not for transformations, not for colission detection etc etc. For those points should be used
Am I correct ?
@MikeSz thats right. But currently its not as "clean" as it should be.
@all:
- (CGPoint)convertToNodeSpace:(CGPoint)worldPoint
{
return CGPointApplyAffineTransform(ccpMult(worldPoint,CC_CONTENT_SCALE_FACTOR()), [self worldToNodeTransform]);
}is a good start put the problems go on. It also has effects on
- (CGPoint)convertToNodeSpaceAR:(CGPoint)worldPoint
{
CGPoint nodePoint = [self convertToNodeSpace:worldPoint];
return ccpSub(nodePoint, anchorPointInPixels_);
}what should be
- (CGPoint)convertToNodeSpaceAR:(CGPoint)worldPoint
{
CGPoint nodePoint = [self convertToNodeSpace:worldPoint];
return ccpSub(nodePoint, ccpMult(anchorPointInPixels_,CC_CONTENT_SCALE_FACTOR()));
}And
- (CGPoint)convertToWorldSpaceAR:(CGPoint)nodePoint
{
nodePoint = ccpAdd(nodePoint, ccpMult(anchorPointInPixels_,1.0f/CC_CONTENT_SCALE_FACTOR()));
return [self convertToWorldSpace:nodePoint];
}
- (CGPoint)convertTouchToNodeSpace:(UITouch *)touch
{
CGPoint point = [touch locationInView: [touch view]];
point = [[CCDirector sharedDirector] convertToGL: ccpMult(anchorPointInPixels_,1.0f/CC_CONTENT_SCALE_FACTOR())];
return CGPointApplyAffineTransform(point, [self worldToNodeTransform]);
}
- (CGPoint)convertTouchToNodeSpaceAR:(UITouch *)touch
{
CGPoint point = [touch locationInView: [touch view]];
point = [[CCDirector sharedDirector] convertToGL: point];
point = ccpAdd(point, ccpMult(anchorPointInPixels_,1.0f/CC_CONTENT_SCALE_FACTOR()));
return CGPointApplyAffineTransform(point, [self worldToNodeTransform]);
}They get even more complicated since convertToGL works in points and with the current version everything would be converted again....
@riq:
What about using own data types for points and pixels.
CCPixel and CCPoint ?
The advantage would be that the compiler warns if somebody mixed both types. You will have to explicitly use a function to transfer one into the other.
You must log in to post.
