Impact

This forum is read only and just serves as an archive. If you have any questions, please post them on github.com/phoboslab/impact

1 decade ago by Drakmir

I created my tile map using Texture Packer our of a set of discrete graphic images. They were all 32x32 images and I had quite a few of them. The original tile map created by the texture packer tool was a bit tall (height) and I noticed that in the editor, the tile popup doesn't show the entire tile map and there doesn't appear to be a way to scroll in the tile map, etc. Am I missing something? If not, what would it take to support larger tile maps?

I "fixed" it by setting my zoom factor in the editor to 1 and changing the dimensions of the packed image to be wider. But I'm still going to hit a point of diminishing returns with this approach.

I wouldn't think it to be unusual on today's hardware (with large resolutions) for a game to have 2048x2048 or even 4096x4096 tile maps.

Also, I'm wondering how this is going to work as I move forward with my product. If I add new tiles to my setup and let texture packer repack the tile map then it would seem to me that my level will be screwed up since everything is index based.

Is there a way to have more complex tile maps that are name based? Tools like texture packer will produce a data file that describes where it put all the images (in fact, Texture Packer even supports JSON as an output type). That way the editor could actually store levels by tile name instead of index?

This can have a few advantages (and this may apply to animation sheets as well):
1) Tiles can be different sizes in the same map
2) Offsets can be stored in the animation sheet so that entities can animate smoothly.
3) Animation information could (in theory) be stored in the tile map so tiles would animate without extra setup

The last few are just ideas to make the editor even better than it already is. If I have to take over full control of my tile map, I can. I just like to use tools to help make my job easier.

The only real issue I see is "large" tile maps.

1 decade ago by Drakmir

For the second part of my question above, I didn't notice that it was at least asked in this previous post:

http://impactjs.com/forums/impact-engine/blitting-non-fixed-sprite-sheets-support

Sorry for bringing up this topic again, my search didn't expose that older post.

My suggestion about making larger tile maps work in the editor still stands though, regardless of more complex sprite sheet support.

1 decade ago by dominic

The tileset popup in Weltmeister has its problems with very large tilesets, yes. Your fix - setting the zoom to 1 - is a good workaround so far. I was always under the impression that if you have such large tilesets, your game is quite "high res" as well. So working with a zoom factor of 1 in WM would make more sense anyway.

But it sounds like you still want to have a higher zoom level in the editor? Out of curiosity, can you maybe show your tileset? Do you really need all tiles in one tileset? Can't you divide them into several smaller tilesets - e.g. one for each "theme"?


Impact uses indexed tiles, because they&039;re fast and easy to work with and don't require any external tools other than an image editor. Have a look at the #lib/impact/background-map.js file - you could subclass the BackgroundMap to work with named tiles instead.

1 decade ago by stahlmanDesign

You can also set your zoom factor to 0.5 to see even more of the map.

1 decade ago by Drakmir

Thanks for the replies. Sorry it took me so long to get back to you, but I've been away from the impact project for the past week.

I didn't think to set the scale factor to a fractional number. I can look into that if necessary.

I am working with tiles from two websites and haven't yet started to split them up and work with smaller tile sets.

I suppose that once the tile sets are reduced to fit my game better, I won't run into the problem too much. It's likely more of an issue at this point since I'm still experimenting.

Finally, the name based thing again is likely only a problem during "development" - as the tile sets are changing. The above situation is one of them. I'm using the uncut tiles to work with and debug my game until I get a feel for the artwork, etc.

Once I chose the sets of graphics I want to work with and piece them into my own tile set, the levels are going to have to be rebuilt (since the index of the tiles will have changed).

This isn't really an issue if you have your graphics locked down during level editing, but I'm used to a more iterative development cycle where that isn't necessarily the situation. Also, during baking, I'd want the tiles to be indexed instead of a name look up anyway (for speed).

So, thanks for thinking on it. I'll work through the issues and if I come up with any good solutions I'll post them.

1 decade ago by Derek

Dominic,

I don't know if it would be easy enough to be worth it, but it would sure be nice if we could scroll the tile selection layer. I, too, have a huge tileset, one I was hoping to use for every level in the game. It might not make the most sense, but it's more of a pain to have to go append more tiles to divided tilesets each time I realize I need another tile from my master set.
Page 1 of 1
« first « previous next › last »