Vous n'êtes pas identifié.
Voilou... Je l'avais promise, là voici et la version beta de sprite maker permet déjà de coder les sprites pour l'utiliser
(la version 1.4b est maintenant disponible, allez voir quelques posts plus loin!)
NOUVEAUTES PAR RAPPORT A LA VERSION 1.3
· Changement du format de compression des 3 couches en 2, pour une décompression plus rapide;
· Plus de fonctions drawsprite() mais une fonction drawspr() à laquelle on passe également le mode d'affichage; possibilité de choisir parmi les 4 modes mask+clip, nomask+clip, mask+noclip, et nomask+noclip;
· Possibilité de définir une origine pour chaque sprite. L'origine (a,b) d'un sprite que l'on souhaite afficher en (x,y) à l'écran est le point du sprite qui sera réelement affiché en (x,y). Ceci revient à afficher un sprite en (x-a,y-b) avec une origine (0,0);
· Possibilité de choisir les fonctions qui devront être compilées, et donc de ne pas devoir compiler les fonctions non-utilisées par le programme pour ne pas l'alourdir inutilement;
· Possibilité de modifier le cadre de clipping (avant la compilation), pour laisser une zone de l'écran sur laquelle les sprites affichés en mode mask+clip ou nomask+clip ne pourront pas empiéter (Attention, "tout" n'est pas permis...);
· Bug corrigé: la macro DRAW_JUMP ne fonctionnait pas parfaitement lorsqu'on modifiait sa valeur.Voyez le readme pour plus de détails
C'est par ici:
http://orwell01.free.fr/drawlib14.zip
Et pour les amoureux du rar: :P
http://orwell01.free.fr/drawlib14.rar
Si un admin de la tg100 voulait bien valider mon upload...
Hors ligne
wéééé je vé voir ça !
sa va m'aider pour cet été ! ^^
Hors ligne
Lol oui mais comme la durée donné pour le défi casio est tres courte... :twisted:
Hors ligne
Voilà, une petite mise à jour après une grosse révision du clipping!
NOUVEAUTES PAR RAPPORT A LA VERSION 1.4
· Révision complète du clipping: fonctions mask+clip et nomask+clip nettement moins volumineuses;
· Le cadre de clipping peut maintenant être configuré comme on veut. On peut ainsi empecher les 2 fonctions citées ci-dessus d'afficher quoi que ce soit en dehors d'un cadre défini dans l'écran, quelles que soient ses dimensions et sa position (tout en restant à l'intérieur de l'écran bien entendu). Les 2 autres fonctions seront toujours capables d'afficher en dehors de ce cadre.
· Bug corrigé: Les compilateurs râlent quand on ne spécifie pas de nom pour les paramètres d'une fonction. Pô ma faute, chuis habitué au c++ moi :arrow: http://orwell01.free.fr/drawlib14b.zip
:arrow: http://orwell01.free.fr/drawlib14b.rar
Les sprites codés pour la version 1.4 restent bien sûr compatibles avec la 1.4b.
A titre d'info, j'ai fait quelques tests de comparaison entre drawlib 1.4b et DB-lib : je fais afficher un sprite en boucle pendant 15 secondes sans effacer les buffers ni raffraichir l'écran, et en comptant le nbre total d'affichages j'en déduis la fréquence d'affichage des fonctions (donnée en Hertz ici).
Ces tests ont été effectués pour un sprite 8*8 et un sprite 16*16, affichés au centre de l'écran (mais décalé).
Sprite 8*8 DB-lib Drawlib Mask+Clip 2200Hz 3316Hz noMask+Clip 4300Hz 4040Hz Mask+noClip 2405Hz 3470Hz noMask+noClip 4641Hz 4297Hz Sprite 16*16 Mask+Clip 1016Hz 1245Hz noMask+Clip 2045Hz 1896Hz Mask+noClip 1066Hz 1298Hz noMask+noClip 2132Hz 2004Hz
Voila, ca devrait permettre de mieux fixer les idées
Hors ligne
bon allé, osons les grand mot: Draw-Lib a un léger avantage. mais franchement c trois fois rien. mais Db-lib à l'avantage d'etre plus complete.
Hors ligne
mais pour les sprites, c' est drawlib qu' il faut prendre, particulièrement quand la taille commencent à ètre de 16+ pxl! et il supporte aussi les pointeurs far sans modification!
Hors ligne
Db-Lib et DrawLib n'ont pas les mêmes objectifs, ca serait ridicule de vouloir n'en garder qu'une pour son prog
Db-Lib est plus technique, et permet pas mal de choses pour peu qu'on s'y connaisse un peu; mais pour les sprites par exemple on est fort limité au niveau de la taille qui est fixe, et on doit appliquer séparément le masque et les couches etc...
Le but de drawlib est de rendre tout ça bien plus abordable pour tout le monde, le fait d'afficher un sprite n'est plus un casse-tête mais se réduit à un seul appel de fonction quelle que soit la taille (bonne chance pour pouvoir passer facilement d'un sprite a l'autre avec db-lib si la taille est fort variable lol)...
Et effectivement, des que la taille d'un sprite dépasse 16*16 drawlib est plus rapide, et c'est d'autant plus vrai s'il y a un masque à appliquer. En plus, le format drawlib est compressé donc tu gagnes en mémoire si tu as bcp de sprites...
Je vais pas reciter tous les avantages (y'a le cadre de clipping qu'on peut régler aussi par exemple), mais je rappelle juste que les buts ne sont pas les memes, et qu'avant d'etre des concurrentes, ces 2 libs se doivent d'être complémentaires
Et au fait, le but de ces tests n'était pas principalement de montrer que drawlib était plus rapide; c'était plutôt pour montrer que, tout en étant plus confortable à l'utilisation, le coût en performance qu'on doit subir en utilisant cette lib n'était vraiment pas fort sensible
Hors ligne
moi je me sert des deux car elles sont vraiment très bien...
Hors ligne