The original .zip can be found here: http://s95013793.onlinehome.us/byond/users/rob/ icon%20scaling.zip (it doesn't have a large .rsc file there)
Ah, I was wondering what you could possibly be hiding in that large rsc to make matters simpler. ;)
It scales them horizontally and vertically (separately), taking a strip of the icon and blending it to a new icon. The procs then return the list of new icons and it creates the overlays.
As I noted in my response to Loduwijk, that's a very nice solution. I didn't really think that critically about the process.
Very clever! Using 64 to 128 slice passes instead of 1024 pixel passes cuts out a great deal of the overhead, though I'd still rather do it with only 1 to 9 icon operations with all the calculations handled as non-icon data.
You can use negative pixel offsets as well, expanding a couple icons in each direction. Pixel offsets act pretty fruity beyond +/-92, so you can't go further than that. You could really push it to 224x244 pixels with +/-92 if you wanted to.
I limit myself to +/-64 (5x5 tiles) for a total size of 160x160 pixels. I had to think a bit to recall why I prefer these limits. The reason is that an atom's pixel offsets are a factor as well. If the atom's offset + the overlay offset goes beyond the limits, the display breaks. Limitting my atom offsets to 0-31 and my overlay offsets to -64 to +64 guarantees no offset related problems. (I could get away with -92 to 64, but why complicate things with lopsided images?)
Here is a quick demo so you can see for yourself: