I am wondering about the viability of using Crop() in-game and how much consideration I should have for caching or performance.
Essentially here is the idea obfuscated enough that you couldn't figure out the game I'm REALLY working on, cause this ain't it =D :
Let's say you have an old-school turn-based RPG - you know, the kind with big portraits of the enemies, like FF1-6, Dragon Warrior, or pretty much anything else. In these games, you have a number of these portraits for every kind of enemy in the game.
What if you had to squeeze a TON of these portraits into a small area - but you didn't really want to Scale() them down (in fact, how intensive is THAT? :P). Instead, what if you could crop them to some dimensions, based on the situation, so you could still see enough of the creature to identify it, but could still shrink the portrait substantially.
The question is - how fast is Crop()? It would of course be foolish to do it per-fight - but could I anyways? The better solution would be to Crop() images and cache them at the same time, so they can be reused when those dimension requirements come up again. The "best" solution, however, would be to simply run a giant batch cropping on every image, to each size necessary (of which there could be tons) and store them all as resources.
Of course, the problem with that is that is that if your packaged BYOND game is over 2 megabytes, you suck. At least according to SilkWizard. This technique would drastically (and exponentially) increase the file size as new portraits were added.
What are your thoughts?