Actually, the library is quite different from the first version we released in June 2006. The only common point is that the author of this library is Seb/The Removers.
Indeed, I have worked hard to give a nice C interface to my library. Thus, it should now be easy to interface your own code (written in ASM or C) with my library. I will get into details of interfacing below.
The display structure is an essential component of the library. A display is a sprite container which is organized in layer. The maximal number of layers is 16. The layer are displayed on screen in ascending order so that layer 0 corresponds to the background and layer 15 corresponds to the foreground. A display have coordinates on screens (display::x and display::y). At most one display may be viewed at a time.
You can put sprite in a display at the layer you wish. The sprite structure is a convenient way to manipulate OP sprites. A sprite can have arbitrary coordinates (sprite::x and sprite::y) relative to the display they belong to.
The sprite can be unscaled or scaled (sprite::scaled), visible or not (sprite::visible), animated or not (sprite::animated). They may have a "hot spot" different from the left upper corner (sprite::use_hotspot, sprite::hx and sprite::hy). An animated sprite is described by a simple array of animation_chunk.
All the tedious details of the sprites are managed by the display manager. The display manager uses a GPU routine for maximal performance. It includes also a simple yet practical GPU subroutine manager. The display manager should be initialised before use by calling the function init_display_driver. You can then create a display with the function new_display. You can then fill the freshly created display with sprites with attach_sprite_to_display_at_layer. To show the display, you then simply have to call show_display. It is also possible to remove easily a sprite from a display with detach_sprite_from_display, change the layer of a sprite in a display with change_sprite_layer. You can even sort a layer of a display with sort_display_layer so that you control the order of display in a same layer.
To use the collision routine, you have first to use the display manager. Then, you have to initialise this routine with the function init_collision_routine. This last function copies the GPU subroutine is GPU ram at the address you give (for example &_GPU_FREE_RAM). You can then launch a collision test with launch_collision_routine and asynchrounously get the result of the test with get_collision_result. The collision routine not only determines if the two transparent sprite collide but also if their bounding box intersect.
To manipulate the frame buffers, some 2D operations are implemented in fb2d.h. The 2D frame buffer manager is still ongoing work. With this manager, you can copy a rectangular area of a screen into another screen with the desired copy mode. This is done achieved with the function fb2d_copy_straight. You can also apply an affine_transform while doing a transformed copy with fb2d_copy_transformed. Thus, you can easily rotate a part of a screen by setting a rotation (with fb2d_set_rotation) as the considered affine transform. You can also compose transformation with fb2d_compose_linear_transform. It is easy to make a point match in the source screen and the target screen with the function fb2d_set_matching_point.
Before using all these functionnalities, you should first initialise the display manager and then the 2D frame buffer manager with init_fb2d_manager. Similarly to the collision routine, it takes the address in DSP ram where the DSP subroutine should be copied.
Note that now there is a sound manager implemented (with v 1.1 of the library), the fb2d manager has moved to DSP ram.
Note finally that it is now easy to share the DSP between several tasks.
Then you also have to know that some part of my library assumes that you are also the jlibc (Jaguar C library) I have also written.
If you are using a C compiler to generate 68k code like gcc, it should be really easy. The only thing you need to know is that the type int stands for 32 bits integers. Thus, every parameter pushed on the stack when calling a function is 32 bits long.
If you are using 68k ASM code, then the additionnal thing you need to know is that all registers but d0/d1/a0/a1 are preserved by function calls.
Provided that your compilation environment is correctly set up, you can also alternatively build the library with the 'make' command and then install it where you want with the 'make install' command. You might have to change the TARGET variable of the Makefile to indicate where you want all the files to be copied.
Copyright (C) 2006 Seb/The Removers http://removers.atari.org/
This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version.
This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details.
You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA