Cocos2d-x V3 - Tilemap Image Source Path

Cocos2d-x V3 - Tilemap Image Source Path
0.0 0


I upgraded a game I made from Cocos2d-x Version 2.1.4 to 3.0alpha0-pre. It was a lot of work, especially getting rid of the deprecated warnings, but I think the changes are worth it.

In my tmx file, the image source path is relative to the tmx file. I have my tmx and image files for them in the same subfolder. This wasn’t an issue before, but in the new version when it parses the tmx file it looks in the main resource folder for the image instead of looking relative to the tmx file. The only way around this is to move both the tmx files and the image files to the main resource directory. This isn’t ideal for organizing. Manually changing the path doesn’t work either because if I attempt to edit the tmx file with the Tiled editor after, it can’t find the image.

I’m curious if this change is intentional, or an oversight.


[TileMap][cocos2d-x-2.1.4]Error with 3 tile layer and 1 object layer

yes, the image path should be relative to the .tmx path. If not, it is a bug.

Could you open a ticket with the code to reproduce it ? thanks.


I’ve looked all over the site but can’t find any way to open a ticket.

The problem is very easy to reproduce, here is the code:

  map = TMXTiledMap::create("tmx/level1.tmx");

Have a tmx file and the tileset image it uses in a sub-folder under resources, in this case a folder called “tmx”. Within the tmx file:

Unless the file “tileseta.png” is under the main Resources folder you will get an Access violation error.

The error occurs in the file CCTMXLayer.cpp, TMXLayer::initWithTilesetInfo(TMXTilesetInfo tilesetInfo, TMXLayerInfolayerInfo, TMXMapInfo *mapInfo)

The version 3 line:

texture = TextureCache::getInstance()->addImage(tilesetInfo->_sourceImage.c_str());

The version 2 line: (which worked as expected)

texture = CCTextureCache::sharedTextureCache()->addImage(tilesetInfo->m_sSourceImage.c_str());

m_sSourceImage contained the full path to the image file, where _sourceImage only has the file name.

I am happy to open a ticket if you can let me know how, or since it’s pretty straight forward, someone else can.


Daniel Bartley wrote:

I’ve looked all over the site but can’t find any way to open a ticket.

Hi Daniel,
You can find the issue tracker here:



I did go to the issues page previously, and visited it again just now. Maybe I’m blind but I don’t see a link anywhere to create a new issue, only view existing ones. I’ve attached a screenshot of what I am seeing.



Can you go to this page ?


I get 403 - “You are not authorized to access this page.”.


Daniel Bartley wrote:

I get 403 - “You are not authorized to access this page.”.


Could you open the ticket here in the meantime ? Thanks.


Create Issue #3375 on github.


Thanks. Created issue here:


I cann’t reproduce this bug.
I viewed the code in V3 and V2, it do the same thing with the tmx image file path, I cann’t find out where the bug is.
We also use the relative image path with tmx in our cpptest, and it works.
here is the code:
if (_TMXFileName.find_last_of("/") != string::npos) { string dir = _TMXFileName.substr(0, _TMXFileName.find_last_of("/") + 1); externalTilesetFilename = dir + externalTilesetFilename; } else { externalTilesetFilename = _resources + "/" + externalTilesetFilename; }
Could you describe this bug with more detail please? Like which platform you use, and how you write the code, It’s much better if you can provide the demo contain this bug.
Thank you!


I don’t know if the platform matters in this case, but it was win32. When I reported this bug earlier it was with the “samples\Cpp\HelloCpp” project. In this project I just added a folder called “tmx” in the resources folder. The “tmx” folder contained the .tmx and the .png file that was used as the tileset for the tmx.

I took a quick look at the TestCpp project and I see what you mean, the tmx file has a relative reference there and is in a sub folder, so I would expect the problem to show.

Anyway, I don’t have access to Visual Studio 2012 where I am right now but will look at re-creating the bug later tonight and attach the project.


I downloaded a fresh copy of cocos2d-x-3.0alpha0-pre and created a project called TileMapTest using “”. I zipped the class and resource files and attached it here. I tried uploading the whole project but it was too big.

Reproduce the problem:

  1. Create the same project and add these files to it.
  2. Open the proj.win32 solution and run it.

The error will occur. If you move the file tilesettest.png from the tmx folder and put it into the main resource folder the project will run just fine.

I’m not sure if it is windows specific, but it’s easy to reproduce in any case.



I use to create TileMapTest project and put your files in it. It runs well, and I put the tilesettest.png into the main resource folder, it crashed.
I try to find out way you confront this bug but I have no idea.
Sorry I cann’t help you if this bug is not occur in my computer. I think you can try to find out why this bug occurred, If it’s our mistake you can commit a pull request in github. We will appreciate it.
Thank you!


That’s because the system checks the resource root folder instead of current folder of tmx files
Say if your tmx file is under Resources\TMX, the system tries to find images inResources instead of *Resources\TMX

It is a bug and hence the sample test for TileMap failed to run in Win32


Oops, I just posted a reply before seeing your post winipcfg exe. So are you confirming the issue I’m having? I was going to give up on figuring this out as all other versions before 3 work fine for me with the same setup. It seems like I am the only one experiencing the issue with 3.


Sorry my cocos2d-x code is newest from github, maybe is fixed.
I will use 3.0alpha0-pre version later, If this bug occurs, I will find out where the bug is and tell you how to fix it, thank you!


yes, you may check the status of issue (

I think there should be a ASSERT to check whether texture is nullptr in code.
The master version of cocos2d-x now only crash without better information


I found the bug, and it fixed at this commit:

You can check it.