How fast is Crop()? in Design Philosophy

ID:151621
 
Dec 14 2009, 5:59 pm
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?


~Polatrite~
#1 Dec 14 2009, 8:41 pm
Polatrite wrote:
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?

One thought is that none of those methods actually help the file size. If, at runtime, you use a dynamically edited icon for something, then sure, it won't enlarge your project's main RSC file, but it goes to a separate cache (.dyn.rsc), and it still has to be sent in whole to every player that sees it anyway - only worse, it has to be sent while the game is being played (unless you configured preload_rsc to send it on-join, which is still worse than being package-distributed).
#2 Dec 15 2009, 12:09 am
Eh, I don't see why added PNGs should drastically increase file size to the point where a Crop()-based method is necessary. If you're worried about size, maybe consider your PNG's format. For example, BYOND supports PNGs with color palettes, so you might save on file size that way. As said though, a large packaged RSC and a large dynamic RSC only differ in the fact that the players need to download the dynamic stuff at runtime, bogging down the server and decreasing the overall experience.

If you want to do the Crop() method, I would definitely cache the results.
#3 Dec 15 2009, 7:00 am
In response to Kaioken (#1)
Kaioken wrote:
One thought is that none of those methods actually help the file size. If, at runtime, you use a dynamically edited icon for something, then sure, it won't enlarge your project's main RSC file, but it goes to a separate cache (.dyn.rsc), and it still has to be sent in whole to every player that sees it anyway - only worse, it has to be sent while the game is being played (unless you configured preload_rsc to send it on-join, which is still worse than being package-distributed).

Hah! A silly lack of thought on my part. And yes, you're quite right, downloading resources on the fly is great from a functional perspective, but awful as a player.


~Polatrite~