GenLib - Page 1

Comme déjà dit dans l'autre topic, ExtGraph propose déjà des fonctions de ce style:

Fast Sprite Grabbing Routines

--------------------------------------------------------------------------------


void Sprite8Get(short x,short y,short h,void* src,unsigned char* dest) __attribute__((__stkparm__));
void Sprite8Get_R(register short x asm("%d0"),register short y asm("%d1"),register short h asm("%d2"),register void* src asm("%a0"),register unsigned char* dest asm("%a1")) __attribute__((__regparm__));
void Sprite16Get(short x,short y,short h,void* src,unsigned short* dest) __attribute__((__stkparm__));
void Sprite16Get_R(register short x asm("%d0"),register short y asm("%d1"),register short h asm("%d2"),register void* src asm("%a0"),register unsigned short* dest asm("%a1")) __attribute__((__regparm__));
void Sprite32Get(short x,short y,short h,void* src,unsigned long* dest) __attribute__((__stkparm__));
void Sprite32Get_R(register short x asm("%d0"),register short y asm("%d1"),register short h asm("%d2"),register void* src asm("%a0"),register unsigned long* dest asm("%a1")) __attribute__((__regparm__));
void SpriteX8Get(short x,short y,short h,void* src,unsigned char* dest,short bytewidth) __attribute__((__stkparm__));
void SpriteX8Get_R(register short x asm("%d0"),register short y asm("%d1"),register short h asm("%d2"),register void *src asm("%a1"),register unsigned char *dest asm("%a0"),register short bytewidth asm("%d3")) __attribute__((__regparm__));

SpriteXGet copies a sprite from the screen at x and y to dest. This routine is many times faster than the TIOS routine BitmapGet. Additonally sprites retrieved using SpriteXGet can be used as arguments for all the Sprite routines found in this header, unlike the bitmaps obtained with BitmapGet. x and y are the coordinates of the upper left corner of the sprite. h is the height of the sprite. src is a pointer to a video plane of size 240x128 pixels from which one wants to retrieve the sprite. dest is the pointer to a buffer (array) which is large enough to store the fetched sprite data.

The SpriteX8Get function differs from the rest of the functions. It is not fixed to a specific width, but you can specify the width in bytes as parameter (bytewidth). The sprite data fetched by SpriteX8Get is organized like this (example for bytewidth == 3): line1/byte1, line1/byte2, line1/byte3, line2/byte1, line2/byte2, line2/byte3 etc. You can use SpriteX8Get_R twice to simulate "FastCopyRectangleX8_R" (see below the Fast...RectanglesX8_R).

Martial Demolins
: ah ouais, merci c'est vachemetn compatible genlib ça.

</IRONIE> pour ceux qui n'auraient pas compris.
Mais je n'ai jamais prétendu que c'était le cas...

Quand à la doc de ExtGraph, quand tu programmes en asm, ya franchement mieux.

Mais pourquoi? Il y a même tous les registres spécifiés explicitement!

* stkparm = paramètres sur la pile (exactement comme pour les ROM_CALLs), sauf quand un registre est spécifié explicitement
* regparm = passage par registres automatique (mais là aussi, la spécification explicite est prioritaire)

Kevin Kofler
:

Martial Demolins
: ah ouais, merci c'est vachemetn compatible genlib ça.

</IRONIE> pour ceux qui n'auraient pas compris. Mais je n'ai jamais prétendu que c'était le cas...

Alors tu es hors sujet. On parle de GenLib ici.

Je le répète, mais extgraph n'est pas aussi puissante que genlib, surtout au niveau des fonctions X8...

Martial Demolins> Ça me semble une bonne idée de fonction, et je pense que ce n'est pas trop compliqué à coder, je pourrais peut-être réfléchir à ça pendant les vacances.
Après, faut voir si PpHd est d'accord ou non. Mais je pense que la routine devrait faire entre 100 et 200 octets max, donc il n'y aurait pas trop de pb de taille...

En y rélféchissant, cette fonction manque vraiment à genlib. Le problème est que genlib 1.0 va être releasé sans cette fonction, et je ne pense pas que PpHd ait encore envie de retarder sa sortie.
Faudra faire un genlib 1.01...

Ensuite, il faut voir si on fait un get_sprite16, et avec des possibilités de palette...

Questions:

Doit-elle gerer le clipping correctement ?
Doit-elle generer un masque ?
Faire des traductions de palettes ?

Pour le clipping : si on fait un genlib::get_big_sprite(BGS *buffer,short x1,short y1,short x2,short y2);et qu'on l'appelle avec des coordonnées négatives quelque part, on peut traiter le problème en recadrant la zone de capture du sprite (genre remplacer les valeurs négatives par 0 et celles >239 par 239 pour les abscisses), mais le BGS obtenu ne correspondra pas à ce qu'aura voulu l'utilisateur puisqu'une partie du sprite manquera... Comment indiquer ça à l'utilisateur ?

Un code de retour ? Remplacer la zone non recuperer par une couleur de fond ?

Mauvaise idée. Ça n'est pas exploitable en C.

Oui mais les 3/4 des utilisateurs ne s'en souciront jamais.

Heu... Nan. Elle est deja trop en retard, et trop de boulot reste.
Surtout que je remets sur les PedroM Apps. Ce n'est pas ma faute si je le suis seul a bosser a la T3

En même temps, tu es le seul de l'équipe non ?
Ah oui, il y a aussi Squale92... Mais je crois qu'il tente de rendre KII compatible avec la Titanium.

Qui ?

Mais je crois qu'il tente de rendre KII compatible avec la Titanium.

J'ai recompilé K pour Titanium... j'attend que quelqu'un le teste
(faudrait que je le poste ailleurs que sur le forum T3, pour avoir plus de chances que quelqu'un le teste, peut-être)

pour ce qui est de KII... le rendre compatible Titanium, j'ai peur que ce soit dur... du moins, si j'ai bien compris certains pbs de la Titanium...
(mais ça sera faisable... suffira de contourner mes hacks )

Version kernel ?