Lass's tile conservation tips
Lass's tile conservation tips
Since people all over the board seem to have problems with tile limits not to mention memory issues, I am starting a topic for the tips and tricks I use to minimize the mount of tiles and memory that I take up when modding. I shall post one tip per day until I can't think of any more.
It will use examples drawn from the Keen 10 alpha release since this illustrates a lot of points which will be seen in the upcoming beta release.
First up, making use of the background layer.
This applies only to Keen Galaxy where, as you know (I hope!), there are two layers of tiles. Usually a modder is given more background than foreground space AND there is the added bonus that background tiles take up less memory. As such it is often desirable to have as many tiles in background as possible.
Any tiles that do not have any transparent pixels (Easier to see in keengraph than modkeen at present.) and are not foreground can be moved to the background in some way or another (Yes, even things like solid and hazard tiles!)
As an example take this computer bank. As per the alpha it took up 4x6 = 24 foreground tiles and could only be placed as-is:
It's easy to see how this can be rearranged, only four of the tiles have transparency so we can move the rest to the background layer. This is especially easy since it has no other properties, it's not solid or anything like that:
However this has some additional benefits; because of the way that works I can now stack banks beside each other, the leftmost row of one overlapping the rightmost row of another. I have additional flexibility. I can also cover nearly all the bank with additional eye candy, be it point items, rust stains or pole tiles. Additional flexibility!
I can go further with the addition of one more tile; if I add (Or have) an invisible 1 way up tiles I can place those over the second row of background tiles (Plus adding the one way up property to the second top-left fore tile) which will allow Keen to stand on the computer banks with only a slight loss of flexibility.
There is also memory saving since background tiles use 80% of the memory of foreground tiles.
There is of course one major drawback to this (And several other tips) an increase in levelmaking complexity. Previously placing a bank was as simple as copy-pasting a block from the fore tileset now it must be constructed from an oddly shaped block in the back AND fore tilesets. Once built it can be copy-pasted, but this may require slight background tweaks again. And removing the bank if it is a mistake is more tedious.
As such this sort of thing should either be done at the start of a mod (which will allow for optimal use) or at the end of it when you can copy-paste-replace chunks to free up tiles for those last minute additions.
Upcomming tips will include looking for duplicate tiles, being careful using templates, and using the background layer to simplify variations on a theme.
It will use examples drawn from the Keen 10 alpha release since this illustrates a lot of points which will be seen in the upcoming beta release.
First up, making use of the background layer.
This applies only to Keen Galaxy where, as you know (I hope!), there are two layers of tiles. Usually a modder is given more background than foreground space AND there is the added bonus that background tiles take up less memory. As such it is often desirable to have as many tiles in background as possible.
Any tiles that do not have any transparent pixels (Easier to see in keengraph than modkeen at present.) and are not foreground can be moved to the background in some way or another (Yes, even things like solid and hazard tiles!)
As an example take this computer bank. As per the alpha it took up 4x6 = 24 foreground tiles and could only be placed as-is:
It's easy to see how this can be rearranged, only four of the tiles have transparency so we can move the rest to the background layer. This is especially easy since it has no other properties, it's not solid or anything like that:
However this has some additional benefits; because of the way that works I can now stack banks beside each other, the leftmost row of one overlapping the rightmost row of another. I have additional flexibility. I can also cover nearly all the bank with additional eye candy, be it point items, rust stains or pole tiles. Additional flexibility!
I can go further with the addition of one more tile; if I add (Or have) an invisible 1 way up tiles I can place those over the second row of background tiles (Plus adding the one way up property to the second top-left fore tile) which will allow Keen to stand on the computer banks with only a slight loss of flexibility.
There is also memory saving since background tiles use 80% of the memory of foreground tiles.
There is of course one major drawback to this (And several other tips) an increase in levelmaking complexity. Previously placing a bank was as simple as copy-pasting a block from the fore tileset now it must be constructed from an oddly shaped block in the back AND fore tilesets. Once built it can be copy-pasted, but this may require slight background tweaks again. And removing the bank if it is a mistake is more tedious.
As such this sort of thing should either be done at the start of a mod (which will allow for optimal use) or at the end of it when you can copy-paste-replace chunks to free up tiles for those last minute additions.
Upcomming tips will include looking for duplicate tiles, being careful using templates, and using the background layer to simplify variations on a theme.
The next thing that can be done is looking for duplicate tiles. This is a surprisingly common occurrence. As an example take the 'purple ground' from Keen 10:
Some duplicate tiles are easy to see; there are two beside the pole going through the floor for example that are quite pointless. Other things look duplicate but aren't (Such as the stack of three ceiling tiles, one is normal, one secret area and one pole, this is why I like to mark those tiles somehow.)
But there are more hidden away. Since this was built from a template they've snuck in. Here I have marked most of the duplicate tiles with dark green squares:
There are 13 marked tiles there, a good percentage of the total. Had we not looked this over most would have been innocuous.
As a further measure combining this with our first tip we can fully halve the number of tiles by pushing many into the background and using invisible foreground sloped tiles. If you're on a tight tile buget this can free up significant space even if applied to your least used ground tiles.
Some duplicate tiles are easy to see; there are two beside the pole going through the floor for example that are quite pointless. Other things look duplicate but aren't (Such as the stack of three ceiling tiles, one is normal, one secret area and one pole, this is why I like to mark those tiles somehow.)
But there are more hidden away. Since this was built from a template they've snuck in. Here I have marked most of the duplicate tiles with dark green squares:
There are 13 marked tiles there, a good percentage of the total. Had we not looked this over most would have been innocuous.
As a further measure combining this with our first tip we can fully halve the number of tiles by pushing many into the background and using invisible foreground sloped tiles. If you're on a tight tile buget this can free up significant space even if applied to your least used ground tiles.
Last edited by levellass on Wed Jan 08, 2014 11:44 pm, edited 1 time in total.
A better one would be one that notes tiles not used and removes them from the tileset; it was such a good idea Id Software had one.
A packing tool would only really be useful at the end of a project since it would scramble a lot of tile blocks and make it harder to place them when building stuff in levels.
Invisible property blocks have a lot of interesting applications. i consider them invaluable when building a tileset.
This brings us to the next tip, proper use of templates.
Using templates has many advantages, mostly they have everything in position and all you have to do is make tweaks to the existing architecture. However this comes with drawbacks as well; they constrain creativity and it is easy to make mistakes when relying on them.
If we take a look at the previous example we can see most of the duplicate tiles snuck in because a template was used:
However there are other issues here too; this template uses the 'standard' Keen Galaxy tile setup. While traditional there is no particular reason to use this POV or tile arrangement. Notably several tiles are nearly all empty space; on the leftmost of blocks of tiles is a thin sliver of wall that is never given a blocking property.
It is quite possible to tweak the perspective so that tile space is more efficiently used. (Or use an alternate scheme, famously Biomenace disposed with the 2.5D perspective altogether.) This again is something that should be considered at the start of a mod or whenever the new template is being considered. It can be difficult to alter a template but it should be noted that our most accomplished modders have tended to stray significantly from templates when making their graphics.
As an example this is a rough template for a 2.5D perspective that packs more efficiently than the default Keen perspective; it did not take long to construct and is easy enough to expand to a full tileset:
A packing tool would only really be useful at the end of a project since it would scramble a lot of tile blocks and make it harder to place them when building stuff in levels.
Invisible property blocks have a lot of interesting applications. i consider them invaluable when building a tileset.
This brings us to the next tip, proper use of templates.
Using templates has many advantages, mostly they have everything in position and all you have to do is make tweaks to the existing architecture. However this comes with drawbacks as well; they constrain creativity and it is easy to make mistakes when relying on them.
If we take a look at the previous example we can see most of the duplicate tiles snuck in because a template was used:
However there are other issues here too; this template uses the 'standard' Keen Galaxy tile setup. While traditional there is no particular reason to use this POV or tile arrangement. Notably several tiles are nearly all empty space; on the leftmost of blocks of tiles is a thin sliver of wall that is never given a blocking property.
It is quite possible to tweak the perspective so that tile space is more efficiently used. (Or use an alternate scheme, famously Biomenace disposed with the 2.5D perspective altogether.) This again is something that should be considered at the start of a mod or whenever the new template is being considered. It can be difficult to alter a template but it should be noted that our most accomplished modders have tended to stray significantly from templates when making their graphics.
As an example this is a rough template for a 2.5D perspective that packs more efficiently than the default Keen perspective; it did not take long to construct and is easy enough to expand to a full tileset:
Last edited by levellass on Wed Jan 08, 2014 11:43 pm, edited 1 time in total.
hey i already made a thread about trying to save memory which no one cared about. can i contribute?
cause i was gonna mention that one way, which i used, to save tile space is to convert tile based decorative objects into sprites (if you have the patching know how ofcourse. or just bug levellass to help you do it.) the most obvious example is the bean-with-bacon megarocket from the galaxy games. Ofcourse it then cuts into your patching space - or if you have the sprite in an ordinary level (not just a BWB-like mini level) you could have memory issues. its all about juggling what you need and not need.
so can i contribute and mention all that? which i just did? and can do nothing about even if you dont allow it?
cause i was gonna mention that one way, which i used, to save tile space is to convert tile based decorative objects into sprites (if you have the patching know how ofcourse. or just bug levellass to help you do it.) the most obvious example is the bean-with-bacon megarocket from the galaxy games. Ofcourse it then cuts into your patching space - or if you have the sprite in an ordinary level (not just a BWB-like mini level) you could have memory issues. its all about juggling what you need and not need.
so can i contribute and mention all that? which i just did? and can do nothing about even if you dont allow it?
To be fair Bernie you got quite a few replies on your thread, especially seeing as this is a quiet forum often going a few consecutive days of no posts. Also, this thread talks more about space in the tileset for more graphical diversity rather than freeing memory. Though, particularly in Galaxy, these may go hand-in-hand.
I don't have much to contribute here myself, however, if you'll glance at this here set-piece I recently made, you will note how I chose to use simple block EGA colours rather than dithering and shading. Not only was this in keeping with the original game's style, but it also freed up a lot of tiles. Look at the land and the ocean, it's all a repeating block colour. The blue even came from the in-level water. Of course, this approach is not for everyone's project, but with some careful tweaking you can create seemingly massive in-level setpieces, with minimized impact on your tileset. My efforts here aren't perfect in that regard.
A pitfall with this kind of image is small straggling pixels that overflow into the next tile, wasting that tile. With a small amount of extra effort I could probably have freed up another 10 or more tiles and still have this Earth look indestinguishable from how it looks now. I happened to be through with adding graphics to my mod, but some people will not be so easily satisfied.
I don't have much to contribute here myself, however, if you'll glance at this here set-piece I recently made, you will note how I chose to use simple block EGA colours rather than dithering and shading. Not only was this in keeping with the original game's style, but it also freed up a lot of tiles. Look at the land and the ocean, it's all a repeating block colour. The blue even came from the in-level water. Of course, this approach is not for everyone's project, but with some careful tweaking you can create seemingly massive in-level setpieces, with minimized impact on your tileset. My efforts here aren't perfect in that regard.
A pitfall with this kind of image is small straggling pixels that overflow into the next tile, wasting that tile. With a small amount of extra effort I could probably have freed up another 10 or more tiles and still have this Earth look indestinguishable from how it looks now. I happened to be through with adding graphics to my mod, but some people will not be so easily satisfied.
This is indeed a good strategy that I would say kinda falls a bit into considering your templates but more into what I call 'general use tiles'
Which, (why not?) Is today's tip: General use tiles
Take a look at these tiles from Keen 4; these are the four kinds of door tiles used in-game. Each only works with a single type of ground and has no variation at all. If you want more than one variation of door in a level you'll need to double the amount of tiles included. (Remember animated tiles auto-cache everything they animate to when the level loads.)
Now we can replace all of these with this more transparent 'general door':
There are several advantages with this, now a single set of animating tiles can serve for all four doors. The door is not limited to what tiles we put behind it, as long as they're background. This goes hand-in-hand with making foreground tiles background a lot of your ground variation should be background which can then combine with varied foreground tiles for an exponential number of combinations.
Note also the marked square in the lower right; given the door tile properties I can use this as my invisible blocking tile. (Being at the end of the animation sequence it only caches itself.) saving even more tile space.
The main disadvantage is again it's harder to place in a level than a chunk of foreground stuff. Also since it requires fore and back tiles it actually uses slightly *more* memory than a single variety of door. However if you're saving tile space you should have these background tiles somewhere in most levels already acting as space-savers for a general decrease in graphic memory.
Another example is the slime from Keen 6; as is this consists of a foreground hazard:
It too is extremely limited as to where it can be placed. Now I could do what I did with the door, making it more transparent so that it can be placed over any ground type. But I can also do this:
This example is from Keen 10 where I have taken the opposite approach; I have kept the ground but made hazard transparent. Why?
Firstly the ground it's based on is quite common so there is some variability with where I can put it. Secondly I can now place an animating *background* tile behind the hazard, say bubbling tar. The animation I placed behind this by default is a loop of 2x8 tiles. In total a large pool of slime then takes 24 (8 fore + 16 back) tiles whereas the same in 'pure foreground' tiles would require 64 tiles (8 fore with 8 animations each.)
I an also create a number of equally impressive variations; in the same background tileset I have a 12 tile green, red and blue glowing sequence These can be placed behind the hazard to make glowing slime pools like in Keen 6 but more impressive and with a different feel for each variation.
Other times this comes in handy are computer screens (Make the screen transparent then put static, blinking lights and whatnot in the background), tanks of liquid\stuff and even background patterns (Combine one partially transparent pattern with a second background pattern.)
Either way having 'general' tiles in your tileset that you can easily apply variations to allows you to sue a small number of tiles for a much larger amount of eyecandy.
@Bernie: Go ahead, especially if your tips go for tiling. As a matter of fact tiles -> sprites was something I was going to cover tomorrow.
Which, (why not?) Is today's tip: General use tiles
Take a look at these tiles from Keen 4; these are the four kinds of door tiles used in-game. Each only works with a single type of ground and has no variation at all. If you want more than one variation of door in a level you'll need to double the amount of tiles included. (Remember animated tiles auto-cache everything they animate to when the level loads.)
Now we can replace all of these with this more transparent 'general door':
There are several advantages with this, now a single set of animating tiles can serve for all four doors. The door is not limited to what tiles we put behind it, as long as they're background. This goes hand-in-hand with making foreground tiles background a lot of your ground variation should be background which can then combine with varied foreground tiles for an exponential number of combinations.
Note also the marked square in the lower right; given the door tile properties I can use this as my invisible blocking tile. (Being at the end of the animation sequence it only caches itself.) saving even more tile space.
The main disadvantage is again it's harder to place in a level than a chunk of foreground stuff. Also since it requires fore and back tiles it actually uses slightly *more* memory than a single variety of door. However if you're saving tile space you should have these background tiles somewhere in most levels already acting as space-savers for a general decrease in graphic memory.
Another example is the slime from Keen 6; as is this consists of a foreground hazard:
It too is extremely limited as to where it can be placed. Now I could do what I did with the door, making it more transparent so that it can be placed over any ground type. But I can also do this:
This example is from Keen 10 where I have taken the opposite approach; I have kept the ground but made hazard transparent. Why?
Firstly the ground it's based on is quite common so there is some variability with where I can put it. Secondly I can now place an animating *background* tile behind the hazard, say bubbling tar. The animation I placed behind this by default is a loop of 2x8 tiles. In total a large pool of slime then takes 24 (8 fore + 16 back) tiles whereas the same in 'pure foreground' tiles would require 64 tiles (8 fore with 8 animations each.)
I an also create a number of equally impressive variations; in the same background tileset I have a 12 tile green, red and blue glowing sequence These can be placed behind the hazard to make glowing slime pools like in Keen 6 but more impressive and with a different feel for each variation.
Other times this comes in handy are computer screens (Make the screen transparent then put static, blinking lights and whatnot in the background), tanks of liquid\stuff and even background patterns (Combine one partially transparent pattern with a second background pattern.)
Either way having 'general' tiles in your tileset that you can easily apply variations to allows you to sue a small number of tiles for a much larger amount of eyecandy.
@Bernie: Go ahead, especially if your tips go for tiling. As a matter of fact tiles -> sprites was something I was going to cover tomorrow.
Last edited by levellass on Wed Jan 08, 2014 11:42 pm, edited 1 time in total.
Woah I am blown away by the simplicity of your ideas Levellass - particularly the slime. I notice that the little bit dripping down anteriorly is grey. This keeps it versatile.
This might be going offtopic, as it doesn't further the goal of reducing tile use, but could you also employ masking to make more complex shapes in multicolour. For instance, if that slime drip was masked so as to darken the colour behind it, then you could have a dark green drip of green slime, a dark pusple drip of purple slime, etc. And so, even though the masking would use up a tile, you could still exploit it and make up to eight different hue slimes.
====== Okay I've thought of a (mediocre) tile-saver idea ========
You could have a general masked foreground tileset - say for instance a red, green, yellow and blue masking tile (behind keen if this is possible - i.e. not masking him). Then, say if you had a wall sign saying "KEY" and one saying "DOOR". You could have just one background tile for each of these signs, in grey. Overlaying the four masking colour tiles over these grey signs would give four different colour signs. Using only six rather than eight tiles. Obviously the more use you get out of each of the masking tiles, the more value you'd get!
This might be going offtopic, as it doesn't further the goal of reducing tile use, but could you also employ masking to make more complex shapes in multicolour. For instance, if that slime drip was masked so as to darken the colour behind it, then you could have a dark green drip of green slime, a dark pusple drip of purple slime, etc. And so, even though the masking would use up a tile, you could still exploit it and make up to eight different hue slimes.
====== Okay I've thought of a (mediocre) tile-saver idea ========
You could have a general masked foreground tileset - say for instance a red, green, yellow and blue masking tile (behind keen if this is possible - i.e. not masking him). Then, say if you had a wall sign saying "KEY" and one saying "DOOR". You could have just one background tile for each of these signs, in grey. Overlaying the four masking colour tiles over these grey signs would give four different colour signs. Using only six rather than eight tiles. Obviously the more use you get out of each of the masking tiles, the more value you'd get!
You are indeed correct; and I have done similar things in Zoltan. An unfortunate limitation is that background and foreground tiles placed together cannot both animate (That would have allowed for some awesomely random seeming animation.)
Another trick is using foreground tiles that are translucent, that is colored but not masked. These will alter the color of any background tiles behind them in an additive manner. (That is blue tile plus red mask = purple color and so on.) If the tile is foreground it will affect sprites too. Notably these can be used to make 'lights'; tiles that make everything behind them appear in light colors only. This is done using an unmasked dark grey tile.
Next up; turning large tile features into sprites.
If you are suffering extreme tile shortage it is possible to take large features such as the BwB Megarocket and turn them into single sprites. Modder often have some sprites left over, or at least the ability to add more sprites to the game. If so a sprite that stands totally still uses the same graphics memory as a bunch of tiles and also one slot in the object array. (This means it may not be a good idea to put it in a sprite-heavy level.)
The basic idea is quite simple but the execution is harder. If a bunch of tiles is simply copied over as the image of a sprite it will free up tile space. (Sprites can be made solid or deadly too, giving you some variability in 'tile properties')
Creating a new sprite is the problem. if there are no 'spare' sprites left over then it will probably need a (rather simple) patch from someone like me. This will convert one of the unused sprite squares (Such as the 'I Keen' in Keen 4) into a sprite that can be placed into a level.
This was done in Zoltan with the eye things and blue things, but really done well in Ruin of Roib where a few things you would swear are tiles are actually sprites.
The difficulty is all in the setup; once done it is easy to add these sprites wherever and they seldom cause memory issues. (And these are easily fixed.)
Next up, how to use those sprite tiles for extra space and when to do so.
Another trick is using foreground tiles that are translucent, that is colored but not masked. These will alter the color of any background tiles behind them in an additive manner. (That is blue tile plus red mask = purple color and so on.) If the tile is foreground it will affect sprites too. Notably these can be used to make 'lights'; tiles that make everything behind them appear in light colors only. This is done using an unmasked dark grey tile.
Next up; turning large tile features into sprites.
If you are suffering extreme tile shortage it is possible to take large features such as the BwB Megarocket and turn them into single sprites. Modder often have some sprites left over, or at least the ability to add more sprites to the game. If so a sprite that stands totally still uses the same graphics memory as a bunch of tiles and also one slot in the object array. (This means it may not be a good idea to put it in a sprite-heavy level.)
The basic idea is quite simple but the execution is harder. If a bunch of tiles is simply copied over as the image of a sprite it will free up tile space. (Sprites can be made solid or deadly too, giving you some variability in 'tile properties')
Creating a new sprite is the problem. if there are no 'spare' sprites left over then it will probably need a (rather simple) patch from someone like me. This will convert one of the unused sprite squares (Such as the 'I Keen' in Keen 4) into a sprite that can be placed into a level.
This was done in Zoltan with the eye things and blue things, but really done well in Ruin of Roib where a few things you would swear are tiles are actually sprites.
The difficulty is all in the setup; once done it is easy to add these sprites wherever and they seldom cause memory issues. (And these are easily fixed.)
Next up, how to use those sprite tiles for extra space and when to do so.
Sorry, yes I actually meant translucent. I used the word masked because, as I am familiar with Vorticons, I am used to using the same tile property - called 'Masked' in tileinfo - to achieve both the translucent effect and actual masking.
Your sprite idea is obviously a good way to get more graphics into your game. But how would this impinge on memory? Is this still an issue? It has been a while since I've run any mods natively on the MS-DOS version that comes with Windows98 (nevermind Dos 5 like I used to play Keen). Would older systems be able to support Keen4 running with several very large set-piece graphical items? And at what point would DosBox be driven to its limit, for that matter?
Your sprite idea is obviously a good way to get more graphics into your game. But how would this impinge on memory? Is this still an issue? It has been a while since I've run any mods natively on the MS-DOS version that comes with Windows98 (nevermind Dos 5 like I used to play Keen). Would older systems be able to support Keen4 running with several very large set-piece graphical items? And at what point would DosBox be driven to its limit, for that matter?
It's certainly odd, you're a white male, everyone should listen to you on everything. Of course... is anyone listening to me?
Using the 'sprite tiles' at the top of the tileset
Galaxy games have several rows of tiles at the head of the tileset that are used to represent sprites in the level editor. By default these are unusuable in any level editor we currently posses, but they are tiles like all others and can be used in the same way, the only question is 'How?'
Now this is best done at the very end of a modding project as it plays hob with your ability to edit levels (What with all your neat sprite images being replaced with tiles.) Indeed it may even help to keep a sprite-filled tileset for use in main level editing while the tile-filled tileset is used only when adding the extra tiles. As such the tiles stored in this section should be rarely used final touches, that ship you wanted in the boss level, the radio tower in level 6 you didn't have space for and so on.
Now on to inserting those tiles. You will need some knowledge of hex editing to do this. The first thing to do is to open a level in your editor of choice, be it TED5, TOM or something else. Now you will need to add a block of nonsense tiles somewhere that aren't used anywhere else in the levels (So they won't be compressed and confuse things.) This is easier than it sounds, ground tiles out of order will do it. It helps to place as many tiles as you will need new tiles. Take note of the numbers of the first few tiles that you used. Save your level and quit.
Next open the level in your favorite hex editor. (For TED5 this will be maptemp, for TOM the gamemaps file.) Search for those tile numbers you placed. If you did it right there should be only one place where those numbers are. If not... back to the drawing board.
Now we simply overwrite these tile numbers with tile numbers from the 'sprite section' ($01, $02...) and save the file. This will swap out the nonsense tiles we placed as markers with the previously unusable tiles.
Now you can just open the level and select the tiles. Due tot he way various level editors are set up you cannot select sprite tiles from the tileset, but you can select them from the level. You can even copy-paste blocks of them and treat them just like ordinary tiles. (Note you will 'lose' a tile if you delete all copies of it in all levels and will have to reinsert it.)
Again this is not to much of a memory tip or even a tile conservation tip, but rather something to help those whoa re finishing up and find they've run out of space. It helps you get the absolute maximum out of your tileset space. (I myself have only had to use this once, in Xmas 2010.)
In general if you set the number of sprite shifts to 1 (A tile-like sprite will not need more shifts as it will not be moving and even a moving sprite can make do with 1 or 2 shifts) it will take up exactly the same amount of memory (Or less since it doesn't have to be a multiple of 16 pixels high.) than the tiles and one slot in the object array (There are about 70-80 odd slots available.) It's still more tile conservation than memory though.Benvolio wrote:Your sprite idea is obviously a good way to get more graphics into your game. But how would this impinge on memory? Is this still an issue?
Using the 'sprite tiles' at the top of the tileset
Galaxy games have several rows of tiles at the head of the tileset that are used to represent sprites in the level editor. By default these are unusuable in any level editor we currently posses, but they are tiles like all others and can be used in the same way, the only question is 'How?'
Now this is best done at the very end of a modding project as it plays hob with your ability to edit levels (What with all your neat sprite images being replaced with tiles.) Indeed it may even help to keep a sprite-filled tileset for use in main level editing while the tile-filled tileset is used only when adding the extra tiles. As such the tiles stored in this section should be rarely used final touches, that ship you wanted in the boss level, the radio tower in level 6 you didn't have space for and so on.
Now on to inserting those tiles. You will need some knowledge of hex editing to do this. The first thing to do is to open a level in your editor of choice, be it TED5, TOM or something else. Now you will need to add a block of nonsense tiles somewhere that aren't used anywhere else in the levels (So they won't be compressed and confuse things.) This is easier than it sounds, ground tiles out of order will do it. It helps to place as many tiles as you will need new tiles. Take note of the numbers of the first few tiles that you used. Save your level and quit.
Next open the level in your favorite hex editor. (For TED5 this will be maptemp, for TOM the gamemaps file.) Search for those tile numbers you placed. If you did it right there should be only one place where those numbers are. If not... back to the drawing board.
Now we simply overwrite these tile numbers with tile numbers from the 'sprite section' ($01, $02...) and save the file. This will swap out the nonsense tiles we placed as markers with the previously unusable tiles.
Now you can just open the level and select the tiles. Due tot he way various level editors are set up you cannot select sprite tiles from the tileset, but you can select them from the level. You can even copy-paste blocks of them and treat them just like ordinary tiles. (Note you will 'lose' a tile if you delete all copies of it in all levels and will have to reinsert it.)
Again this is not to much of a memory tip or even a tile conservation tip, but rather something to help those whoa re finishing up and find they've run out of space. It helps you get the absolute maximum out of your tileset space. (I myself have only had to use this once, in Xmas 2010.)
See, this is exactly what I've been doing with my tilesets for Cosmo II. I've been trying to remove duplicate tiles to make space for other decorations, as well as making those decorations as neutral and generalized as possible. Unfortunately, it's not perfect, because a few tiles have to be put into a specific order to look proper.
Not only that, there's a very large decoration which takes up most of the space in the masked tileset for Episode 1.
However, there are a few masked tiles worth of space I'm willing to sacrifice for other decoration because of ease of rebuilding them. If I were to take out those tiles and put them in the regular tileset, it would be difficult trying to put them together in COSEDIT.
(Sorry if this didn't make quite as much sense as it should. It's nearing 11:30 P.M. where I live and I'm exhausted.)
Not only that, there's a very large decoration which takes up most of the space in the masked tileset for Episode 1.
However, there are a few masked tiles worth of space I'm willing to sacrifice for other decoration because of ease of rebuilding them. If I were to take out those tiles and put them in the regular tileset, it would be difficult trying to put them together in COSEDIT.
(Sorry if this didn't make quite as much sense as it should. It's nearing 11:30 P.M. where I live and I'm exhausted.)
Some good stuff here; deffo want to use Bernie's idea with the BwB as a sprite, and Lass' idea for the slime hazard is really worth looking into and experimenting with.
Regarding templates: I love templates. It has never been worth it, for me, to not position tiles in template pieces. That said, the default templates in Keen Galaxy, platforms for example, are wretched. Always design your own (not designing from scratch, but rearranging tiles); you'll save space and know exactly what each tile does for you. I've got a condensed platform tileset floating around somewhere.
As a general rule I try to leave at least two rows of tile free when the tileset is 'complete' because there will always be additional things needed when you start level editing. Tile management is about planning ahead.
Regarding templates: I love templates. It has never been worth it, for me, to not position tiles in template pieces. That said, the default templates in Keen Galaxy, platforms for example, are wretched. Always design your own (not designing from scratch, but rearranging tiles); you'll save space and know exactly what each tile does for you. I've got a condensed platform tileset floating around somewhere.
As a general rule I try to leave at least two rows of tile free when the tileset is 'complete' because there will always be additional things needed when you start level editing. Tile management is about planning ahead.