CompuServe Messages

Anim.Player Dev. Kit

    07-Dec-94 11:20:36
Fm: Jonas Ruikis [ADESK] 73172,1351
To: Andrew Wiltshire 100332,613
Hi Andy, << (Drum of fingers :-(( ) wait zzz zz z ….. All I want to know is what is 'What is shipped in the product?' >> Well…. The kit contains the Animation Player For Windows Developer Kit This set of programs allow you to write Visual Basic or C programs under windows calling the player .DLL. Animation Support Libraries This allows you to write stand alone programs under Dos to read/write/display flics. Here's the README… ————————————————————– Animation Support Libraries README.DOC July 9, 1992 Updated: April 30, 1994 This readme file contains information about: – Installing the Animation Support Libraries – Compiler Support for POE and PDR – Porting FlicLib to Other Compiler and DOS Extenders – Two New .PDR Files Installing the Animation Support Libraries ========================================== The Animation Support Libraries (ASL) are the Developer Kit Disk 1. To install ASL, we suggest you note the following instructions: 1. Insert Developer Kit Disk 1 in drive A 2. Type A:\INSTALL at the DOS prompt 3. Follow the instructions on the screen You will be prompted to specify the drive and directory at which to install the ASL files. Alternatively, you can also install ASL from within Microsoft Windows. Specify A:\INSTALL.EXE in the RUN command under the FILE pull-down menu of the Program Manager, and then follow the instructions on the screen. Please note that the above instructions will install only the ASL files. Animation Player Developer Kit files are also found in the Developer Kit Disk 1 (and Disk 2), and must be installed separately. This is accomplished by invoking AASETUP.EXE from within Windows. Refer to the README.DOC file for Animation Player Developer Kit found in Developer Kit Disk 2 for instructions. Compiler Support for POE and PDR ================================ The POE (Poco Executable) and PDR code have been developed and tested using the Watcom C/386 (v8.0 and v9.0) compiler and the Phar Lap DOS extender (v3.0). See the next section for information about FlicLib and compiler support. Porting FlicLib to Other Compilers and DOS Extenders ==================================================== The FlicLib code has been developed and tested using the Watcom C/386 (v8.0) compiler and the Phar Lap DOS extender. It has also been tested with the Intel CodeBuilder DOS extender. It is quite likely to be compatible with other compilers and extenders, but this has not been tested. The following paragraphs contain notes that can help you port FlicLib to other environments. For compatibility with CodeBuilder, FlicLib assumes parameters are passed on the stack rather than in registers. A new version of the library supports clients using the Watcom -3r calling standard (parameters in registers), but internally the -3s convention is still used. A set of Watcom #pragma statements are used in the pj*.h header files to inform the -3r client code that the FlicLib functions must be called with the -3s parameter conventions. There is no practical way to convert the FlicLib to use register parameter passing internally, short of recoding all the assembler routines at the deepest level of library internals. The assembler source code assumes Watcom -3s conventions: -The compiler does not prepend an underbar to global data item names. -Any routine can modify the EAX, ECX, and EDX registers, but must preserve other registers (including all segment registers). -The caller cleans up stacked parameters. -Values are returned via the EAX register. -The processor direction flag is assumed to be cleared at entry and exit of any routine (i.e., CLD is always in effect.) Compatibility with DOS extenders other than Phar Lap should be relatively easy to achieve. The existing Phar Lap libraries should already be compatible with the Ergo DOS extender, but this is untested. The target extender's environment must meet some conditions before you consider a port to it: -The DS, ES and SS registers always contain the same value (i.e., flat model addressing). -The GS segment register is used extensively within FlicLib. The extender must place no restrictions on use of this register, and other code must preserve this register if using it. -The extender must provide a segment descriptor that maps the first megabyte of real memory (DOS memory) as a linear address space. The mapping must include the video and hardware address range (i.e., address 0x000a0000 points to the VGA video page, 0x000c0000 to the video BIOS, etc.). Whenever FlicLib needs access to DOS memory or the hardware address range, it uses the value in the GS register. This allows fast access to the BIOS clock, the video hardware, and so on. The library routine pj_set_gs loads the GS register. The video driver and clock initialization routines call this function to ensure that GS is set up with the right value for DOS memory access. They expect that the value in GS never changes throughout the run of the program. As implemented in the Phar Lap versions of the library, GS is loaded with the value from DS, and then the value 20h is added to it. Under both Phar Lap and Ergo, this process results in a segment descriptor that maps the first megabyte as a linear address space. In the CodeBuilder version of the library, the value from the DS register is copied directly and unmodified into GS. CodeBuilder's DS descriptor already maps the first megabyte of memory directly. The pj_set_gs function is in LIBSRC\GLUE_xx\setgs.asm. This is the only place in FlicLib that makes a direct reference to an extender-specific memory descriptor. To port FlicLib to another extender, re-code the functions in setgs.asm as appropriate to the target extender. (Comments in setgs.asm provide more details.) There are three modules within the FlicLib source that make calls to extender-specific functions: -LIBSRC\UTIL\doserr.asm -LIBSRC\VESA\xxralloc.asm -LIBSRC\VESA\xxint10.asm The pj_doserr_install and remove_handler functions are in doserr.asm; if you don't explicitly call these functions from your code, you won't need to modify them. The VESA driver uses several extender-specific calls to communicate with the VESA BIOS, which runs in real mode. You have to do some rewriting in these modules if you want to use the VESA video driver with another DOS extender. Comments in the existing modules give more details on this. Two New .PDR Files ================== Two .PDR files (file format converters) have been included on disk 1 in the \POE\PSTAMP directory. The files are BMP.PDR and PICT.PDR. Place the files in your Animator Pro \RESOURCE directory to add BMP and PICT file support to the file formats already supported by Animator Pro. You will need to have these two .PDR files in your \RESOURCE directory if you intend to use all of the features in the \POE\PSTAMP example application.