Vous la voulez? - Page 11

2 solutions:

soit tu compresses ton prog, soit tu define un ghost sapace:
#define EXECUTE_IN_GHOST_SPACE

Mais ca sert a rien de mettre les 2.. donc ce que je te conseil, c'est de le develloper avec le define, et si tu veux le distribuer, tu le compresses en enlevant le define..

Voila pourquoi XOn ne revoie pas de valeur d'erreur...

ok nickel, ça marche avec le #define ....
Bah en DLL c très bien maintenant (mis à part que la taille du prog pur augmente d'1.5 Ko à l'aise pour les appels ect ), ça va aussi vite qu'avant (pour la fonction XGNSprite, c la seul où mes anciennes def sont bonnes donc je la garde), et le clipping total est très bien, plus de boggue

Sinon quelle fonction est la plus rapide entre XGNSprite() et XGTWSprite() ???

Je pense celle de transparence non ?

Sinon j'attend la nouvelle DLL pour tester les fonctions de mask

Le reste des cas c'est en particulier pour aider le programmeur pas les users..

Je n'ai pas besoin de cette aide

Bah moi j'ai déjà dit ce que je trouvais le mieux. Il vaut mieux laisser le soin au programmeur de faire ses propres mask, comme il les veut, aussi tordus qu'il veut, donc garder en DLL la fonction XGMSprite()

je suis d'accord.
(ou alors, propose les deux foncions)

Pim> il faut se placer en ghost_space pr pouvoir utiliser des Dll

squale92:
La lib a pour but d'etre facile d'utilisation, si t'as pas besoin de cette aide comme tu le dits.. t'as qu'a faire ta fonction avant XOn!!! XLib ne te l'empeche pas...

arf, moué...
ma fois, j'obtiendrai pas mieux, visiblement

c'est deja pas mal

Pim89 a écrit :

Sinon quelle fonction est la plus rapide entre XGNSprite() et XGTWSprite() ???
Je pense celle de transparence non ?

vi ?? alors ???? c quoi la plus rapide ?

Ecris #define EXECUTE_IN_GHOST_SPACE avant #include <tigcclib.h>

XGN

Pim89> XGN sans pbm, ta pas le calcul du mask a faire ! donc forcement c plus rapide !

Contrairement ca certaine lib, mes routines de transparence ne calcule pas de mask

par contre TiMad, faire une fonction qui genererait un sprite avec mask apart d'un simple mask c une id nan ? (Cf post de Pim89 #298)

comment tu veux faire
a partir d'un truc a 2 couleur arriver a 4 couleur c'est un peu chaud

oulala

je manque de moi !!!
lol

générer un mask a partir du sprite !

Comme le fait la lib de l'Autre (celui dont il faut pas dire le nom, vous saver bien nan ? le sorcier qui a "mal tourné" (Non je viens pas de regarder Harry Potter ))

Arf la fonction de hallo est trop lente je trouve..

mais elle peut être pratique ds certains cas
(notamment pr faire ressortir un personnage dans un jeu en environemment sombre, ou très chargé)

oui la fonction de halo est lente, mais se que propose Pim c de pourvoir l'utiliser, mais qu'une seule fois, cad qu'on a sont sprite au format "normal" et on le fait passer a la moulinette par cette fonction qui nous renvois un pointeur vers un nouveau sprite qui est sauver au format XGN, apres reste plus qu'a l'afichier avec XGN

C pourrait servir dans certain cas non ?

avec XGM plutôt pour l'utiliser non ?

pour le calcul une seule fois ?? bah j'ai peur que si on a bcp de sprite, ça fasse bcp de RAM bouffé pour tout concerver en mémoire ...

Si on veut absolument un mask, on le fait soit même et on utilise tout directement avec XGM.
Par contre si c un peu sprite normal de temps en temps à convertir en hallo ou mask, et bien on se tape le calcul mais bon, c pas dramatique.

Rapidité => on fait son propre mask et on utilise direct avec XGM. De toute façon ça revient à pire de demander un automask, car cet automask est copié en RAM en plus de la def normal du sprite.

Pas trsè rapide, de tps en tps => def normale et Xlib nous calcul l'automask.

le mask auto tu le calcul que quand tu va utiliser le sprite jusqua se que tu l'utilise plus (disparait de l'affichage etc..., enfin bon ct qu'une id)

Erf Xlib peut passer a la moulinnette 1000 sprite a convertir apres, il suffit qu'il y ait de la ram libre ce qui je pense n'est pas un probleme...

Le mieux TIMad, tu fait ttes les fonctions qui te plaisent et pi apres tu l'aisse le programmeur choisir celle qui lui plait a utiliser

C pas cool comme sa ?

ben c chaint 500000000 DLL dans sa caltoche avec 3/4 des mm trucs

Je v me la jouer à la Kevin's style :
c'est à ça que ça sert les libs statiques


(sauf que lui l'aurait dit mieux que moi °

oué, c vrai .. mais faut dire que la DLL est bien pratique lorsque vous aurez 2/3 jeux fonctionnant avec XLib sur votre TI ... nan?

s'il y a autant de jeux avec Xlib que avec genlib...
ça serait pas mal de pouvoir compresser la Dll, en fait...

(Genlib (sous PreOS), comme toutes le slibs, peut être compressée, et c clair que c vachement pratique : vu que je m'en sert que rarement, comme ça, elle prend peu de place, mais je l'ai toujours)

oué, c sur mais c deja bien la DLL nan ?

Hum en plous de se que g vu la DLL elle est pou enourme ! (g du mal avec le ou touday moua )

En effet, j'ai reussit a la faire tenir en moins de 8800 Ko...
Meme si rien que 2 bon jeu utilise lalib, elle est "rentabilisée" ...
d'ailleur meme 1 seul, puisque par exemple K2 utilise toutes les fonctions dedans..

Erf, moi j'utilise les fonctions de plan (toutes je crois, sauf copygplantogplan),et les fonction de sprites : XGM, XGN, XGTW ....
Mais j'attend la fonction de pic avec impatience !!! (pour afficher la boite de dialogue par ex , car mon ancienne méthode ne marche plus avec la nouvelle Xlib DLL, maintenant on vois tjs le décort au travers de la boite ).

j'ai commencé à ripper une map, la démo RPG va devenir plus jolie , j'attend la nouvelle DLL et les fonctions de sprites maské, et la fonction de PIC pour montrer un shot (même si ça sort ds 1 mois pour la pic, pas grave ).

Pim89> rajoute XFilleRectangle(x,y,x1,y1,WHITE); pour avoir le fond blanc