I have a very beta FLIC animation datatype I'm writing for OS4. This is my first animation datatype, and I'm using a "from scratch" FLIC decoder.
For various reasons the whole thing is horribly inefficient, Multiview skips most frames, mid-anim palette changes won't work and only FLIs are supported (the chunks used in the more common FLC format are giving me grief).
Because this is all new, I'd like to test what is there currently with more than the one FLI I have available (which seems to be working - slowly - mostly without crashing).
If anybody knows of a source of FLIs and/or can download the above datatype and test to see what works and what doesn't I'd be grateful.
Updated 31/05 I fixed the problem with the FLC chunks (by accident!), above link now supports FLCs (at least works with BillE's link below) and has marginal speed improvements. Still skips most frames though.
Updated 01/06 Caching now working (palette changes probably not working again), now playing at a decent speed except when there is a crazy framerate set in the file.
Thanks Chris
todo: fix seeking backwards through files (goes a bit mental and crashes) fix palette changes mid-anim
Edited by Chris on 2008/5/31 17:14:51 Edited by Chris on 2008/5/31 17:15:12 Edited by Chris on 2008/6/1 13:48:56 Edited by Chris on 2008/6/1 14:38:36
Since you made some changes since my post, please let me know what you want done re:testing at this juncture.
One correction on my email. The particular pair of pacman FLI/FLC were made by MainActor from the following anim on aminet, and not an .mpg as I stated in the email. The balance, though, were FLI/FLC in original state as found.
All the samples played properly under OS3.x with Mainactor, as well as the FLIs only with the P96 utility "FLIP". XANIM also played them properly, iirc.
Just a quick comment about the API, there seems to be a little confusion as to what exactly alf_Frame and alf_TimeStamp actually mean, particularly for variable frame-rate formats such as animgif. My understanding is that they are exactly the same thing, except one is an input, and the other is an output. Thus, even though frame 10 in the file may be shown for 5 frames, these five frames are treated as separate timestamps and separate frames by the animation datatype.
That's how I've been using them, fortunately FLI/FLC doesn't have the concept of variable rate frames, although I'm curious as to how these are supposed to be supported by animation.datatype. There's a Duration field, but I can't see any information on what is supposed to go here (I've been setting it to 1, as in duration: 1 frame)
I found the bug causing some of those files not to play. For some reason I'm not reading the exact amount of data contained in the chunk somewhere (so it's reading into the next chunk, or stopping before the end. I need to find out where this is happening, but in the meantime I've put an extra file seek to place it at the start of the chunks each time.
I've updated the archive again, they all work now. However, digifly seems to crash it here, as does mobicogs (which is on Aminet). This may be related to the file positioning bug above, if it is wandering off into memory, or it might be due to the complexity of the files and the slowness of my decoding routines.
Seeking back/forth is sometimes crashing it as well, seems to be reading random data rather than looking for the correct frame in some cases.
If you can try and reproduce the crashes, that might be useful. I've built it with debug symbols this time so crashlogs might track them down. It seems to be completely freezing here when closing Multiview after (attempting to) play those two files.
That's how I've been using them, fortunately FLI/FLC doesn't have the concept of variable rate frames, although I'm curious as to how these are supposed to be supported by animation.datatype. There's a Duration field, but I can't see any information on what is supposed to go here (I've been setting it to 1, as in duration: 1 frame)
Basically you set a base frame-rate (100 fps for animgif) and duration is how many "frames" a single image should be shown. The animation datatype uses that information in order to avoid loading the same frame several times.
MPlayer (Leitmotiv) with GUI gave me correct graphic transistions.
MPlayer (Leitmotiv) from shell (with huge stack recommended by afxgroup) gave me a lengthy error report on what it could not determine, followed by not 1, but 2 grim reapers.
Different still with your datatype.
I'm particularly curious about the MPlayer difference in behavior from shell vs the GUI...
I've updated the archive again, they all work now. However, digifly seems to crash it here, as does mobicogs (which is on Aminet). This may be related to the file positioning bug above, if it is wandering off into memory, or it might be due to the complexity of the files and the slowness of my decoding routines.
Where did you get the FLI/FLC version of mobicogs from? The mobicogs on aminet is a HAM6 anim.
MPlayer (Leitmotiv) with GUI gave me correct graphic transistions.
MPlayer (Leitmotiv) from shell (with huge stack recommended by afxgroup) gave me a lengthy error report on what it could not determine, followed by not 1, but 2 grim reapers.
flxplay appears to have the wrong colours, this might be because that anim changes the colour palette every frame, or uses the entire palette and SDL/OS4 is taking over some of the pens itself.
MPlayer plays it correctly, from GUI and Shell.
The Datatype is playing it correctly but at a much reduced frame rate, that's next on my list. (edit: done, but now has the same colour problems as flxplay)
Chris
Edited by Chris on 2008/6/1 13:47:27 Edited by Chris on 2008/6/1 13:49:58
flxplay appears to have the wrong colours, this might be because that anim changes the colour palette every frame, or uses the entire palette and SDL/OS4 is taking over some of the pens itself.
MPlayer plays it correctly, from GUI and Shell.
The Datatype is playing it correctly but at a much reduced frame rate, that's next on my list. (edit: done, but now has the same colour problems as flxplay)
Chris
Are you passing the animation datatype the updated colour map every time a frame changes the palette? If not, have a look for the animgif datatype does it.
Agreed. This was the only place where our test results differed. Seems in shell MPlayer Leitmotiv will crash with a .fli without the use of the -vo sdl parameter, something that does not happen with an .mpg for example.
Not that this source will be any help, but here's another fli/flc player that worked reasonably under OS3.x: