Icon proc Frames

ID:1304439
 
Jun 27 2013, 5:56 am (Edited on Jun 27 2013, 8:10 am)
Applies to:DM Language
Status: Open
Issue hasn't been assigned a status value.
I would like to suggest the addition of a built-in icon function icon.Frames(icon_state).

It would return the amount of frames an icon_state has.

Currently, it can be done with counting the pixels by calling icon(icon,icon_state,dir,frame)and checking the frame if it has any pixels, which are not null, therefore it would continue to check the next frame until you get a blank frame, it would then return the frame count.

The problem with that is that if it encounters a blank frame, but an up coming frame is not blank it will not read on and returns the current count.

It can be fixed with a fail-safe, which allows you to check further frames if they are in use, but this would use up more processing power.
Jun 27 2013, 8:00 am
It seems like the internals would most definitely have access to the number of frames for a given state, so this should be made available to the developer. Something like .Width() or .IconStates() as OP has suggested.
Jun 27 2013, 9:18 am
That could be useful in runtime icon generation, however slow it may be. It should be a rule that whatever values you are able to change, you should also be able to check, otherwise you are just left in the dark.

I would also suggest adding an icon.Delays(icon_state) proc, that would return all of the decisecond delay values in an icon state, in params format. For example, if the icon state has 6 frames, the result might look like this: "2;4;1;3;2;1". These would of course be in the respective order of the frames.
Jun 27 2013, 9:21 am
In response to Multiverse7
Yup, I would definitely agree on that. Considering that I love to make use of dynamic-icons and their generation by various means. Especially since there is no built-in particle system, we can get a similar end result by doing an icon generation to get the effect.
Jun 27 2013, 9:33 am
I don't have too much experience with icon generation yet, but I know that if these procs are outsourced to the client side one day, they will be infinitely more powerful and useful. So even though they are not lightning fast right now, I do plan to conquer them.
Jun 27 2013, 9:37 am
icon.Frames(icon_state)

would return a list

The length of the list is the number of frames, and each index in the list is the frame delay of respective frame.

L[1] = 0.5 //frame 1, 0.5 frame delay
L[2] = 0.5 //frame 2, 0.5 frame delay
length(L) = 2 //the number of frames
Jun 27 2013, 9:40 am
In response to FIREking
Would work either way, as long as we get the information it doesn't particularly matter in what form. Although yes getting it returned in a form of a list with that kind of output seems more ideal.
Jun 27 2013, 9:56 am
Yes, I guess that would make more sense to have an associative list returned. I would just hope that doesn't mean a slower proc. Although, depending on how you are using it, it can be more efficient to grab more information with a single call.

Anyway, just imagine what you could do with the ability to get frame delays. You could generate faster and slower versions of any icon on the fly, so you could for example have awesome slow motion effects!
Sep 26 2013, 3:16 am
*cough**cough* I must insist on this being added, it would prove to be invaluable when processing icons.
Sep 26 2013, 3:04 pm
You can use my DMI Icon Info library to get this information. It's not ideal, but works for the interim.
Sep 26 2013, 5:24 pm
In response to DarkCampainger
I can get the info, but it would be more ideal to have it as a built in function due to the difference in performance.
Mar 17 2019, 5:56 pm
I'd like to bump this post, as this feature would be useful to me.