Vous n'êtes pas identifié.
euh Julien jcrois ke t'as mal compris, il veut release un moteur tile-renderer
vala en gros du travail déjà mâché plus qu'à réchauffer quoi ...
Hors ligne
Ah oui pardon, je n'avais gardé que sa fonction "drawmap()" en tête...
Hors ligne
pour les tiles animé, faut utiliser la méthode leadfiner qui consiste à modifier le sprite animé toutes les X frames!
Hors ligne
bin oui
soi faut faire comme ca
mais la lib auxiliaire independante dont je parlais
aura des fonctions qui permettront de modifier la map (pas les sprites)
creer, donc de modifier les sprites pour qu'il y ait un peu d'animation
Hors ligne
euh je vois pas trop l'interet d'une fonction spéciale pour modifier la map... c'est assez facile à faire soi même mais bon c'est toujours ça
Hors ligne
arf deja des problemes de comprehension...
tu confond, a mon avis, petite map et grande map (bof pas terrible l'explication)
je te parle pas d'une map codée comme ca:
unsigned char petite_map[][]=
{
4,0,1,2,3,5,7,
2,2,4,5,6,1,1,
5,6,7,7,9,0,1,
};
ou chacun des numéros represente un sprite
la fonction se sert de cette petite map pour en creer une nouvelle (la grande)...
donc y aura plus qu'a changer chacun les numéros de la petites map pour faire des sprites animé... ensuite on appelle la fonction qui recréé la map en fonction de la petite, et voila
enfin tout cela sera plus clair lorsque j'aurai creer les fonction...(pour l'instant ya que drawmap() qui est faite)
Hors ligne
ne me dis pas que la "grande map" est une image que tu recrées en assemblant les tiles indiqués par la petite, et que tu enregistres en mémoire 8O
Hors ligne
bin si...
comment veux tu faire autrement...
c un bouffe place enorme c sur...
il serait préférable de stocker tous les sprites ailleurs que dans le programme...
mais je ne vois pas d'autre méthode tout en ayant la meme vitesse qu'il y aura
Hors ligne
Ca c clair, pour peu que les maps soient un peu grandes (30*30) par ex, si ce sont des tiles 8x8 ca prendra 30*30*2*8 octets = 14,4 ko en mémoire, et pour des 16*16, faut compter 4 fois plus... donc ca dépasse déjà l'espace normal dispo pour le prog :? Utiliser les memzones est possible, mais l'espace n'est tjs pas illimité, et ca obligerait à utiliser cette lib aussi presque systématiquement...
Ton système est ok pour de toutes petites maps, donc je sais pas si ca servra vraiment... En plus si vraiment on veut créer une map avec des tiles animés, il faudra modifier la "petite map" et puis redessiner la grande à chaque cycle, donc le faible gain de temps pour l'affichage de la map tu le reperds entierement en devant la reconstruire à chaque fois en entier! :?
En plus en général les tiles ne "bougent" pas a chaque refresh (ca serait trop rapide), donc la map ne sera à recréer que tous les 5-6 frames par ex, donc vive la fluidité... Ou alors faut créer plusieurs grandes maps et passer de l'une à l'autre pour ne pas avoir à les redessiner "en live", mais vu leur taille, c meme pas la peine d'y penser
Hors ligne
lol...
c pour ca que g dit que ca serait plus clair qd j'aurai fait les fonctions...histoire de voir ce que ca donne vraiment, en vitesse...
en fonction des résultats, je verrai si je sors la lib auxiliaire ou pas...mais en tous cas je sortirai de toute facon drawmap(), qui, si on en sert comme arriere plan fixe, peut toujours servir...
en meme temps je peux toujours essayer de faire une fonction qui affiche un buffer complet mais directement a partir des sprites...evidemment ce sera plus lent
Hors ligne
apres une petite réflexion...c décidé
je vais faire des fonctions qui affichent directement a partir des sprites...
d'une part, le probleme de la taille sera réglée, en plus je pense que le compromis en vitesse sera tout de meme interessant, car le temps de creer ou d'actualiser une map n'aurait pas été négligeable...
en fait je n'avais pas pensé a faire ca car je voulais utiliser absolument drawmap() pour n'importe quelle type d'affichage (sprite ou map).
comme ca j'intégrerais les nouvelles fonctions a db-lib sans avoir besoin de creer une librairie auxiliaire... cependant, il va etre tres difficile de conserver les optimisations de drawmap dans ces nouvelles fonction
Hors ligne
arf salut!!!
alors voila que dites vous de fonctions qui affiche du texte en mode db, sans aucun sprite a charger soit meme :
vous placez la fonction dans votre code, et c'est tout, ca affiche du texte.
Le miracle : g juste reutilisé les sprite de casio.
g créé deux fonctions :
-> une tres simple locate() qui fonction comme celle du basic (a qq détails près)
-> une fonction text() qui a l'aide d'argument permet d'afficher du texte de toutes les couleurs avec pleins d'effets...
alors pour avoir tout ca c : http://perso.wanadoo.fr/swfprod/dblib/Db-lib.zip
et les explications des fonctions : http://perso.wanadoo.fr/swfprod/dblib/DB-lib.htm
Par contre, comme g pas mon cable, tout a été testé avec l'emulateur, donc faut vérifier que ca marche sans aucun problemes.
ah oui g aussi amélioré les fonctions clippés, et je risque de ressortir une petite mise a jour si j'ai le temps...
Hors ligne
Marche sans prob pour texte...
-->Merci pour ces fonctions
testé et approuvé à 02h11
JOYEUX NOEL
Hors ligne
Ca c'est une bonne idée! Je m'étais justement demandé si c'était utile que je refasse une fonction comme printf en même temps que les autres fonctions de stdio
Hors ligne
a quand un genre de scanf pour creer des pitis programmes de maths sans se fouler ?
Hors ligne
Juste pour demander à Swifter s'il pouvait mettre à jour sa version DigitalMars qui date de la première parution de dblib ! merci
Hors ligne
euh bin je crois qu'il n'y a pas besoin de version spéciale pour digital mars...
normalement les mise a jours permettent de compiler soit avec tc3 soit avec digital mars...
m'enfin g pas essayé, fo vérifier mais normalement...
Hors ligne
c bon pour digitalmars. fo juste changer deux trois fonctions car DM n'eccpete pas de mettre un label à la fin;
Hors ligne
Oui il faut lui rajouter un ';' derriere :rouge:
Hors ligne
salut a tous...
ca faisait longtemps que j'étais pas passé, et j'ai que certain avaient quelques probleme pour coder les sprites pour db-lib...
j'ai en fait fini mon codeur de sprite depuis pas mal de temps mais j'avais oublié de le sortir...lol
alors les trucs important a savoir...euh fo que je me souvienne...
vous pouvez faire glisser l'image bmp sur le programme (ou alors placez votre bmp a cote du programme puis rentrez le nom de l'image au clavier), ensuite reglez les options du programme. La fonction spr2map() n'existe toujours pas dans db-lib. Sinon si votre image fait 128*64, vous pourrez coder des images pour disp_bmp().
A oui un autre truc, vous pourvez mettre une image de n'importe quelle taille. Pour coder des sprites, le programme va séparer votre image et coder les sprites les uns apres les autres : en commencant par le sprite en haut à gauche jusqu'a celui en haut a droite, puis en descendant aux sprites en dessous.
Si vos sprites "debordent", ils seront completé avec des pixels blancs.
Ah oui sinon vous pouvez : mettre des arguments
-l8 ou -l16 : longueur de 8 ou 16
-hx avec x la hauteur de votre sprite : determine la hauteur
-e : ecrase si le fichier existe deja
... euh yen a d'autre mais jm'en rapelle plus
sinon les différentes sortie de fichiers...
Soit un .C : a inserer avec votre code source
Soit un .GPH : a envoyer sur votre calculatrice. Le codage d'un GPH n'a rien de plus simple : aucune compression et les données sont stockées les une apres les autres.
euh j'ai aussi integrer la fonction drawmap() avec comme exemple le moteur graphique de zelda : donc pour coder une map selectionner "drawmap" avec une image au minimum de 128*64
voila je crois que c'est tout :
http://perso.wanadoo.fr/swfprod/dblib/Db-lib.zip
Hors ligne