My animation datatype works correctly when I use RGBFB_CLUT P96 bitmaps with 256-colour colormaps, but when I try to use RGBFB_R8G8B8 with ADTA_Depth set to 24 and no colormaps (set to NULL) it displays nothing and crashes when I press play in Multiview.
Does this mean that animation.datatype doesn't support true-color but only colourmapped chunky or planar?
Also tried RGBFB_A8R8G8B8 with ADTA_Depth of 32 with same results...
Can anyone confirm that this is the case? I.e. that animation.datatype doesn't support hi/truecolor graphics.
Also is anything being done to improve the base datatype classes?
F.e. add truecolor support to animation.datatype or add 16-bit and maybe also 32-bit support to sound.datatype?
I posted this... elsewhere... but as well as 16-bit and proper streaming support for sound.datatype, we also need the following classes: Drawing: for 2D structured drawings (IFF DR2D etc) Object: for 3D objects (Lightwave etc, not sure if there is any IFF standard) Music: for music modules, MIDI files etc (this already exists as a defined class, but there is no datatype superclass corresponding to it) There are probably others...
Datatypes could also do with the ability for individual datatypes to add some form of interaction, so if you have (for example) a Flash animation datatype, you could listen to the mouse clicks, keyboard input and change the display accordingly. This only needs to be supported for embedded objects of course.
My experimentation with the gifanim confirms what you're saying. If I override the GM_RENDER method, it no longer crashes (until I click on the invisible tapedeck.gadget object that the datatype contains) so the bug is somewhere in the GM_RENDER code for the animation datatype.
I hope that this will be fixed soon. Unfortunately, I have no idea who is maintaining the animation datatype, so I don't know who to contact.
Why is animation.datatype still v44, even though it is PPC native code?
Because there exists a third-party v45 version and we dont believe that all programmers were clever enough to use v45 functions only with v45 and not with v52...
Similar reasons are responsible for the version numbers of e.g. sound.datatype and Installer.
srupprecht wrote: animation.datatype does not support bitmaps deeper than 8bit.
Ok, that explains why it doesn't work. Is this going to change any time soon?
Hans
EDIT: Should I consider writing a video datatype for truecolour video data? Or is extending the animation datatype planned?
Any idea what's happening with the sound datatype? Someone uploaded a replacement on os4depot that supports 16-bit multi-channel sounds. Will an official extension with those features occur?
Edited by Hans on 2007/3/11 17:27:18 Edited by Hans on 2007/3/11 17:45:49
Why is animation.datatype still v44, even though it is PPC native code?
Because there exists a third-party v45 version and we dont believe that all programmers were clever enough to use v45 functions only with v45 and not with v52...
Similar reasons are responsible for the version numbers of e.g. sound.datatype and Installer.
Where can I find this third-party version? I've managed to find a version 41.6 on the aminet.
Sorry, it seems I've mixed that up with datatypes.library where a third-party v45 version existed. No idea why animation.datatype is still v44, maybe we simply forgot to bump the version. Hints welcome
Some extension in OS3.9, whereas the OS4 version is based on OS3.5 sources?
According to my 3.9 installation, the releasenotes in the 3.9 SDK and the OS4 releasenotes, the latest pre-OS4 version was v44.18 (OS3.5), could not find a newer OS3.9 version.
I ported the v41 sound.datatype over to OS4 a while back, think I might still have it left here. I didn't release it though because of some small problems.
Also I had to remove most of the 16-bit sound code because I couldn't find the #defines anywhere IIRC.
As for the sound.datatype on OS4Depot, that one would have been nice in my opinion. Unfortunately the author seems to have disappeared.
It would also need a version bump so it would be possible to support the new features without breaking compatibility with the OS sound.datatype.