Ok thanks :)

For vertical speed you mean like jumping or going up right? In that case yes, I have vertical speed half the horizontal speed.

@itlgames
Thank you : )
I'll begin posting youtube videos of the development process soon.

I would like to ask something:
When moving a character in a isometric map, the vertical speed is half the horizontal one?
I'm asking this because as the height of a tile is half of it's width in many cases, it would make sense to give the illusion of depth to make the character has less speed moving vertically, do you agree?

That looks great! Good luck with your game, let us know once is done!

This is a game I've done a long time ago, it was made using Game maker Lol :)

http://www.youtube.com/watch?v=paa_3VBJvFI

It's that kind of game I'll try to develop in Cocos2d.
The tile system can handle this, and using box2d I'm able to handle collision and that sort of things.

Yeah, I've seen that example before, note the character when jumps from behind a block, you see the glitch? To be honest I have spent sooo much time working on the perfect isometric ordering algorithm to realise it's impossible to get something perfect, so it will really depend of your game, where it is noticeable those glitchs or not, and what you can compromise.

In my case was very obvious and I needed something good enough, what I do is, first order all elements assuming all are in same height (or altitude), using the y screen position, then I order by altitude all objects that collide when in same height, that kind of works but it's pretty CPU intensive if you have lot of objects in different altitudes.

See this guy:

http://www.youtube.com/watch?v=fonxgvz35Y4

It seems to work pretty good, but I guess he is using same tile size for all objects, something I wanted to avoid.

For the interaction on my game I didn't use box2d so again had to do from scratch, works fine, to be honest all interaction/physics/collisions... I do is in map coordinates, not screen coordinates, for example all objects are suppose to be enclosed in a 3d rectangle, so they all have a rectangle base, if you project that on a map coordinates, it's all 90 degrees, so it's easy to calculate collision between two rectangles.

@itlgames
Hy there! I've been following your work for some time by now! :) What most impresses me in your game is the interaction of the character with the objects in different height levels :)

About the z sorting using height, i'm thinking on using something like:

[myActor setVertexZ: (-(myActor.position.y))/32];

and with the "myActor" position itself, something like:

myActor.sprite.position.y = myActor.position.y + myActor.fakez;

Do you think it works?

The worst case scenario we can get is using sprites with x much bigger than y (in iso) like the purple block in your example, because it's zdepth center wont be precise in all cases, know what I mean?

For now what I'll try to reach is a game like diablo, something more click 'n kill Lol :) and wont be considering height variation in character movement.

This example really amazed me: http://www.youtube.com/watch?v=Fli3725M7UE&feature=related
I've seen it's possible to use a buffer to access height map of the tiles to simulate character getting in high places, but I don't believe it's gonna be a accessible road for me. I'm a 3d generalist, learned programming not too long ago, so I'm just beginning.

@huika that looks good, I have some experience with isometric games and I can tell that ordering iso tiles/objects all in same level (so no heights) and with same tile size, it's fairly easy. I found the best way is to use the screen y position (not iso map position), so the close to the bottom of the screen, the close to the camera. You can also use the x and y map position (so iso coordinates) but I found the other way more easy.

But if you start using map heights, so objects can be in different altitudes, objects on top of another... that gets tricky, there is no perfect ordering algorithm. On my game, I don't even have all objects with same tile size and that complicates the thing, I can have any sort of sizes, objects in any altitude, objects piled, and it looks nearly perfect, but still there are some situations where it's impossible to do the ordering, like this one, where it is impossible to order:

Here a sample of my working engine:

I have to say I didn't use tile map cocos2d support as I started my game before Riq introduced this featured. Also have to say my ordering algorithm is rather complex, works in mostly all situations, but it has a CPU cost, but still, I can have a few dozen objects on screen with decent fps.

Hi there!
Just wanted to post some tests I've been doing following all the info we can get access from this post.

All those are captures from my iPad, the first two scaling to 0.5 the layer, and the last ones are in 100% scale.

As you can see, the ordering is working very well and is even possible to combine "walls" using this method. Also the performance is really good, considering that all the 100 spheres have box2d physics affected by accelerometer and all the 200 walls ( most are not on screen ) have static colliders.

Hope it's a good new for people still wondering to create isometric games :)
See ya!

Hi there! First I would like to thank everyone, you already helped me a lot with all the posts about isometric tiles and z ordering.

I have 2 questions that I still didn't found an answer:

In my tests I've subclassed a CCLayer and in this subclass I've included an CCSpriteSheet using this in implementation (just posted the important part)

@implementation characterLayer

- (id) init

{

	self = [super init];

	if (self != nil)
	{

		//CGSize winSize = [[CCDirector sharedDirector] winSize];

		// Create a SpriteSheet -- just a big image which is prepared to
        // be carved up into smaller images as needed
        CCSpriteSheet *BastSheet = [CCSpriteSheet spriteSheetWithFile:@"BastRotation.pvr" capacity:20];

        // Add sprite sheet to parent (it won't draw anything itself, but
        // needs to be there so that it's in the rendering pipeline)
        [self addChild:BastSheet];

		// Load sprite frames, which are just a bunch of named rectangle
        // definitions that go along with the image in a sprite sheet
        [[CCSpriteFrameCache sharedSpriteFrameCache] addSpriteFramesWithFile:@"BastRotation.plist"];

		// Finally, create a sprite, using the name of a frame in our frame cache.
        BastSprite = [CCSprite spriteWithSpriteFrameName:@"defend_0.png"];
		//BastSprite.position = ccp(winSize.width/2, winSize.height/2);

        // Add the sprite as a child of the sheet, so that it knows where to get its image data.
        [BastSheet addChild:BastSprite];

		NSMutableArray *walkAnimFrames = [NSMutableArray array];
		for(int i = 0; i <= 7; ++i)
		{
			[walkAnimFrames addObject:[[CCSpriteFrameCache sharedSpriteFrameCache] spriteFrameByName:[NSString stringWithFormat:@"defend_%d.png", i]]];
		}

		CCAnimation *walkAnim = [CCAnimation animationWithName:@"walk" delay:0.1f frames:walkAnimFrames];
		CCAction *walkAction = [CCRepeatForever actionWithAction:[CCAnimate actionWithAnimation:walkAnim restoreOriginalFrame:NO]];
		[BastSprite runAction:walkAction];

	}

	return self;

}

-(void)dealloc
{

	//[[CCSpriteFrameCache sharedSpriteFrameCache] removeUnusedSpriteFrames];
	[super dealloc];
}

@end

after that, in the main gameScene I'm working on, I'm instantiating the new class I've created.
Everything is working fine, I'm being able to use

characterLayer *bastChar = [characterLayer node];
bastChar.position = ccp(0,-100);
[self addChild:bastChar];
[bastChar setVertexZ: (-bastChar.position.y + 80)/32];

Even the Z depth is working, but I would like to ask:
1 - The fact that I'm using the SpriteSheet inside an "CCLayer" subclass, and then instancing this CCLayer subclass is going to break down the performance of one draw call, or I still get this benefit?

2 - using " CCSpriteSheet *BastSheet = [CCSpriteSheet spriteSheetWithFile:@"BastRotation.pvr" capacity:20]; " inside the subclass is going to generate one spriteSheet for each instance of this subclass I create, or all of them are going to reuse the same one?

Thanks a lot for all the help!

I really looked in many topics, but still wasn't abe to get those 2 questions answered.

@riq: Tried your idea of subclassing CCSprite with fresh copies of 0.99.1-rc and r1866 and it works great! Here's the subclass:

@implementation CCZSprite

	-(void) draw
	{
		glEnable(GL_ALPHA_TEST);
		glAlphaFunc(GL_GREATER, 0.0f);

		[super draw];

		glDisable(GL_ALPHA_TEST);
	}

@end

Notes:
* Am no longer calling [[CCDirector sharedDirector] setDepthTest:YES];
* Appropriate foreground layers use cc_vertexz=automatic set in Tiled
* Other background layers get a vertexZ manually like this:

if(![[layer propertyNamed:@"cc_vertexz"] isEqualToString:@"automatic"])
			[layer setVertexZ:-1000.0f + layerCount];

@matsebc: A solution to the edge pixels of your sprites is to create an empty layer in Tiled below everything else. That way the edge pixels are blended with black and it looks ok. You can try playing with the glAlphaFunc(GL_GREATER, 0.0f) value if you don't like black edge pixels.

@matsebc: Are you using a custom alpha test function ? or did you modify the the alpha blend func ? which SVN revision are you using ?

Following Riqs recomendation I am posting a screenshot of the issue I am having, as you can see the character that has a dynamic vertexZ order shows a small hallo of the actual lowest layer around it, I am not sure why the sprite is blending with the lowest layer instead of doing so with the layer right below it, any tips, appreciated!
BTW I am not sure how to embed an image.

Hey guys just to chim in, things are working fine here as well with the settings I managed to recoup from this post, also worth notting that I am getting as well a bottom layer silouette around my hero (and other bugs as well as those are vertexz enabled).
bullets, have you found any solution to that?

@riq: it works!

Will try re-getting the latest codebase (to clean out anything I did), subclassing the draw methods, and post the results.

@riq: Ah yeah, I see what you mean about the semi transparent issue. I have a feeling that you are right about bullets issue. Most likely, he wasn't enabling GL_ALPHA_TEST on his character sprite and thus it wasn't rendering properly with the tiles.

Also, like riq said it probably would be best to subclass CCSprite and override the draw, to include the GL_ALPHA_TEST. That way you can enable GL_ALPHA_TEST only on the sprites / objects / layers that need it.

@Metric: I tried with your solution, but it is not working for the "TMX iso vertexz" example.

This is how it looks following your suggestions:

This is how it looks following your suggestions, but instead of using GL_GREATER=0, it uses GL_GREATER=0.5

This is happening because some tiles (like the trees) have semi-transparent parts.

@bulletsburning: Could you try removing the glBlend() functions from the director.

Instead of this:

// makes vertexZ work {
		glEnable(GL_BLEND);
		glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
		glEnable(GL_ALPHA_TEST);
		glAlphaFunc(GL_GREATER, 0.0f);
		// }

Just add this:

// makes vertexZ work {
		glEnable(GL_ALPHA_TEST);
		glAlphaFunc(GL_GREATER, 0.0f);
		// }

If it works, then I think that I know why it wasn't working for you.
If it doesn't, then I'm totally lost.

Explanation:
GL_ALPHA_TEST was only enabled on the TMXLayer but since your sprite wasn't part of the TMXLayer, it wasn't rendered using GL_ALPHA_TEST. Since you are enabling GL_ALPHA_TEST globally, then everything you draw uses GL_ALPHA_TEST, including your sprite and the tmxlayer.

Possible solutions:
- You could leave the GL_ALPHA_TEST on the director, but this will slow down a little bit your game. GL_TEST_ALPHA should only be used when it is strictly needed (well, at least according the the iPhone guidelines).
- The other alternative is to only draw the images that needs GL_TEST_ALPHA. For example, the HUD doesn't need the GL_TEST_ALPHA. To do so, you can subclass sprite and override draw (see TMXLayer), and also, the TMXLayer#draw should be uncommented.

@bullet: Great! I had a feeling that would work, because that is what eventually worked for me in the IsoTileMapTest project that I created.

@Metric: it works like a charm!

High five to Metric

Interesting note. The edge pixels of the hero character now show the bottom-most TMX layer.

Border pixels showing a few black empty tiles and a bit of sand tiles

I tried messing with the glAphaFunc(GL_GREATER, ...) function's 2nd argument with 0.01f and 0.5f. Kind of made it worse. Then I realized an easy fix: just create a black empty layer as the bottom-most layer. If any pixels "show through" they will just be black. This actually creates a pleasant "cartooney" feel.

Notes:
1. Only change necessary to the app delegate code was: [[CCDirector sharedDirector] setDepthTest:YES];
2. The projection is CCDirectorProjection2D (set after attaching to window). The alpha pixel format can be kTexture2DPixelFormat_RGBA4444 or kTexture2DPixelFormat_RGBA8888.
2. The CCDirector's setDepthTest looks like this:

- (void) setDepthTest: (BOOL) on
{
	if (on) {
		glClearDepthf(1.0f);
		glEnable(GL_DEPTH_TEST);
		glDepthFunc(GL_LEQUAL);

		// makes vertexZ work {
		glEnable(GL_BLEND);
		glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
		glEnable(GL_ALPHA_TEST);
		glAlphaFunc(GL_GREATER, 0.0f);
		// }

		glHint(GL_PERSPECTIVE_CORRECTION_HINT, GL_NICEST);
	} else
		glDisable( GL_DEPTH_TEST );
}

3. The draw method of CCTMXLayer is commented out now.
4. It works beautifully with my existing levels that have around 8 or 9 layers. I just add a bottom black layer.
5. It works fine even for setting the vertexZ of a CCNode-derived Player object which is a child of the CCTMXTiledMap and has a child "hero" sprite and a life-bar sub-sprite which fades in and out. So all of the player's effects are drawn behind or in front of the world at once.

@bullet: could you please try this and see if it does anything different:

remove the following from the draw in CCTMXLayer.m for right now:

if( useAutomaticVertexZ_ ) {
		glEnable(GL_BLEND);
		glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);

		glEnable(GL_ALPHA_TEST);
		if( CCRANDOM_0_1() < 0.2f )
		{
			NSLog(@"Trying %.3f", __f);
			__f = CCRANDOM_0_1();
		}
		glAlphaFunc(GL_GREATER, __f);
	}

Then go into CCDirector.m and go down to the method setDepthTest.

Between glDepthFunc() and glHint() in setDepthTest put:

glEnable(GL_BLEND);
		glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);

                glEnable(GL_ALPHA_TEST);
		glAlphaFunc(GL_GREATER, 0.0f);

Next in your appdelegate where you initialize the cocos2d engine add these in this order or modify your code to have these settings:

`
// Use RGBA_8888 buffers
// Default is: RGB_565 buffers
[[CCDirector sharedDirector] setPixelFormat:kPixelFormatRGBA8888];

// Default texture format for PNG/BMP/TIFF/JPEG/GIF images
// It can be RGBA8888, RGBA4444, RGB5_A1, RGB565
// You can change anytime.
[CCTexture2D setDefaultAlphaPixelFormat:kTexture2DPixelFormat_RGBA8888];

[[CCDirector sharedDirector] setProjection:CCDirectorProjection3D];
[[CCDirector sharedDirector] setDepthBufferFormat:kDepthBuffer24];
[[CCDirector sharedDirector] setDepthTest:YES];

@riq: Can I solve it for now using a custom ALPHA_TEST value? If so, how?

I tried the following code for CCTMXLayer's draw:

static float __f = 0.0f;

-(void) draw
{
	if( useAutomaticVertexZ_ ) {
		glEnable(GL_BLEND);
		glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);

		glEnable(GL_ALPHA_TEST);
		if( CCRANDOM_0_1() < 0.2f )
		{
			NSLog(@"Trying %.3f", __f);
			__f = CCRANDOM_0_1();
		}
		glAlphaFunc(GL_GREATER, __f);
	}

	[super draw];

	if( useAutomaticVertexZ_ )
		glDisable(GL_ALPHA_TEST);
}

It still shows the bottom most layer no matter what the value of glAlphaFunc(GL_GREATER, ...). Also tried setting it to 1.0f, 0.5f, and 0.999f manually.

Screenshot with a bottom most layer like a checkerboard of empty and sand tiles.

Interesting to note it does make some of the edge pixels flicker on the rock layer (the one with cc_vertexz automatic). Does this have anything to do with the format of my PNG files? I'm using 8-bit PNGs exported with Adobe Photoshop CS4's "Save for Web & Devices" command for both the hero and the tilesets. I'm using RGBA_4444 as the Texture2D pixel format.

@metric: alpha blending is enabled by default in cocos2d. The default blend func is GL_ONE, GL_ONE_MINUS_SRC_ALPHA.
If the image is not premultiplied, then it uses GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA.

I guess @bullets has the same issue that can be triggered in example #4: "TMX Ortho Vertex Z" (test/TileMapTest.m)
I tried using forcing GL_SRC_ALPHA,GL_ONE_MINUS_SRC_ALPHA, but I obtained the same results.

The problem seems to be when the tiles have an alpha value between 0 and 1, like 0.5. If the tiles are either 100% opaque or 0% opaque, then it works OK, but if tiles are 50% opaque, then you can trigger this issue.

I solved it using a custom ALPHA_TEST value. It might not be the best solution... I'm rather new with GL_ALPHA_TEST, but it worked for this particular case.

What do you suggest ?

@riq and bullets: It isn't the glAlphaFunc causing the issue, but instead a blending issue of alpha transparency.

If you notice in my TileMapTest project in CCDirector.m under setDepthTest I enable GL_BLEND first and set the glBlendFunc. Basically the following:

glEnable(GL_BLEND);
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);

Then I enable the glAlpha with:

glEnable(GL_ALPHA_TEST);
glAlphaFunc(GL_GREATER, 0.0f);

Enabling both the glBlend with the above and the glAlpha with the above settings fixes the alpha and blending clipping issue when using the depth buffer. Even opengl documents recommend you use glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA) for proper blending of alpha transparencies.

Thus just goto the same file riq mentioned above and add:
glEnable(GL_BLEND);
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);

Before glAlphaFunc / enable.

That should fix the issue, at least it did for me when testing the IsoMap layering with a hero object.

@bullterburning:
Look at CCTMXLayer.m, line #628.

// line 628
		glAlphaFunc(GL_GREATER, 0.0f);

and modify it with:

glAlphaFunc(GL_GREATER, 0.5f);

If it doesn't work, try with different values from 0 to 0.999.
Let me know if it works.

Thanks to @metric and @riq for their work on getting the vertexZ solution rolling. I am running into a transparency issue using r1828.

Whenever my hero character gets close to a tile with cc_vertexz automatic his "transparent" pixels override the correct tile and show the bottom-most TMX layer. Screenshots:

Working ok.

In the above screenshot the hero's vertexZ is -6.44 and the vertexZ of the rock directly above him is -7. There are only two tile layers in the orthogonal TMX, the ground "grass" layer with cc_vertexz -1000 and the rock layer with cc_vertexz automatic. There is an object layer with the player's start position above the rock layer.

Why am I getting this transparency issue?

I've tried it in the simulator, on the device, with different depth buffer bit sizes, using different alpha pixel formats, and using different PNG file bit depths for my hero character, but I always get this transparency issue. By the way, yes, my hero character's sprite is a child of the TMX map object.

I remember @riq saying something about how this wouldn't work with sprites that are not completely opaque. Does this mean we can't use vertexZ with partially transparent sprites? Or is there something I am doing wrong in the code? Please point me in the right direction to solving this.

Note that the pixels that are displayed in the hero's transparent areas are always the bottom-most TMX layer, regardless of cc_vertexz value. For example, if I create one more empty layer below the ground/grass layer it will look like this:

There were a few (but horrible) bugs in the samples. Fixed in r1815

I've also updated the programming guide regarding how to use vertexZ in the maps:
http://www.cocos2d-iphone.org/wiki/doku.php/prog_guide:tiled_maps#z_order_and_depth_buffer

Feel free to correct any syntax/grammar error that you might find. thanks.

@matsebc: no problem. If you have any doubt with TMX, don't hesitate in opening a new thread.

@riq, apologies I wasn't trying to highjack the thread, cheers.

r1808 includes examples that uses both z-order (multiple layers) and vertexZ (uses depth buffer).

According to my tests, everything is working correctly. If something is not working Ok, please post an screenshot of the test, detailing what's wrong with the screenshot.

I'll ignore reports that doesn't have the screenshot with the expected behavior. In this particular case, it's much easier for me to understand a bug report with an screenshot.

@matsebc: I'm not sure what you are trying to do, but it is possible to modify the maps in runtime. Please see the examples. If you have further questions regarding how to do it, please open a new thread. This threads is about how to use z-order correctly.