|
|
|
|
|
|
 |
 |
 |
|
 PierrotLL
MP / Email |
Il y a un certain temps déja que j'avais programmé ça, mais je n'ai pas eu le temps d'y retravailler depuis. J'avais essayé de faire un moteur de niveaux de gris (le fichier Gris2.rar est en fichier joint ici). Le problème, c'est qu'aucune fréquence ne donne quelque chose de potable. Si vous voulez des explications des sources, posez vos questions, je serais enchanté d'y répondre. Et si vous avez des explication de la nullité de mon programme, se serais parfait  . Je ne comprend pas pourquoi c'est si lent. J'ai lu toutes les sources de revolution-fx de kucalc, apres en avoir un peu discuté avec lui je les ai comprises. En réalité, pour le timer, lui il utilise directement un port du processeur, mais il ne sait pas trop comment ça fonctionne. Moi je n'aime pas utiliser quelque chose sans comprendre comment ça marche, j'ai donc utilisé un timer avec les fonctions du SDK (c'est d'ailleurs les seules fonctions du SDK que j'utilise). Mais je suis assez désespéré devant le résultat médiocre. Help me please 
PS: la fonction en assembleur est tirée de revolution-fx, de kucalc.
|
PierrotLL
MP / Email |
Grosse avancée dans le projet
Ce soir j'ai compris et résolu le bug qu'avait ma fonction d'affichage de sprite en octet par octet (donc tres rapide), et j'en ai profité pour programmer un petit utilitaire pour PC qui donne le code des sprites en 8*8 et 16*16.
Vous pouvez télécharger le tout ici.
SpriteLib.c et SpriteLib.h sont les fichiers de la nouvelle version de SpritLib (qui ne contient que deux fonction  ) et Uselib.h est un exemple d'utilisation.
main.c est le fichier source de SpriteMaker.
J'attend vous remarques avec impatience
|
 Bebevador
MP / Email |
j'ai pas eu le temps de tester la lib mais j'ai testé le generateur ^^
à quoi correspond le cache ?
|
PierrotLL
MP / Email |
Le cache c'est pour les pixels blancs. En fait, avec sprite1[] et sprite2[] je fais un OU binaire sur le buffer, donc si un bit de sprite1[] vaut 1, le bit de buffer devient 1, si le bit de sprite1[] vaut 0, le bit de buffer ne change pas.
Donc avec juste sprite[1], on a du noir et du transparent.
Avec cache[], je fais un ET binaire, donc si le bit de cache vaut 1, on ne change rien, s'il vaut 0 on met un 0 dans buffer. Comme ça on a du blanc.
Mais évidement, s'il y a un cache a afficher, ça fait une seconde boucle, donc ça ralentie. Le plus rapide c'est s'il n'y a que sprite1[]. Si on rajoute cache[] ou sprite2[] c'est un peu moins de deux fois plus long. Et si on rajoute cache[] ET sprite2[] alors ça fait 4 boucles, donc 4 fois plus long (enfin, un peu moins)
|
PierrotLL
MP / Email |
Je suis désolé, je suis allé un peut trop vite hier et il restait des problèmes au deux programmes.
Vous pouvez télécharger le nouveaux fichier ici
L'exemple a changé et utilise revolution-fx 
|
|
|
 |
 |
 |
|
|
|
|
|
|
