Skyhawk
When I run my program with HKTMX all I see is black and white lines.
HKTMXTiledMap
(180 posts) (32 voices)-
skyhawk
Member@Dani: I can say with 99% confidence it will not work with cocos2.0. That being said, as I have no plans in the immediate future (My current game engine is very 1.0 bound), If you would like to do a test / experimentation, I'd be delighted to know the results.
Also to answer @Yann: not entirely sure how I would implement it, but I suspect it would just be testing for said bits in showtile, then around line 448 in HKTMXTiledLayer where we set up the texture vertices, do the proper vertex ordering... I believe. slycrel could confirm or deny.
Posted 4 months ago # -
-
I think that re-ordering the vertices may indeed get you what you want. I'm a n00b as far as the low level OpenGL stuff so I'm not sure I could code it. But it's as simple as flipping the X axis or y axis. (I think we set flipX and flipY on the sprite to do this in the regular class)
Posted 4 months ago # -
The bits part is pretty easy. You don't even have to know how it works, just use it. =)
However, since I hate not knowing (and it was semi-painful to learn), here's a quick bits lesson that pertains to this code.
If you look in the regular code you will see 3 #defines for the bit flipping.
#define kFlippedHorizontallyFlag 0x80000000 #define kFlippedVerticallyFlag 0x40000000 #define kFlippedMask ~(kFlippedHorizontallyFlag|kFlippedVerticallyFlag)- Open up apple's calculator and go into the programmer mode.
- Click on the "16" in the upper right of the window. This will allow you to enter hex numbers.
- Type 0x80000000
The area just below the format shows the bits that are set with any given number. In this case we are looking at an unsigned 32 bit integer, so the top row is ignored. (a double or a long int would show bits there) Notice that with the number we've typed there is a 1 in the leftmost position. This is the "flip this tile horizontally" bit.
- Clear that and type 0x40000000.
Notice that the second position from the end on that same row now has a 1. This is the "flip this tile vertically" bit.
- If you add these together you will see a one in the first two bits of this row and zeroes in the rest. Easy enough, these are our two flip bits.The mask is a bit more work. Up above in the #defines, the bar character represents an "or" operation, which essentially adds those two values just like we did on the calculator (to get 0xC0000000). That's fine, but to strip those bits off of any given GID we want the opposite of that, which is two zeroes in those slots, and all ones in the other slots. This works out to be 0x3FFFFFFF. The ~ operator is a bitwise not, or in other words, it reverses the 1's to 0's and the 0's to 1's. In this case turning 0xC0000000 into 0x3FFFFFFF.
Now to use this mask we want to use the bitwise and operator, &. So if a tile is flipped on it's X or Y axis then our GID representing it will be really big. To get that back to the actual number we want to mask off those two extra bits by doing something like this:
realGID = gid & kFlippedMask;This will mask off the did variable (or clear) the zeroed bits of the mask we are anding with it, giving us the real GID number that maps to our atlas.
Clear as mud I expect, any clarification by the gurus out there that know this better than I are welcome to chime in. =) But that's the general idea... and what you'd be dealign with for the flipped tiles. Also the rotation bit that has been added for rotation in Tiled 0.8 is the next bit in from the left, if someone is feeling ambitious. =)
Hope that helps some.
Posted 4 months ago # -
@skyhawk
So I am trying to adapt your code to handle the flipped tilles. But I have no success yet because I don't understand everything for know, but... well I am working on it. But I have a different question : how can I change the texture pixel format because my tiles looks really ugly with HKTMXTiledMap... And I can't find what code is changing that in your files ? :(Thanks !
Posted 3 months ago # -
skyhawk
Member@Yann the texture is loaded via CCTextureCache. I do nothing but bind with that. If you're talking about the filtering, that's all done on 370-374. Most notably, I use nearest neighbor, and if your tilemap is not 1x1 pixel mapped to the screen's pixels, then you might want to not use nearest neighbor for best result.
As far as the flipping, I was going to implement it, but then I found a bug in the latest CCTMXTiledMap (due to flipping). @slycrel fixed that up, but I haven't found free time to invest more into it. should be trivial though.
Posted 3 months ago # -
@skyhawk
Thanks I will take a look at those lines !For the flipping — and after a lot of hours — I finally made it !... but I skipped all your animation/cache code XD Because I am not using it and I wasn't able to detect flipped tiles with showTiles, so I replaced it with the original *tiles_[].
If you want the code to make the bridge with your animation things, tell me :)Anyway, the performances of my game are way much better now.
Edit :
For the graphics the problem is that the borders are not "clean", I have little spaces between plain tiles, and tiles with transparent edges have lines borders (the start of the next tile). Also note that I have no issues like that with the original CCTMXTiledMap and I haven't changed the TMX file.Posted 3 months ago # -
@skyhawk
I am currently testing the stability of HKTMXTiledMap and I have got a strange issue, when I am loading another scene — sometimes — I get strange random crashes with the sharedspriteframecache... Is this the problem you had, or have experienced it ? —— EDIT FIXED : Some other code from me was buggy, sorry ——For the gfx, I haven't been able to fix it for now, but I am working on it : The problems with gaps and lines is over, I only have to change something like the pixel format to make the transparent borders really transparent, but I haven't found how to do it in opengl directly :)
Posted 3 months ago # -
I'm seeing these line artifacts also. Which is a bummer considering the massive benefits over the normal class (which didn't have artifacts).
Its pretty much the same as the artifact issue commonly discussed around here which affected CCTMX, but my attempts to fix it in the same ways have actually produced more pronounced artifacts. CC_FIX_ARTIFACTS_BY_STRECHING_TEXEL 1, the artifact fixer etc don't seem to help. Any ideas @Yann?
Posted 3 months ago # -
@Scottapotamas
HI Scott,
To get those lines away I did that:
1. In draw method of HKTMXLayer be sure to have those textparams : ccTexParams texParams = {GL_NEAREST, GL_NEAREST, GL_CLAMP_TO_EDGE,GL_CLAMP_TO_EDGE};
2. Do not use PVR.CCZ files which are buggy (for now). Instead use a png file.
3. If you use a parallax/ccfollow, be sure that your x and y axis will always return an interger and not a float.If those advices do not help... well I can't say more, because now it's working properly for me this way.
Posted 3 months ago # -
@Yann
Thanks, I checked the texParams. They were already set like that, I'm not using pvr's, and Im not sure if scrolling by an int will look right (generic box2d based platformer)...
I originally thought it may have been caused by a POT issue with the tilemap. But after trying it I can see that having rectangular tilemaps only exacerbates the artifacts, it didn't remove them. Any other ideas anyone?
Posted 3 months ago # -
skyhawk
Membergithub has been updated with @LordKrodd's changes (plus bug fix to his code regarding animation)
If you don't use cocos 1.1, don't use flipping.
If you do use cocos 1.1, flip to your heart's content.I played around with the tileAt addition you added, but to me it seems like the appropriate way to use it (as if normal) would be to call tileAt: ccp(x,y), then set the gid at that location to 0, add the sprite to the layer, then do whatever to the sprite you have. it's kinda awkward cause it's not REALLY the tile, but a facsimile of it. It also doesn't respect flippedness.
Still, marvelous addition.
Posted 3 months ago # -
LordKrodd
MemberGood find on the animation bug, completely missed it.
Any idea why it only works with cocos 1.1, i had assumed the changes where independent of cocos code?Regarding tileAt: is it simply returning the texture form the spritesheet not the map itself.
In my code I simply wanted to read the data for collision detecting, not try and modify it.I agree it needs flipping support added.
I think it needs a setTileAt: to clear the gid and added the sprite to the layer.
These modified tiles would be out of the control of HKTMX and thus add a performance hit.
It would obviously be better to simply switch tiles from the spritesheet using setTileGID:I'll also add a functions to get and set the flip bits of a tile location, as tileGIDAt and setTileGID should only handle setting the GID.
I start having a look today.
Posted 3 months ago # -
Questor
MemberskyHawk,
Nice work. I was also seeing the vertical line issue, but with the latest code it seems to be gone, but I am guessing that that is probably a total coincidence...
Anyway, I was curious if you had looked at the cocos2d fix in 0.99.5 beta 2 regarding the vertical line fix by CJ that was added to the cocos core at that time?
Here is link to the primary change:
https://github.com/cocos2d/cocos2d-iphone/commit/233668a496b167c5284dba2b37749d30f26f8097#L3R446Not sure if you're code is already calling CCSprite's updateTextureCoords (I don't see it called explicitly but it is possible it is getting called behind the scenes implicitly). In any case, if it is not getting called, then calling it (or some reasonable facsimile) might just do the trick.
I was planning to take a look at it myself, but it may not be for a while (or at least until it pops back up in my app with enough consistency so that I can reproduce it reliably). Anyway, I just thought I'd point it out in case you or others with more time (and a consistently problematic map) want to take a shot at it.
Hope this helps.
Cheers,
QPosted 3 months ago # -
-
zmeinaz
MemberFigured out part of the problem. I need a way to zoom the map out and make the whole thing visible so I changed initWithTilesetInfo from
screenGridSize_.width = (ceil(screenSize.width / mapTileSize_.width)*2) + 1;
screenGridSize_.height = (ceil(screenSize.height / mapTileSize_.height)*2) + 1;to
screenGridSize_.width = mapTileSize_.width;
screenGridSize_.height = mapTileSize_.height;which draws the whole tile map of all layers all the time (performance still seems better than CCTMXTiledMap). One I get past a certain map size the tiles seem to stop drawing correctly and seem to show up as other random GID's. Are there any known map size limits? I am using a 200x75 tile map with 80x80 tiles.
I was using this same setup with CCTMXTiledMap with no problems aside from some performance issues on the first gen iPad (frame rate is about half of what it is on iphone4 and 4s) I was hoping HKTMXTileMaps would help with the lower frame rate on older devices.
Posted 3 months ago # -
skyhawk
Member1) eliminating the screensize limitation defeats half the point of this. You might as well just use CCTMXTiledMap.
As far as zoom, I'm sure you can think of a way that doesn't involve drawing the whole map. =)2) Unsure of any limitations other than memory. I just did a 170x100 map of 64x64s with nary an issue.
Posted 3 months ago # -
LordKrodd
MemberHi All
Very sorry, but zmeinaz post about zooming has made me realised that I left support in for 2x zoom-out from my game
screenGridSize_.width = (ceil(screenSize.width / mapTileSize_.width)*2) + 1;
screenGridSize_.height = (ceil(screenSize.height / mapTileSize_.height)*2) + 1;The above should not have the *2.
It will obviously have performance hit on anyone using it.I'll resend you my recent changes and include a define for zoom support.
Sorry again.
Posted 3 months ago #
Reply »
You must log in to post.