Quote: Original post by Fuji
How exactly does the program refer to part of the saved tileset image without referencing the image as a whole? Is there a special format or file extension to use when saving an image to use as a tileset?

Well what exactly are your goals? Are you an artist working with a programmer to create a tileset? Are you an upstart programmer trying to get started with tiling?

Since you already said you don't program, you're maybe an artist making a tile set? Or just someone trying to make a game with an existing engine?

The reason I ask is, explaining it to you as a programmer may be meaningless. At which point, it doesn't really matter how it works ;)

I'm an artist and I want to start doing some mapping, but I haven't done anything of the sort, mainly character and item type things. I want to start doing environments now.

Quote: Original post by Fuji
I'm an artist and I want to start doing some mapping, but I haven't done anything of the sort, mainly character and item type things. I want to start doing environments now.

Okay then. Most things you can think of are possible. However, your art will require some criteria or need to follow a certain pattern/format depending on the engine you are targetting. Your art is only as good as the program (if you are targetting games, which I think you are).

I'd stick to the more traditional tile method, which is tilesets. One image file, many tiles all stored together spaced by 0 or 1 pixels. Sets are then only loaded based on the map.

Whereas the maps only ever refer to the tiles in the set (the actual image file). Hence why some or many games seem to be broken up by environment type (winter, forest, desert, etc). This not only saves memory, but it keeps things nice and clean and organized. Modern 3d games might even use similar tactics in their texture sets.

But most of these restrictions are non-issues now (particularly for 2d). Modern PCs have more memory and processing power, you probably don't even need to worry about the technical reasons why things are done how they are done; the reasons might be insignificant, but it still serves as good organization. Just that it's a widely accepted format and if you're doing these to provide to the public for free use (or for a price), this is probably the most acceptable way to organize it. It's also easy to reorganize if a serious end user wants to. And chances are, since it's rather the standard, any engine you try to use will be able to load the tiles.

Try to stick to power of 2 as a precaution (that is 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, etc).



I've programmed a tile engine that didn't even bother with tilesets, I just loaded what was needed for the map and did some basic memory management (buffering). I didn't even bother to put my tiles in a single file, they were in fact all a separate file. At the end of the day, it just didn't matter. And while some of my programming brethren could make arguments about speed or efficiency, the end results are probably not measurable enough to make a real compelling argument.

Anyway, hope this helps a little.