@riq:
What about using own data types for points and pixels.
CCPixel and CCPoint ?
Don't forget Riq is not going to be around until the 5th of October so don't expect a reply any time before then.
cocos2d v0.99.5-beta3 released
(56 posts) (20 voices)-
Steve Oldmeadow
AdministratorPosted 1 year ago # -
Ah ;-)
@anybody:
What do you think of this idea?Posted 1 year ago # -
I created a separate topic for the CCPixel discussion to get it out of the release thread.
Posted 1 year ago # -
Has anyone done anything with iso maps? It seems my maps are way off after converting them to hi res. Not sure what the issue might be.
Anyone else having problems?
Posted a code example of the bug: (included an attachment with code)
http://code.google.com/p/cocos2d-iphone/issues/detail?id=999My test shows the issues with the ISO system. I didn't test it on other map types, since I don't use them. I tossed together a quick example of the error. It looks like it is similar to all the other pixel / point issues.
Posted 1 year ago # -
Maybe this is a stupid questions, but...
If now we work in Points and I want to develop a game for the Retina Display, how do I make use of the higher resolution?I'm not talking about loading HD images and stuff, I'm talking about exploiting each pixel on the Retina display.
Even if I load HD textures and everything looks very nice, I won't be able to position my sprite at a specific coordinate, because there's a 1:2 relationship between points and pixel. And if I have my sprite and it's moving by one POINT every frame, it will actually move by two PIXELS... what if I don't want that? What if I want my sprite to move as smooth as possible on the Retina? Should I use decimals like 11.5f when specifying points?
I'm not criticizing what has been done here, I'm just trying to understand.
Thx!
MarcoPosted 1 year ago # -
@receptor When in college, when we created a gfx paint program that was display agnostic, we created the display with a 1x1 size. Everything was from 0 to 1 in width and from 0 to 1 in height. so center of the screen would be 0.5, 0.5, and in our case in college, lower left was 0,0 and upper right was 1.0,1.0. What impact would doing things this way be? I really don't see that it would make much difference in the end, except to probably drive some folks nuts as it takes a little getting used to. It really is arbitrary. The problem is that we are used to thinking in concrete terms. When you start using points over pixels, you have to think more abstract, not always the easiest to do.
Posted 1 year ago # -
@sabshire I understand the concept, I just have the feeling that thinking only in terms of POINTS and having a fixed point resolution (480x320) will make people forget that on the Retina display they have maaaany more pixels available which won't be used.
Of course it makes things much easier when it comes to deal with different devices, but you won't be able to exploit higher resolution devices (like the Retina) in a simple way.
Posted 1 year ago # -
Thanks Riq, upgraded one of my games today.
One thing I was pleased to notice was that particle system plists use the points api too and will pick the -hd texture when applicable.
Posted 1 year ago # -
Well, just an FYI.. I was having some major issues with my tilemaps. Calculating the cords of the location the user was clicking on was totally hosed.. After looking through the code I saw that when you call convertToGL it uses points, but then convertToNodeSpace uses pixels, so you want to convert back to pixels before making the call to nodespace.
I made the following 2 macros to convert to and from the points/pixels.:
#define CC_PIXELS_TO_POINTS(__pixels__) \ CGPointMake( (__pixels__).x / CC_CONTENT_SCALE_FACTOR(), (__pixels__).y / CC_CONTENT_SCALE_FACTOR() ) #define CC_POINTS_TO_PIXELS(__pixels__) \ CGPointMake( (__pixels__).x * CC_CONTENT_SCALE_FACTOR(), (__pixels__).y * CC_CONTENT_SCALE_FACTOR() )So if you are doing anything like:
point = [[CCDirector sharedDirector] convertToGL:point]; point = CC_POINTS_TO_PIXELS(point); point = [_tileMap convertToNodeSpace:point];Hopefully that saves a little time for someone.
Posted 1 year ago # -
hello,
It looks like the box2d bodys wont stay in sync with the sprites no mater what... every thing is fine until I enable hd mode and then nothing stays at it place.
Sprites are where it suposed to be, but b2bodyes are not.do you guys have the same problem? do you know how to fix it?
thank you!Posted 1 year ago # -
XPhoenix
MemberWhat I did for my game was to use the same tilemap for the HD one as for the SD one.
My Box2d world is also exactly the same for SD and HD version as I want the gameplay to be the same.What I did do to support HD was to have the CCTMXParser import the HD tilesheet and all sprite coordinates are scaled by ScreenScale.
In my tick method my character and all sprites are also updated as Sprite.Position = b2mult(box2dPosition,ScreenScale);
So for SD versions or games I want to work on Iphone 4 in SD mode, I can set ScreenScale to 1.0f else it will have ScreenScale = 2.0f for iPhone 4 HD Mode.
Not sure if this was the best way to do it, but it worked for me..., as my 2 requirements was not to have to design every tilemap twice (re-use SD) one and also have the possibility of using SD version of iPhone 4.
Posted 1 year ago # -
Thanks for the feedback.
For each feature that is not working correctly, could you open an issue (eg: worldToNode /NodeToWorld? Thanks.
Posted 1 year ago # -
Riq, but in that case - what does working correctly really mean ? Due to the way CCMenuItems are treated there's no error there, although some transformations use CC_CONTENT_SCALE_FACTOR, some don't. Sometimes positions are multiplied by it, sometimes not. Sometimes rect uses points, sometimes it uses pixels... It all sort of works correctly, but only due to some "hacks" that were introduced...
So basically - in your opinion how should it all work ? I think you should set some direction (eg CC_CONTENT_SCALE_FACTOR should not be used unless... or position in pixels should only be used for...) and then we could try to write down what follows this direction and what doesn't
Posted 1 year ago # -
I think what riq said is you report what you think is wrong, and what you are expecting, and from there he can determine if it is a bug, what the bug is, and keep a record of it so it won't slip through the cracks. Managing bug reports in a forum doesn't work too well.
Posted 1 year ago # -
-
Riq - I posted a bug about the tile maps #999.. This issue is the following:
CCNode.c
- (CGPoint)convertTouchToNodeSpace:(UITouch *)touch { CGPoint point = [touch locationInView: [touch view]]; point = [[CCDirector sharedDirector] convertToGL: point]; return [self convertToNodeSpace:point]; } - (CGPoint)convertTouchToNodeSpaceAR:(UITouch *)touch { CGPoint point = [touch locationInView: [touch view]]; point = [[CCDirector sharedDirector] convertToGL: point]; return [self convertToNodeSpaceAR:point]; }convertToNodeSpace uses pixels, and convertToGL returns points. To get them to work correctly you need to use:
- (CGPoint)convertTouchToNodeSpace:(UITouch *)touch { CGPoint point = [touch locationInView: [touch view]]; point = [[CCDirector sharedDirector] convertToGL: point]; return [self convertToNodeSpace:ccp( point.x * CC_CONTENT_SCALE_FACTOR(), point.y * CC_CONTENT_SCALE_FACTOR())]; //point]; } - (CGPoint)convertTouchToNodeSpaceAR:(UITouch *)touch { CGPoint point = [touch locationInView: [touch view]]; point = [[CCDirector sharedDirector] convertToGL: point]; return [self convertToNodeSpaceAR:ccp( point.x * CC_CONTENT_SCALE_FACTOR(), point.y * CC_CONTENT_SCALE_FACTOR())]; }When you make that change they work correctly. Once I discovered that convertToGL was points I was able to compensate for the Nodes.
That fixed my issue for #999 (I have updated the bug to included what I posted here)
Posted 1 year ago # -
-
Ummm, those functions are not used by the cocos2d itself really ;)
Copying other bugfix from previous page:
Currently:
- (CGPoint)convertToNodeSpace:(CGPoint)worldPoint { return CGPointApplyAffineTransform(worldPoint, [self worldToNodeTransform]); }Should become
- (CGPoint)convertToNodeSpace:(CGPoint)worldPoint { return CGPointApplyAffineTransform(ccpMult(worldPoint,CC_CONTENT_SCALE_FACTOR()), [self worldToNodeTransform]); }This will break current implementation of CCMenu which multiplies touchLocation in itemForTouch method by the CC_CONTENT_SCALE_FACTOR(). just remove the line that does so and it will work
---
There's also a possible issue in the [CCMenuItem rect] function:
-(CGRect) rect { return CGRectMake( position_.x - contentSizeInPixels_.width*anchorPoint_.x, position_.y - contentSizeInPixels_.height*anchorPoint_.y, contentSizeInPixels_.width, contentSizeInPixels_.height); }As you can see there's a rather unusual mix of points and pixels multiplication here...
Posted 1 year ago # -
@MikeSz - While they are not specific to something within the Cocos2d engine, they are still implemented within. Therefore it makes them part of the engine, and could be prone to causing issues.
The bigger issue at hand is the different uses between points and pixels. I think things need to be ironed out a little more before making more changes. I know I have had to do a lot of stuff using pixels, just because I couldn't count on the points to be correct. One of those things was the convertGL, and NodeSpace. Being one used points and the other using pixels.
I can honestly say I haven't seen any menu issues, all of my menus work fine in both implementations.
Posted 1 year ago # -
DavidNZ
MemberI'm having strange issues were if I enable the HD mode for retina display my screen will rotate to either portrait or flipped directly. It is set to landscape mode in the applicationDidFinishLaunching delegate.
This hasn't been happening with previous cocos2d versions and also doesn't seem to happen if I don't add in the code for the retina display mode for -hd images etc.
Anyone got any ideas?
Posted 1 year ago # -
I'm still thinking about this
convertToNodeSpace.For example, there are 2 open issues:
- issue #999
- issue #1000They are similar, but the suggest different approaches.
Issue #999 suggest @Verisutha's approach, while issue #1000 suggests the @MikeSz's approach.
I think that
convertToNodeSpaceshould include the conversion.convertTouchToNodeSpaceARis a helper method, and should work correctly, but users that don't use it should be able to obtain the "correct" result too.As I mentioned, I'm still thinking about this, and I'll review the API again, but for the moment I'm going to commit the @MikeSZ's approach.
Posted 1 year ago # -
This is how I'm thinking...
.cocos2d uses the Affine Transform Matrix in pixels. Why ? Because it uses that matrix in OpenGL. No additional transformation are needed.
What can you do with the transform matrix and the inverse one ?
- Basically you can convert a pixel to and from the world space coordinates to the node space coordinates (always in pixels).cocos2d has 2 methods:
a)convertToNodeSpace:(CGPoint)worldPoint
b)convertToWorldSpace:(CGPoint)nodePointAs it is now:
a) Input: Points, Output: Pixels
b) Input: Pixels, Output: PointsShould the Inputs and Outputs be in Points ? Probably... I'll do some tests...
Posted 1 year ago # -
OK, now everything uses Points with the exception of a some inner methods like
nodeToParentTransformandparentToNodeTransformNow the API is simpler. The Menu code is simplified (everything uses Points), and also the TouchTest uses Points, and it seems that everything is working OK.
If you find any issue, please, let me know.
http://github.com/cocos2d/cocos2d-iphone/commit/b6856503d22dbcf01c3b780945a1604f2a27a4e8
Posted 1 year ago #
Reply
You must log in to post.