[DEV] pour les nuls

[chacha]

tu peux mette un lien vers ton image qu'on puisse la regarder ? Ou c'est résolu ?

Bin en fait, je ne comprends pas pourquoi IMAGESHACK enregistre mon image en .png (elle est en .bmp à la base).

La voici enregistrée, mais elle est donc en .png. Je ne sais pas si vous pourrez en faire grand chose :




Là, j'essaie de faire une image toute neuve dans GIMP pour voir si ça fait pareil. C'est le bordel, j'arrive même pas à faire un trait .

[CeL]

Click droit sur ton image -> Informations sur l'image

=> Type : Image PNG

Enregistre la au format bmp avec gimp (sans le renommer hein )

[chacha]

Et bé non, c'est ça le problème avec IMAGESHACK, c'est que c'est bien un fichier BMP que j'ai, mais quand j'y enregistre quoi que ce soit (sur leur site), c'est enregistré en png.

Le seul moyen que j'ai pour que tu ais le fichier, c'est les mails .

EDIT =



Je ne comprend pas; ça doit venir de l'image, ou de sa "transformation" en .bmp .

Bref, deuxième étape résolue .

Faut que je prenne des notes de la mort, là, sinon, je vais être perdu. J'avais oublié de modifier la taille de mon "sprite". La compilation fonctionnait, mais pas de srpite en vue.

Bon, vous avez vu la gueule de mon "sprite" justement ? J'ai pas réussi à colorier pixel par pixel, du coup, ça donne ça . On s'en fout, le but, c'est que ça fonctionne.

MERCI LES GARS (jusqu'à la prochaine tuile )

[HPMAN]

Fonctionne très bien cette image chez moi

[CeL]

envoie le par mail alors cel at redarmor.net

[chacha]

Fonctionne très bien cette image chez moi

C'est tiré de quel programme cette tof ?

[chacha]

envoie le par mail alors cel at redarmor.net

Merci, mais look at the EDIT of my post .

[HPMAN]

C'est tiré de quel programme cette tof ?

C'est mon programme à moi

[chacha]

Mais tu en as de la chance (du mérite plutôt) d'avoir tes propres programmes .

Mon "sprite" avait une forme bizarre, le voilà dans sa bonne forme (j'ai inversé la hauteur et la largeur dans le main.c) :


avec changement de la couleur 0 (transparence) :





Bon.

Points suivants, dans l'ordre :

- modifier un sprite
- bouger un sprite
- animer un sprite
- animer un sprite en fonction de sa direction

Edit =



Gniiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

[chacha]

Que je comprenne bien :

Le bg.bmp est comme ceci, en 0,0 :



Sa taille fait qu'il prend tout l'écran : 15x20, soit la résolution de l'écran. Edit = erreur, c'est bien 14x20. Mon image est rognée en bas; elle fait 15 tiles de haut, mais il en est affiché que 14 en partant du haut. La dernière ligne n'est pas affichée.


On pourrait très bien prendre que les tiles utiles, soit 4 de haut et 20 de large 4x20 et l'afficher en 11,0 (12ème case en partant d'en haut et 0ème case en partant de la gauche) :



C'est quoi le plus intéressant ? Pour le côté pratique, c'est le sprite 14x20 (à mes yeux, mais je ne sais pas pourquoi ^^ ). Pour le côté mémoire, c'est le sprite 4x20.

Qu'en pensez-vous ?

[CeL]

On pourrait très bien prendre que les tiles utiles, soit 4 de haut et 20 de large 4x20 et l'afficher en 11,0 (12ème case en partant d'en haut et 0ème case en partant de la gauche) :

Oui c'est même mieux de faire comme tu dis, par contre tu n'économiseras pas de sprite puisque c'est la largeur qui compte(or tu ne réduis que la hauteur).
Là où tu vas avoir en bénéfice, c'est en superposition de sprites, je ne connais pas exactement la limite mais quand tu commences à superposer pleins de sprites ça bug.
Ex.: une explosion, au dessus d'un boulette, au dessus d'un ennemi, aussi dessus d'une animation, au dessus d'un BG1, au dessus d'un BG2 ==> ça bug. Le bug n'est pas visible sur nebula( tout s'affiche bien) mais sur mame et sur le vrai hard, ça glitche


Pour faciliter la compréhension, habitues toi à parler en largeurXhauteur ex.: 320x224 = 20x14.

soit 4 de haut et 20 de large 4x20 et l'afficher en 11,0

ex.2: Soit 20 de large par 4 de haut : 20x4 et l'afficher en x=0, y=11 => 0,11

Enfin moi je fonctionne comme ça

[chacha]

Essai en diminuant la taille de bg.bmp (20x4 , en 0,0) :



J'ai changé les coordonnées en write_sprite_data(0, 11, 15, 255, 14, 20, (const PTILEMAP)&bg); et ça donne ça :



Donc les coordonnées des sprites sont en pixels, mais leut taille est en tile. Simple :fartaz: .


C'est quoi ce carré noir ?


Edit : oups, j'ai oublié de diminuer la taille du sprite dans le main.c . P'tain, faut penser à beaucoup de choses.

Je le mets donc en 0,160 (224-64=160) et ça donne avec write_sprite_data(0, 160, 15, 255, 4, 20, (const PTILEMAP)&bg); :



Bon, ça fonctionne, je commence à appréhender le schmilblick. Mais c'est quoi ce carré noir ? Je modifie le bg ( ) pour voir un peu.

Edit ² : faudrait que je résolve avec votre aide ce problème de make et makeroms, car c'est assez long et répétitif (surtout long : changer une info, à mon stade ^^ , est assez rapide; je lance donc le make et ensuite je compile à la main).

Edit 3 :

Et ça donne ça :



J'AI UN INTRUS DANS MES SPRITES , tel un ninja, on ne le voit pas, car il est de noir vétu.


Une idée ?

Je vais bouger mon "shinobi" (la cameraball, oui, je n'ai pas changé de nom, trop long ^^ ), et je reviens...

Voilà, je suis revenu, et ça donne ça :



Brin, ça vient de mon bmp de cameraball.

Bon. Je vais essayer avec un autre sprite alors .

[HPMAN]

Là où tu vas avoir en bénéfice, c'est en superposition de sprites, je ne connais pas exactement la limite mais quand tu commences à superposer pleins de sprites ça bug.

96 sprites par ligne max

[chacha]

Mais p'taiiiiiiin, j'arrive pas à faire un point avec ce programme à la con .

[sengoku 2]

C'est mon programme à moi

Oh, cela se voit que Hp man est revenu dans la place, ça doit bosser dur pour avoir ses propres programmes à soi .
A retenir cette phrase de son poto kizunos :

"4/ he's working on something (for the Neo) that noone will be able to forget (very very crazy thing)."

http://www.neo-geo.com/forums/showth...=1#post3378114


Grâce à jeff kurtz et son nouveau logiciel wav to adpcm a , hp man va bientôt pouvoir sortir crossed sword 2 .