I remember someone mentioning something about rewriting one of these two libraries to cache icons. Did anyone ever actually end up rewriting it?
I'm looking for it to try to cut down on unnecessary processing in my games, so if anyone has any information, it'd be greatly appreciated! Thanks.
ID:103400
 Oct 18 2010, 3:36 am
|
|
|
Oct 18 2010, 3:40 am
|
|
Toadfish
 |
Lummox mentioned it and didn't. But it's easy to do yourself so how about you write something and release it?
|
Toadfish wrote:
Lummox mentioned it and didn't. But it's easy to do yourself so how about you write something and release it? I wanted to make sure it wasn't already done, so I figured I'd ask. Plus, I have an idea of how to do it, but I'm not really sure how caching would work, specifically. I was just thinking of keeping an associated list of everything that was generated. | |
A list works. You also want a setting that determines whether a configuration will be cached though (f. ex. in the case of randomised color setting, it'll be a waste of memory to cache).
| |
Another valuable feature to have is the ability to save a .dmi of certain configurations. This could be used in the case of oft-used settings, such as for damage to hit points.
| |
I'll review this and see. Gives me an opportunity to trial some more comprehensive documentation as well. No promises. Incidentally, which API would you prefer, f_damage or s_damage?
| |
Stephen001 wrote:
I'll review this and see. Gives me an opportunity to trial some more comprehensive documentation as well. No promises. Incidentally, which API would you prefer, f_damage or s_damage? f_damage has a lot more features than s_damage (such as a longer scope of numbers, and the neat effects), so I'd have to say f_damage. | |
I'm close to something release-worthy but I haven't had much chance to work on it lately.
| |
