RetinaDisplay on Windows

I am using cocos2d-x to develop on Windows. I have plans to write for the iOS and to simulate that, I set the window size to: 320x480.

When I enable retina display using:
director~~>enableRetinaDisplay;
The window size adjusts to a larger size: 640x960.
The correct assets are also used. I’m not sure if this is how retina display works on the iPhone simulator for mac developers.
My main problem is that I am loading data from a .tmx file. It loads the following coordinates for a sprite from my~~hd .tmx file: (800, 160).
I assume this is correct because the window size is adjusted to (960x640), note: it is set to portrait mode.

However, the sprite does not appear on screen, so I debug by hardcoding the coordinates to:
ccp(size.width/2, size.height/2)

The sprite shows up in the center, the window size is (960x640), but the log shows that the sprite was placed at: (240, 160). Which means that director~~>getSize is actually: .
So now, I correct the position by hard-coding it to: .

Can someone please explain this for me and let me know how I can resolve this issue? If I change the window resolution to 960x640: win~~>Create(TEXT (“Title”), 640, 960);
The director will give me those values, but the window will be twice as large (because retina is enabled to use the HD graphics). If I disable retina display with this window size, it will load the SD graphics instead of the HD graphics, which isn’t correct because they are scaled for 320x480.

Yep, it’s the rule of cocos2d retina system. You may pay attention to the difference between CCSprite::setPosition & CCSprite::setPositionInPixel.
Ricardo Quesada describe the design here http://www.cocos2d-iphone.org/wiki/doku.php/prog_guide:how_to_develop_retinadisplay_games_in_cocos2d?s[]=retina

Walzer Wang, so just to clarify this would be a particular case when I should use setPositionInPixel, correct?

Right now I have my -hd .tmx file, which works correctly for retina display as well as non-retina display as long as I divide the coordinate values by two.

What I don’t really follow is that they are saying to have two versions of your map file, but it seems like you only need one version. Perhaps that guide should be updated because I am using points, and I am sure that most people should be using points. Having two map files not only takes more effort, it is also unnecessary.

I think that tmx files are the exception to two map file versions, it is unnecessary and is actually wrong (as long as you’re loading the positions in points and not pixels). Graphics should have SD and HD versions but map files should have only 1 version. Correct me if I am wrong.

Nope. The recommended approach is to use point in both retina & HVGA version.
At first you’re in a HVGA resolution, the center of screen is ccp(240,160), in the unit of point.
Then you run this code in retina display, it’s still ccp(240,160) in point, and the engine will automatically change it into (480,320) pixel and load resource with -hd sufbix, all is done in engine internal, not in your code.

Okay, so let’s say you have two map files with an object at position: ccp(240,160).
So you have two map files, pixels (240, 160) and (480, 320)

If you load the object properties:
map = CCTMXTiledMap::tiledMapWithTMXFile(name);
CCTMXObjectGroup* objects= map~~>objectGroupNamed;
float x = objects~~>getObjects()->getObjectAtIndex(0)->objectForKey(“x”)>toFloat;
float y = objects
>getObjects()>getObjectAtIndex>objectForKey~~>toFloat;
Object* s = new Object;
s~~>autorelease;
s~~>setPosition);
this~~>addChild(s);

You said don’t use setPositionPixel();
If I have two map files and I don’t use that, it’ll set the position at (480,320) point for HD. So that’s why I only use one map right now (SD map). I have a working system that uses only one map for SD and HD, so I still don’t get why you need an SD map and an HD map. The retina system uses point and SD and HD have the same resolution.

So why does the article say to make two maps and upscale the second map? If I upscale and use an HD map, it will position the object at (480,320) points, which is wrong. (480,320) pixels is correct, but we’re using points. And if we’re using points, why do you need another map to figure that out?