ID:272518
 
How would I go about copying one icon from another, only it adds the other icon's overlays to the new icon permanently?
At runtime? You'd use an /icon object and icon.Blend() or (somewhat differently) with the += operator though it is less recommended.
In response to Kaioken
Hmm, would there be a way of retaining the pixel offsets? Could I save the icon with the overlays as a .png without loosing the pixel offsets?
In response to Smokey Joe
You can always fcopy() the final image... that's how I did the decapitation scene in my hangman game.

What I did was have two states: the wooden area with the guy locked in and the other containing the blade.

I programmed it so that in a loop, each time it is repeated, the blade will go one pixel lower (up to a certain point), Blend() with the OVERLAY argument and DrawBox() a rope colour. This would show the blade falling with a rope in the middle.

After this automation programming, the final modified icon, I fcopy()d it and modifying it by making the head drop off and blood dripping/streaking (manually).

Er, started rambling off again...

Anyways, just fcopy() the icon after Icon.Blend()ing: fcopy(/icon,"File Name.ext")
In response to GhostAnime
Maybe I don't get it, but what the point of fcopy() would be? You can convert an /icon object to an icon file by other means. In fact, it's often done automatically when you try to use the /icon object as an icon.
In response to GhostAnime
Ah, this answers one of my questions, thank you.
But my problem is the blending, after I blend, the overlays appear on the same 32x32 space my icon is. I have swords and junk that take up at least an offset of 20. The real question would be how I keep those offsets while saving them as a file.

This is my system right now;
    var/icon/i = new(src.icon, src.icon_state)
for(var/obj/o in src.Overlays)
var/icon/a = new(o.icon, o.icon_state)

i.Blend(a,ICON_OVERLAY)



usr<<output("\icon[i]", "popup.output")

Which gives me:
In response to Smokey Joe
Naturally pixel_* values don't count when you're adding the icon's image to another icon, which are all 32x32, so it ends up all in the same spot (since you blended it into the same 32x32 icon). Basically you can't really have an icon bigger than 32x32 in actuality and can't automatically save such overlay offsets, that's not how it works. Overlays and their offsets need to be initiated from the code, they can't magically appear just how you want them straight of the icon.
In response to Kaioken
Kaioken wrote:
Basically you can't really have an icon bigger than 32x32 in actuality

I've done .gifs that are about 200x200 and put them straight into the game as mobs using src.icon.

It could just as well be possible to save offsets to a file too. There must be a way
In response to Smokey Joe
Smokey Joe wrote:
I've done .gifs that are about 200x200 and put them straight into the game as mobs using src.icon.

No icon in-game is bigger than 32x32, ever. Even 4.0's new DMI files just get split on runtime. What you said would not work (you'd just get a 1-tile resized thumbnail really) unless I suppose if you laid the mob through the Map Editor on the map, which automatically creates new instances by splitting the image when used with big image files, but you're in actuality going to get multiple mobs (with your 200x200 example, consider a separate mob for every tile taken up, which is around 60) and not one, etc. Like I said in my first sentence, this is just currently impossible unfortunately, and the best you can get with only one atom is pixel-offsetted overlays, which are of course a visual-effect only among other limitations.

It could just as well be possible to save offsets to a file too. There must be a way

Offsets are a code thing, they have nothing to do directly with DMI files. So, no. You could store all the icon(s), but not the actual offsets, though they can still be code-generated easily.
In response to Kaioken
Kaioken wrote:
Smokey Joe wrote:
I've done .gifs that are about 200x200 and put them straight into the game as mobs using src.icon.

No icon in-game is bigger than 32x32, ever. Even 4.0's new DMI files just get split on runtime. What you said would not work (you'd just get a 1-tile resized thumbnail really) unless I suppose if you laid the mob through the Map Editor on the map, which automatically creates new instances by splitting the image when used with big image files, but you're in actuality going to get multiple mobs (with your 200x200 example, consider a separate mob for every tile taken up, which is around 60) and not one, etc. Like I said in my first sentence, this is just currently impossible unfortunately, and the best you can get with only one atom is pixel-offsetted overlays, which are of course a visual-effect only among other limitations.

It could just as well be possible to save offsets to a file too. There must be a way

Offsets are a code thing, they have nothing to do directly with DMI files. So, no. You could store all the icon(s), but not the actual offsets, though they can still be code-generated easily.

Couldn't he just use the Shift procedure on the overlays before he blends them into the icon?
In response to Green Lime
Shift() doesn't change the size of the icon, it just moves all the pixels. If some pixels get off the edge, they are deleted (or with the right argument, shifted over to the opposite side like in Dream Maker's icon editor). Even Scale() doesn't look like it supports the "large DMI files" and as such you can set up (but not edit) from the map editor, if you use it to resize an icon to a size bigger than 32x32 then it will just get separated into icon_states. Though it ultimately doesn't matter, because again, one atom can only have one, 32x32 icon, and one atom takes up one tile (the exception is areas), and you can't change that because that's just how BYOND works, with its tile-based system. You can, of course, use multiple atoms each with a 32x32 icon part to imitate a large object, etc, or use pixel-offsetted overlays.
In response to Kaioken
Where Shift() fails, Crop() triumphs. And I don't believe he was looking for a way to make multi-tiled atoms, just a way to save the overlays, basically...
e.g. F["overlays"]<<overlays
In response to Naokohiro
Now you're bringing up savefiles, which were never discussed, anyway. Apparently he wants to save the complete set of icons (pixel-offesetted overlays and all) in a DMI file, or whatever.
In response to Kaioken
Well, it is possible, but of course, it would be multi-tiled...
In response to Naokohiro
It's not technically possible as he apparently wishes, as pixel_x is an object variable, and therefore isn't saved in uh, icon files. Of course, you can easily store the offsets in the state name and have your code read them and adjust the wanted object's pixel_x/y vars.
In response to Kaioken
You can use Crop() to resize the icon larger thn 32x32, then apply the overlays by shifting them with Shift(), perhaps. (not sure, you might have to do this the hard way), then you can fcopy() it as a normal png, I believe.
In response to Kaioken
It is possible with Crop(). DMIs are basically pngs, so it doesn't really matter as long as he can access the image from the code.
In response to Xooxer
4.0 Dream Maker supports large PNGs, but all in-game icons are still 32x32 (except in the case of images used within HTML of course) only, so even if that works, what I think he's asking for is, well, impossible.
In response to Kaioken
Well, we could stop talking about what's impossible (like you...) and give him a work-around...
Overlays officially do store icons with pixel offsets, so if you maintain access with your code, you can keep the pixel offsets in tact.
In response to Naokohiro
Naokohiro wrote:
Well, we could stop talking about what's impossible (like you...) and give him a work-around...

No reason not to say the truth. I'm not sure if that's quite what he wanted because he was vague, but storing offsets in an icon file is impossible. The possibility of saving them in a savefile, a text file or anything, just like any other value, seemed too obvious to mention, and once he says what exactly he wants you could direct him to what he needs to do or if that's impossible what to do instead. I already said you could have the numbers of the offsets stored as icon_state names (Dream Maker often does this) then have your code loop through them (eg with icon_states()) and act accordingly, but detail is unrequired unless he actually wants that.

Overlays officially do store icons with pixel offsets, so if you maintain access with your code, you can keep the pixel offsets in tact.

This part didn't seem to be very meaningful (or phrased well). Are you saying you can save and load the offsets automatically by saving and loading overlays? Well, you can, but among other things saving the overlays var is bad and bulky anyway.
Page: 1 2