ID:259999
Jul 17 2005, 9:41 am
|
|
I was just thinking how it would be nice to be able to set separate delays between frames in a dmi animation, rather than using one set delay. I don't think this would make dmi files much larger, as i think it would be balanced out by removing the need to create like 10 of the same frame to create the desired delay before a small, short, and fast animation at around the 11th frame.
For example, consider the following: Now: state1 - delay 1 - state1 - delay 1 - state1 - delay 1 - state2 - delay 1 After suggestion(if accepted): state1 - delay 3 - state2 - delay 1 By needing only two frames for this animation(as opposed to 4), I would think that this may reduce the size of dmi animations, especially in the case of animations with many more frames RD | |
|
Jul 18 2005, 6:03 am
|
|
Jamesburrow
 |
Not that I really bother with .dmi files that much, I second this suggestion. It does sound like ti would make things easier.
|
Rurouni Dragon wrote:
I was just thinking how it would be nice to be able to set separate delays between frames in a dmi animation, rather than using one set delay. I don't think this would make dmi files much larger, as i think it would be balanced out by removing the need to create like 10 of the same frame to create the desired delay before a small, short, and fast animation at around the 11th frame. I agree this would be a very nice feature. It would change some existing functionality but I'd be okay with that. Tom is presently working on a new .dmi format that's basically a form of .png, finally moving us out of the era of 256-color icons. (Huzzah!) This sort of flexibility might be a great option for that. Lummox JR | |
yeah, this would be a great feature =).
O-matic | |
The old form will still be supported, I hope. That would be quite a blunder to update to a new format then look back and say "Oops, all the old games aren't going to work now."
| |
Loduwijk wrote:
The old form will still be supported, I hope. That would be quite a blunder to update to a new format then look back and say "Oops, all the old games aren't going to work now." Naturally it will be supported. Maintaining backwards compatibility won't be hard. If you look at some old games you'll even find some examples of the version 3 .dmi format, vs. the standard .dmi version 4 used by BYOND for 4+ years. Lummox JR | |
Lummox JR wrote:
Tom is presently working on a new .dmi format that's basically a form of .png, finally moving us out of the era of 256-color icons. (Huzzah!) Awesome! That brings us one step closer to being able to use the alpha channel... assuming the new DMI format keeps PNG's alpha capabilities. =) | |
Crispy wrote:
Lummox JR wrote: As I understand it it has been Tom's intention for some time to go for a 25-bit format, rather than full 32-bit. Odds are it'll use 32-bit encoding but will just use the MSB of the alpha channel. Lummox JR | |
Makes sense (once I figured out that MSB meant most significant bit - at least I think it does =)). I didn't expect that BYOND would actually draw the translucency; but if the format already supports it, future use of the alpha channel becomes that much simpler to implement.
Not that it is simple to implement.... but hey, I can dream... =) | |
