Best approach for building a layer

[Vincent]

Hi guys!

I need your suggestions.   I'm moving on to level design in my game.  So I found a lot a tileset on the web, I plan to alter them a little to make them unique to my game, etc.  I build my levels in photoshop.  For the moment not much is done, but I wanted to try to implement a room into sgdk2 to see how well it does... and boy: it's a lot of work! 

There are many different tiles in my tileset.  Look at the attached png image.  It's a not such a big room, but there are a lot of specific tiles.  (each tile is 16px by 16 px).  You can see the room and 2 backgrounds that will go under the main room.  The "floating" tower goes over the tower to the left on a "top" layer.  So when the character moves into the tower, I hide the wall and show the inside of the tower.

Is there a good way to recreate this level in sgdk2 without selecting each and every 16x16 tile and assembling them in the layer?  Because, since I want to optimize, each repeated tile is there only once in the frameset.  And it becomes a huge mess.  If I have to assemble a "jigsaw puzzle" for each level, I'm never gonna see the end of it.    (I plan for 7 different levels consisting of about 30-35 screens each.  This room makes a total of 4 screens.)

So, if you had to accomplish this, how would you do it?

I really need a hand here. 

Thanks a lot! 

[SmartBoy16]

you could turn the floating tower into one single tile if you plan to use that repeatedly. or else, 16x16 does seem small for a tile, especially for the enite level. maybe the best thing to do is combine the tiles so they are larger like 32x32. in fact, for the tower iself, make that a large tile in the background so building another tower is just as simple as a single click. the same goes for the fence and the backgrounds too.

[Vincent]

I guess making bigger tiles for background elements is logical!  I should have thought of that.   :yes:  Thanks SmartBoy16!

But for the actual "solid" tiles, I have no choice but to make them 16x16: my library of tiles all are 16x16 so I would have to develop a whole new set of solidity definitions to make up for all the possibilities... Hum... not an option.  But it would save me a lot of troubles to make the fence in a few tiles rather than cutting it in 16x16...

I wonder, what is the best choice performance wise?  To have a single tile that is repeated frequently or a few big tiles that don't repeat often, considering that in both case, you make a layer of the same size? 

I have to consider that, since my game is already taxing and that no levels are done yet...

Oh, and also, what should be the max size of a tile?  My 128x128 sprites are already painful to load...

[SmartBoy16]

Oh, and also, what should be the max size of a tile?  My 128x128 sprites are already painful to load...

for the main layer, my best guess is 32x32 to 64x64, make sure it is square so hills work correctly. for backgrounds, use 64x64 to 128x128, but about any size will do. usually, tiles dont use up as much memory as sprites do, so you can probably go even bigger than that.

edit: actually, i think having manymanymany smaller tiles slows the drawing time for some computers

[Vincent]

Woohoo!  That's good news!   
Bigger tiles mean a lot easier work for me!

Suddenly, it doesn't seem like an impossible feat after all!

Thanks a lot SmartBoy16!

[SmartBoy16]

youre welcome

[bluemonkmn]

I'm not exactly sure what you're going to do to get bigger tiles.  If you're going to draw more graphic sheet cells to support it, the increased memory usage could cost you somewhat performance-wise because increased memory usage can sometimes affect performance, so you might want to be careful about that.  If you are going to define the larger tiles by combining the smaller frames, you might not get much of a performance boost because it would still have to draw the same number of separate images on the screen.  And if you're only doing this on layers where there aren't sprites interacting with the tiles, there's not much optimization in the area of tile interactions with fewer tiles.

So you might want to consider another option where you may not need to rely on bigger tiles: Use the Copy and Paste features from the "Tools" tab of the map editor.  If you have a tower somewhere on the map, and you want another, just copy it.  I think I had a plan to implement support for "Brushes" where you could have these predefined objects built out of tiles ready to use at any time on any map, but the Copy feature is so close to that that I haven't been compelled to implement it yet.  You could "manually" implement it by drawing one of all the objects you'll want at the top of the map and just copy them from there (or the nearest location) whenever you need them.  I know it's not very convenient, but it's better than drawing it manually every time.  And once you've done one map, I think there are ways to copy that to other maps if you want the same brushes to be available on multiple maps... but it might take some work... there's no built-in feature to copy layers across maps I don't think.

[Vincent]

Well, if there is no difference between big tiles and small tiles for optimization on layers where no sprites interact, I'm definitely going for bigger tiles.  It will be faster to create. 

I was unaware of a copy-paste tool for the map editor!

Well to get bigger tiles, i will extract all the actual tiles with solidity from the level.  Those will be 16px by 16 px, but there won't be a lot of them.  All of the other parts of the level that are only"eye candy", will be in another graphic sheet and another layer with bigger tiles.  I will have more graphic sheets, but I will separate them to not duplicate the tiles...  So, one additional layer, I guess it won't be too hard for the performance...  Anyway, I'm going to give it a try.

Could I copy-paste layers form map to map via the XML file?  Is there something particular to be aware of during this operation?

Thanks guys.   

[bluemonkmn]

One option for copying content from one map to another is to do it manually with the XML, as you suggest.  Then I think the safest bet is to make an empty layer that is the correct size and everything else matching the source data (except of course all the tiles), and just copy the layer's tile data over so you don't have to worry about the data being corrupted because of the tile data length being inconsistent with the layer size or something.

Another possibility it to use the map copy/merge utility I created recently:
http://gamedev.enigmadream.com/index.php?topic=1388.msg8623#msg8623

It was designed for merging the same map from one project file to another (where you have multiple people working on the same project), so I'm not sure how well that will work... haven't even tested it very well for its original purpose.  But you may be able to make two copies of the same project (copy A and copy B) with an empty layer in copy B, then rename the layer that you want to copy in project A to match the empty layer in project B.  Then you might be able to copy it from project A to project B and have two copies of the layer in project B.

[Vincent]

Thanks Bluemonkmn, I'll give your utility a try!

[Jam0864]

I wouldn't worry about performance... I was hitting over 1500fps on the SHFL demo.

[Vincent]

Well about performance, when my game has loaded all of it's components, it runs fine (60 fps cap), but it's so long to load...

[bluemonkmn]

It's slow because of all the collision masks you've defined.  You have so many huge graphic cells where only a small piece of the cell is used, and SGDK2 has to walk through every empty (and non-empty) pixel looking for non-transparent pixels to define the collision masks for every frame of every state of every sprite that has Mask Alpha Level not equal to 0.  Maybe you should try setting mask alpha level to 0 on everything and then only define masks for sprites that really need pixel-perfect collision detection. (Be sure to select all the frames for a state before setting the collision mask level.  Each frame has its own level.)

[SmartBoy16]

It's slow because of all the collision masks you've defined.  You have so many huge graphic cells where only a small piece of the cell is used, and SGDK2 has to walk through every empty (and non-empty) pixel looking for non-transparent pixels to define the collision masks for every frame of every state of every sprite that has Mask Alpha Level not equal to 0.  Maybe you should try setting mask alpha level to 0 on everything and then only define masks for sprites that really need pixel-perfect collision detection. (Be sure to select all the frames for a state before setting the collision mask level.  Each frame has its own level.)

wow!

[Vincent]

Allright!  Thanks bluemonkmn, I will change them.