ID:138347
 
Here's my situation:

I have a set of four related icons, each of which has 16 states, each of which has 4 directions.

That's 256 instances of icon. Now I need those in four colors...

I was going to use icon tinting, but then I realized that everytime I created a new object using a tinted icon, I will probably be sending the tinted icon to all players. In this game that will be happening a lot -- enough so that in every tick a player might be receiving 3 or 4 tinted icons.

So:

a) Am I wrong here? Does DM recognize that this new object is using the same kind of tinted icon that's already been transmitted?

b) Could we get an icon copy function? If I could copy the original 4 icons and tint them, then I could just use copies of those everytime I created a new object...

c) or something I'm not thinking of...
On 10/16/00 7:56 pm Deadron wrote:
Here's my situation:

I have a set of four related icons, each of which has 16 states, each of which has 4 directions.

That's 256 instances of icon. Now I need those in four colors...


Oh hey after getting carpal tunnel doing only half the changes for a single color, I realized how I can easily change the color of all directions of 16 states in an icon at once:

Just remap the color table spot for the original color to the new color. Bam, all icon states and directions changed.

Hallelujah!

On 10/16/00 7:56 pm Deadron wrote:

a) Am I wrong here? Does DM recognize that this new object is using the same kind of tinted icon that's already been transmitted?

Yup, BYOND should recognize that. If you tint an icon once, and then do the same thing later on, it will only send that resource the first time. How does it work? Each resource has a unique id based on the bytes in the file. If this id doesn't change, the file doesn't get transmitted.

On the other hand, the server will still have to regenerate the id every time if you make the assignment inside New(). This is not a really intensive operation, but it is unnecessary. So I propose two alternatives:

(1) Do the tinting once, and store the result in globals:

obj/furbee
var/global/iconList[]
icon = 'template.dmi'

New()
if(!iconList) // we haven't created it yet
var/red = icon + rgb(255,0,0)
var/green = icon + rgb(0,255,0)
var/blue = icon + rgb(0,0,255)
iconList = list(red,green,blue)
..()

red_furbee
New()
..()
icon = iconList[0]

Or if this isn't object specific you could just make this iconList global.

Another idea is to just make different icons in the icon_editor. Sure, you don't want to edit all N versions, but that's why there's a palette. Just edit one state, change the colors for a few of the palette entries and miraculously all of your states will change too. This probably won't work too well if your icons have zillions of colors, although you might be able to manage it by:

  • launching your external paint program on your 256 color icon.
  • editing the palette (through whatever color filters you want to use)
  • resaving the icon as a bitmap
  • importing it back in as a new icon
  • saving the palette of this icon
  • importing that palette for your original multi-state icon.

    This will only work if the bitmap saves the new palette in the same slots as the original. I believe it does.
In response to Tom H.
On 10/16/00 8:20 pm Tom H. wrote:
Another idea is to just make different icons in the icon_editor. Sure, you don't want to edit all N versions, but that's why there's a palette. Just edit one state, change the colors for a few of the palette entries and miraculously all of your states will change too.


Yes I will probably keep it this way for now -- but I will ALSO use the nice icon list idea (I was assuming that changing icon state of one in that case would change it for all...but it doesn't sound like it).

It will simplify my life.