I was trying to use the icon proc Shift() to offset an icon such that it would now occupy both the obj's current loc and an adjoining loc, but when I run it nothing shows up in the adjoining loc.
var/obj/Tc // Tc is just a 32x32 black square
var/icon/I = new(Tc.icon)
I.Shift(NORTH,9) // tried w/ 9, 18, 27, and 36
Tc.icon = I
My impression from the help on Shift is that if you have wrap = 1, the pixels would wrap to the other side of the same loc, and if wrap = 0, they would move on to the adjoining loc, NOT disappear.
However, unless there's a bug in Shift(), I need a new approach to accomplishing this. Any suggestions?
Thanks!
ID:148793
Sep 27 2002, 6:30 am
|
|
In response to Lummox JR
|
|
Lummox JR wrote:
atom.pixel_x and atom.pixel_y are just what you need. yep, that did the trick... thanks! on a related note, can I add either obj.icon overlays or obj overlays which are located in a different (adjoining) tile than the obj itself? If so, would they all shift with the one atom.pixel_x or _y setting, or would this need to be set for each image individually? For context, I'm creating a game board out of hexagons, and each hexagon occupies a total of 9 tiles (3x3). I suppose it might be easiest to just use larger image files and let DM break it up into icon states, but I'd prefer to get it working with 9 different icons in an icon file. (The reason it's 9 instead of 4 is that the hexagons are not a solid color, but will have a non-symmetric graphic). |
In response to Dramstud
|
|
dramstud wrote:
Lummox JR wrote: The overlays' pixel_x and pixel_y settings will be added to the main atom. You can shift pixel_x or pixel_y up to ±32 total (that is, overlay.pixel_x+src.pixel_x) and safely be sure the overlay/atom will be in view; shift any further, and it may or may not appear properly. For context, I'm creating a game board out of hexagons, and each hexagon occupies a total of 9 tiles (3x3). I suppose it might be easiest to just use larger image files and let DM break it up into icon states, but I'd prefer to get it working with 9 different icons in an icon file. (The reason it's 9 instead of 4 is that the hexagons are not a solid color, but will have a non-symmetric graphic). If the center atom is offset, and the overlay is offset by 32 in the same direction, you might run into a display problem like I mentioned above if the center atom goes off-screen by more than 1 tile. Otherwise, though, it should be fine. Lummox JR |
Nope; this only affects the icon, not its placement on the screen. The icon bitmap is just a picture; it has no inherent location. The atom you assign it to, however, does have a location.
atom.pixel_x and atom.pixel_y are just what you need.
Lummox JR