New tile shapes and a suggestion

[Vincent]

Hi guys,

Even if I'm not asking questions lately, I'm still working on my game, but I guess most of my issues are solved for now, so I don't need to bother you. :p  I still hang around though. 

I worked on some new tile shapes, maybe some of you could be interested in them (I attached them to this message).  Some can probably be improved, but they still behave fine I think.  Here are the tiles I created:

• a bottom-half solid tile (can be inserted between a downhill left and a downhill right and fits perfectly).
• a bottom-half top solid tile (like the one above but only solid when you arrive from the top)
• a uphill top solid tile (like the uphill tile but only solid when you arrive from the top or the left)
• a downhill top solid tile (like the uphill tile but only solid when you arrive from the top or the right)
• a uphill left top solid tile (like the uphill tile but only solid when you arrive from the top or the left)
• a uphill right top solid tile (like the uphill tile but only solid when you arrive from the top or the left)
• a downhill left top solid tile (like the uphill tile but only solid when you arrive from the top or the right)
• a downhill right top solid tile (like the uphill tile but only solid when you arrive from the top or the right)

I think the bottom half tiles are perfect, but sometimes the uphill and downhill top solid tiles can be a problem if the character wants to jump through and arrives from the side where there is a solidity.  So I gotta prevent the problem in the way I design the level.  Or maybe someone (like Bluemonkmn or Durnurd) could check it out for a solution! 

Also, I realized (so late...) that with one good tileset for solidity, I could have done all my levels.  What I mean is, I could have drawn the levels in photoshop (or another drawing software) and import big images into sgdk2.  Then, use these images for the visual on a layer (with low z-index) and create the "solid" layer (where I put all the sprites) over the visual layer.  Use the universal solid tiles and draw them over the visual layer, put in the sprites, etc.  Then, when all the solidity is done, go into the frameset and set all the universal tiles to invisible.  So I use always the same tileset to make the solidity, but it doesn't matter to the person who is playing because all he sees is the visual layer underneath and the sprites on the layer with invisible tiles.  Do you follow me?

By using this method, only one tileset with tile solidity is needed for almost any situation.  I thought, maybe that could be explained into the help file?  I didn't see this anywhere...  Anyway, it's just an idea.  It's a little late for me to go back and redraw all the levels using this technique, but when I'll start another project, I will be sure to do that.

What do you guys think?

Thanks!

[bluemonkmn]

I made a program that shows pictures of a solidity function as it is seen from above, below, left and right.  I used it to make sure that the tile shape looks the same from all directions (eliminating rounding errors) so that the shapes would not be problematic.  I'm not sure if your problem is related to that, but if you would like that program, I can look for it when I get home.

[Vincent]

Sure, I'm interested in this program!

[durnurd]

After you're done with the solidity, do you leave the gigantic image in the background, or do you break it up?  Because you should definitely break it up as much as you can for performance reasons.

[Vincent]

@durnurd:  Well, yes I leave the big image there.  It is the whole point of the operation, to skip the operation of the image break down. 

Of course, it depends a lot on the type of visual you make for the game.  A game like the SHFL would not need to proceed like this, because it is always the same tiles that are used and the background is simple.  In fact, as you point out, it would be wise to advise against my procedure because of performance issues.

My game,is definitely bigger: backgrounds are complex and big anyway, and there is one in every map.  So to save a background and put tiles over it to make the solidity with invisible or visible tiles doesn't change anything in this case for the performance.  But it solves a lot of time to make the level and to create new tilesets.

[durnurd]

Just how big are these images though?

[Vincent]

Each background image is 320 pixels wide by 240 pixel high.  I have about one per "screen" and my game is about 110 screens big for now.  I expect to add another 360 screens or so eventually...     Yeah, I know it's big... 

[Vincent]

Hey, now that I think of it, it could still be useful to proceed like this in SHFL.  If you want to make a tileset each season, you could use the visible tiles to make the visual of the level, then draw with the invisible tileset over it.  So you wouldn't have to manage solidity for many tilesets, only the invisible one...  Oh well, you get the idea. 

[durnurd]

Oh, I was thinking you were doing large scrolling maps, but if you're jsut doing small static screens, it makes it easier to deal with.  If each image is 320x240, it fits in a 512x256 block, and that comes out to be 0.5 MB in RAM per image.  Thankfully, you don't need to worry about having all 470 images on screen at once, so the RAM requirements shouldn't be too bad... as long as each image is in its own Graphics Sheet, anyway.  If not, then you will obviously want to split them up at least somewhat so that you don't have a 128 MB image in memory just to draw a 0.5 MB part of it.

[Vincent]

Oh!  Well some rooms are more than one screen big, but my biggest room is about 6 screens by 4 screens.  I won't do bigger rooms.  And of course I split them between different graphic sheets.  A graphic sheet contains a maximum of 3x3 screens.  And of course I pack the multi-screen rooms in the same graphic sheets as much as possible.

[bluemonkmn]

I'm not sure if SGDK2 can handle such a load.  All the images are stored in 1 EXE file, and I'm not sure how well SGDK2 loads/unloads graphics when using them and when not using them.  I hope it will work, but I hope it doesn't derail your project if you hit some limit and have to find another way.

Attached is the tile shape viewer program.

[Vincent]

Thanks for the program Bluemonkmn!

Well, I guess I'll see what happens along the way.

Thanks again