In fact after the latest SDK update, gdb tends to be really unreliable on my system whereas I was pretty solid before. It seems that almost every time I try to attach a crashed process to gdb via GrimReaper either my whole machine hangs, either gdb prints strange error messages asking to contact GNU authors... Really annoying, so now when a program crashes I reboot, launch a shell, then relaucnh the soft inside gdb and try to reproduce the crash (most of the time I'm unable to
@TetiSoft
Was just reading the CatComp documentation and found a (very) small problem in it but I guess this comes from CVS : Quote:
The above will embed "$VER: myprogram.catalog 39.1 (31.7.92)" inside of the message catalog.
See the incoherence in the date ? Also two lines above where the format is presented CVS seems to have expanded it so one won't see the format but two times an example...
The above will embed "$VER: myprogram.catalog 1.13 (5.2.2007)" inside of the message catalog.
The problem is that CVS modifies the rcsid part od the file each time an update is checked in, so dont wonder when minor glitches (wrong revision or date) will appear again in future
Years ago there were promises of updated ROM Kernel Manuals. They haven't been updated since 2.04 (over 15 years ago), it is now 4.0, they are in dire need of updating.
They don't need to be released in hardcopy of course, softcopy versions would do.
In particular some detailed ReAction coverage would be welcome.
Note that doing a SDK is a huge task. If anybody can help writing docs, writing example codes, it will be appreciated by everyone. Please send your work to os4-sdk on hyperion-entertainment dot biz
It seems those SysList functions dont exist and adding such a description to the autodoc was a mistake, the current autodoc doesnt mention such functions anymore, the example uses Forbid().
Ok thank you for the information. Altough that was IMHO a good idea to have such functions, because as I understood it (and my version of autodocs is stating) the Forbid/Permit couple is something to avoid and can also cause problem parallel computing environment.
I've found another item that could use a big update. The datatypes documentation. For example, the animation_dtc autodoc lists the methods that an animation datatype has, but not what arguements they take, etc. That documentation seems to be embedded in the datatype source-code for datatypes released with source. Even then, there are tricks such as alf->alf_UserData possibly pointing to a previous frame that should be unloaded.
For the benefit of both datatype users and implementors, these details really should be moved out of example source-code and into the docs. Also the base datatype class has no autodoc, and hence no documentation on its methods.
animation_dtc autodoc lists the methods that an animation datatype has, but not what arguements they take
Aren't tags enough? Or I misunderstood you.
No, they're not enough. Take ADTM_LOADFRAME for example. The msg parameter (arguement) is supposed to be a pointer to a variable of type struct adtFrame and alf_TimeStamp within the passed struct is supposed to be set to the desired timestamp. Without this information, you can't use ADTM_LOADFRAME, or write a datatype that has an ADTM_LOADFRAME method. The autodoc simply lists the valid MethodIDs, not what the parameters and return data are for the methods.
Difficulty in finding this information is probably one of the biggest reasons why we have so few datatypes.
Take ADTM_LOADFRAME for example. The msg parameter (arguement) is supposed to be a pointer to a variable of type struct adtFrame and alf_TimeStamp within the passed struct is supposed to be set to the desired timestamp. Without this information, you can't use ADTM_LOADFRAME, or write a datatype that has an ADTM_LOADFRAME method. The autodoc simply lists the valid MethodIDs, not what the parameters and return data are for the methods.
The autodoc is only a part of the SDK. The include files also contain comments for human readers. <datatypes/animationclass.h> contains Quote:
which clearly eplains that this structure has to be used with this methods, and the structure itself starts with Quote:
ULONG MethodID; ULONG alf_TimeStamp; /* Timestamp of frame to load */
/* The following fields are filled in by the ADTM_LOADFRAME method, */ /* and are read-only for any other methods. */
which IMHO clearly explains that besides the MethodID alf_TimeStamp is the only field to be filled out by the caller, and what else than the desired frame could be specified by this field?
Quote:
Difficulty in finding this information is probably one of the biggest reasons why we have so few datatypes.
IMHO the current datatypes system is too limited and too slow for modern animation formats, thats the reason why everybody writes custom animation players instead of a datatype which would allow to use MultiView for viewing DVDs etc.
The autodoc is only a part of the SDK. The include files also contain comments for human readers. <datatypes/animationclass.h>
I've been using the headers as well, but the information is not as clear as you think. There is no definite, "here are the input parameters, this is what is output" documentation there, although it's all implied. Moreover, people starting out don't think to look in header files. A lot of people put their documentation in their .c files instead of the header where it should be.
Quote:
TetiSoft wrote:
IMHO the current datatypes system is too limited and too slow for modern animation formats, thats the reason why everybody writes custom animation players instead of a datatype which would allow to use MultiView for viewing DVDs etc.
While experimenting with the gif anim format, performance in Hollywood increased dramatically the moment I enabled 24-bit bitmaps. Unfortunately, the animation datatype can't handle those. The performance issue seems to be because the datatype converts from chunky to planar and then to display it, you have to convert back to chunky again.
Regarding the limitations, I agree that adding support for truecolour bitmaps, streaming, encoder prefs menu popup, etc. would make the datatypes much more useful. Looking at the animation datatype itself, I think that it could easily be improved and extended. There was a group several years ago that were going to attempt this, but it died. It's all a matter of a group getting together and officially extending it.
Even if you use custom viewers for watching, datatypes would still be useful for reading manipulating and saving datatypes. I'd be interested in helping out with advancing the datatypes, the animation datatype in particular.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
