I'd like to request some kinda of internal proc support for animating png and gif files as a whole. Code wise for BYOND you could start from the original plot point, and then have 2 arguments (x)(y) of the oppisite corner to form a box. like the pixel offset, you could just count out how many pixels from the plot point the PNG or GIF is. As of right now you can use PNGs but when trying to move them they still move as 32x32 sqaures.
LJR
ID:136187
![]() Apr 9 2003, 6:46 am
|
|
I think he means using two plus pngs and (for) looping through them all in order to create animated effect.
|
MNG is the animated version of PNG. I don't know how much support the format has, but it does exist.
|
Spuzzum wrote:
Dantom has been planning on implementing MNG for a while, though. You can try a search back. As far as I know, MNG isn't really supported anywhere. What I was planning to do was update the editors to make it very easy to incorporate large PNGs (or BMPs) into movies. They would then be saved as DMIs. |
Tom wrote:
Spuzzum wrote: Hmm. Well, I remember seeing something about MNG somewhere... maybe in ancient release notes or something. |
That would work.. as its what I'm doing manually right now. Takes alone time as of right now, and always chance for something to get unaligned.
Tom wrote: Spuzzum wrote: |
LordJR wrote:
That would work.. as its what I'm doing manually right now. Takes alone time as of right now, and always chance for something to get unaligned. Yup. I just spent the other night creating 15 movies of 64x64 icons, 6 frames each. Only 360 states to copy/paste... That same icon also has 48 static 64x64 states, so it was a fun evening! ;-) What I'd love to see is some sort of DMI software development kit. Release the BYOND graphics code as a compiled C library with documented functions for creating states and movies. Then those of us who are so inclined can write utilities to do just this sort of thing. Since most of my graphics are 3-d rendered, I've got my latest project automated to the point where I can type one command, walk away and come back in a couple hours (less time for a low quality test render) to a single graphic with all 552 icons tiled together. This makes it very nice to allow me to tweak the graphics and re-render without spending too much repetitive effort. It's easy to import that graphic into DreamMaker, which splits it nicely into 32x32 chunks for me. But then I have about an hour or more of cut/paste and renaming states. This is the main reason why I hesitate to tweak any more. All that clicking and keyboarding is a pain (literally, in the wrists)! With a DMI SDK, I could have whipped up a C program to do that, and then tweak til the end of time... But I know that Dantom are freakishly busy trying to make this project profitable. Technical niceties like this will have to wait for now... |
I'm really not sure what you're getting at here.
If you've got a .png on the map larger than 32x32 and it's the image for just one atom, then something is happening in the display algorithm that shouldn't be happening, because there's no built-in support for larger icons yet.
But also what you're talking about is just positioning, not animation. Animation would mean the image itself was changing; .gif supports this but .png doesn't, and I doubt BYOND is gonna get .gif support ever.
Lummox JR