TMXLayer scrolling glitch

[JRam13]

Hi there, it's me again. It appears that I've stumbled across a similar glitch, but this time it happens when scrolling a TMXLayer. By the way, I am using your current build this time.

It seems that the problem is line 698. The culling goes away by setting tile.hidden = NO. I don't understand why tile.hidden is set to YES, since sprite-kit automatically removes those tiles when they are off-screen to save memory (you can tell that nodes disappear once they go offscreen). This leads me to believe that there are no memory leaks by setting tile.hidden to NO, so we should be safe in that regard.

I updated the sample project so you can see this bug in action.

https://github.com/JRam13/JSGlitch

[JRam13]

This isn't a bug, I just wanted your general thoughts on this matter-

When moving TMXLayer's around, the fps seems to drop like a rock (even with tile.hidden=YES). I'm not able to scroll 3 layers simultaneously without a considerable drop in fps. It works ok when I don't use the layers and use skspritenode's instead. Probably something I have to reconsider doing.

[davecom]

A tmxlayer incorporates a separate sprite for every tile. Perhaps it's the effect of moving all of those sprites at once?

Sent from my iPhone

On Aug 4, 2014, at 11:26 AM, Jonny Ramos notifications@github.com wrote:

This isn't a bug, I just wanted your general thoughts on this matter-

When moving TMXLayer's around, the fps seems to drop like a rock (even with tile.hidden=YES). I'm not able to scroll 3 layers simultaneously without a considerable drop in fps. It works ok when I don't use the layers and use skspritenode's instead. Probably something I have to reconsider doing.

— Reply to this email directly or view it on GitHub.

[slycrel]

@JRam13 can you try changing the line #define CullNodes 1 to be #define CullNodes 0 and see if that changes anything?

[JRam13]

@slycrel Wow, setting CullNodes = 0 made a huge difference in FPS. I can scroll 3 layers now with no problem at a stable 60FPS.

Interesting that the optimization feature is actually causing the FPS drop.

I updated my demo with the optimization test showing the 3 layer scroll + 130 animated sprites at a stable 60FPS - https://github.com/JRam13/JSGlitch. I'll benchmark these against png skspritenodes and see what the difference in performance is.

[JRam13]

I did some extensive performance testing and Spritekit's native batch rendering is much much faster than using a tilemap. I tested the exact same maps and assets on both (using tilemap vs using raw png's and adding actions to those).

This doesn't really make much sense to me since I thought breaking big images into tiles should result in better performance. I guess Spritekit does a better job optimizing and batch rendering than I thought.

[slycrel]

That's pretty interesting. When I was originally writing JSTileMap I had considered a "render, flatten, display" workflow. This would render a tilemap, construct images of the rendered tilemap for you, and then use those in place of a ton of sprites. I wasn't sure how performance would work out and that would trim a bunch of issues with tiles (animations, rotation, etc at runtime). However if that is the case, maybe it would be worth looking into that for real. I do know that there are hard limits to the size of images that you can use with the GPU. If you're looking at a couple of background images used in a parallax fashion, I expect you would be better off using the images, or images cut into large sections. If you are making more of a world map style of game with lots of reused tiles, then a tilemap makes more sense there, as a pre-rendered image is unlikely to be feasible.

[JRam13]

For sure. I'm aware I'm not really using the tilemap as it was intended to be used- although it would have made my life much easier.

Still would be the best thing to use if you're going for the world map style type of game as you say.

[slycrel]

@JRam13 I think we have this issue cleared up. If you run into any other issues let me know!