sprite : la lib pour as - Page 1

Vous revez de programmer vos zeldas ou F-Zero directement sur la calc ? Bientôt un pas de plus sera franchi : j'ai ecrit les 3 fonctions Sprite8,Sprite16 et Sprite32 directement sur ma calc! (avec AS() ) La libraire devrait etre disponible pour au plus tard vendredi.

En attendant : voici un extrait : Sprite8

Vous pouvez toujours l'adapter pour les deux autres fonctions, mais moi qui ait déja réussi à le faire, je vous conseille plutôt d'attendre (Surtout pour Sprite32s)Sprite8:  move.l 4+0+10(a7),a0  ;-------------------------  move.w 4+0+2(a7),d0 ;-- charger y  muls #30,d0  add.w d0,a0  ;-------------------------  move.w 4+0+0(a7) ;--- charger x  lsr.w #3,d0  add.w d0,a0  ;------------------------  move.w 4+0+0(a7),d1  divu #8,d1  swap d1 sprite8_b1:  cmp.w #0,4+0+4(a7) ;--- c'est h ---  beq sprite8_f1  move.w 4+0+6(a7),a2  ;--- decalages ------  clr.w d2  move.b (a2),d2  lsl.w #8,d2  lsr.w d1,d2  move.b d2,d3  lsr.w #8,d2  ;---- mode d'ecriture -----  cmp.w #0,4+0+14(a7) ;--- il s'agit de mode  beq sprite8_xor  cpm.w #1,4+0+14(a7)  beq sprite8_or  ;---------------------------- sprite8_and:  and.b d2,(a0)  and.b d3,1(a0)  bra sprite8_endtst  ;---------------------------- sprite8_xor:  eor.b d2,(a0)  eor.b d3,1(a0)  bra sprite8_endtst  ;---------------------------- sprite8_or:  or.b d2,(a0)  or.b d3,1(a0)  ;---------------------------- sprite8_endtst:  add.l #30,a0  add.l #1,4+0+6(a7)  sub.w #1,4+0+4(a7)  bra sprite8_b1 sprite8_f1:  rt

et c rapide ?
pke programmer avec des ftcs lentes on-calc, c pas interessant

Au fait, quelqu'un serait il d'accord pour que je lui passe ma lib et qu'il la diffuse pour tout le monde. Sinon ca serait dommage : j'en ai marre de Lycos Webmaster, je ne fous que la merde.

Bah, je veux bien t'heberger ca ... ca me pose pas trop de prob, mais un lien ou une page, et c toi qui fait tout ...

Tu préfère pas que je te l'envoie par mail ?

Je ne veux pas être méchant, Tails mais ta fonction est très lente.
Tu as vraiment de quoi optimiser. Surtout le divu suivi du swap... Ça peut s'optimiser en un and

Tu m'envoies le tout par mail ...
c'est à dire une page nomée index.php avec ton html dedans
et ton zip

ton adresse sera: http://neurone.kouette.com/tails/

Et puis la façon dont tu shiftes le sprite est loin d'être rapide aussi...

Et ton mode and m'a l'air buggé (je n'ai pas vérifié, c'est juste à la lecture du code)

mode==OR) { } else if(mode==XOR) { } else { } }

Et ta façon de sélectionner le mode n'est pas ce qu'il y a de plus optimisé :while(dest+=30,h--)
{
 if(

{ while(dest+=30,h--) { } }

C'est mieux de faire un truc du genre :if(mode==OR)
{
 while(dest+=30,h--)
 {
   
 }
}
else if(mode==XOR)
{
 while(dest+=30,h--)
 {
   
 }
}
else

Par contre si quelqu'1 pouvait me donner une fonction put_sprite16(int x,int y,unsigned int *spr,int height) super rapide et en plus clippé ca serait mon bonheur... Car malheuresement celle que j'ai faite pour ktl doit etre un poil lente et ca me premettrait de gagner du temps pour faire autre chose ....

c'est lent, mais bon si c'es ta premiere fonction graphique c'est deja un debut

JackosKing > C'est bien ma première fonction graphique
nEurone > merci, mais de toute facon, comme l'a dit JackieChan, je ne suis pas assez fort pour proposer mes sources, si à l'avenir j'ai des docs perso ou des progs, je te les enverrais par mail. (C'est plus fort que moi, des que j'ai besoin d'une fonction, je l'ecris moi meme, et quand je l'ai finie, il faut que j'essaye de la diffuser. Bon, ben maintenant je me calme)

Tails: diffuser c'est un bon moyen d'apprendre, avec tous les reports de bugs, conseils etc..

Ok, bon je vais mettre mes deux routines de sprite restantes, mais ca ne sera pas optimisé maintenant (les vacances approchent). Comme j'ai un problème avec le TI-GRAPH LINK chez moi, je suis obligé de tout recopier

(L'ecriture de la pile x+y+z(a7) a été empruntée dans le 92Guide)
Sprite16: Sprite16:  move.l 4+0+10(a7),a0  ;-------------------------  move.w 4+0+2(a7),d0  muls #30,d0  add.w d0,a0  ;-------------------------  move.w 4+0+0(a7),d0  lsr.w #3,d0  add.w d0,a0  ;------------------------  move.w 4+0+0(a7),d1  divu #8,d1  swap d1 sprite16_b1:  cmp.w #0,4+0+4(a7)  beq sprite16_f1  move.l 4+0+6(a7),a2  ;-------decalages---------  clr.l d2  move.w (a3),d2  lsl.l #8,d2  lsr.l d1,d2  move.b d2,d5  lsr.l #8,d2  move.b d2,d4  lsr.l #8,d2  move.b d2,d3  lsr.l #8,d2  ;----- mode d'écriture --------  cmp.w #0,4+0+14(a7)  beq sprite16_xor  cmp.w #1,4+0+14(a7)  beq sprite16_or  ;--------------------------------- sprite16_and:  and.b d2,(a0)  and.b d3,1(a0)  and.b d4,2(a0)  and.b d5,3(a0)  bra sprite16-endtst  ;--------------------------------- sprite16_xor:  eor.b d2,(a0)  eor.b d3,1(a0)  eor.b d4,2(a0)  eor.b d5,3(a0)  bra sprite16-endtst  ;--------------------------------- sprite16_or:  or.b d2,(a0)  or.b d3,1(a0)  or.b d4,2(a0)  or.b d5,3(a0)  ;-------------------------------- sprite16_endtst:  add.l #30,a0  add.l #2,4+0+6(a7)  sub.w #1,4+0+4(a7)  bra sprite16_b1 sprite16_f1:  rts

je me suis tromé à la ligne 20, c'est (a2) et non (a3)
Sprite32: Sprite32:  move.l 4+0+10(a7),a0  ;-------------------------  move.w 4+0+2(a7),d0  muls #30,d0  add.w d0,a0  ;-------------------------  move.w 4+0+0(a7),d0  lsr.w #3,d0  add.w d0,a0  ;------------------------  move.w 4+0+0(a7),d1  divu #8,d1  swap d1 sprite32_b1:  cmp.w #0,4+0+4(a7)  beq sprite32_f1  move.l 4+0+6(a7),a2  ;-------decalages---------  clr.l d0  clr.l d2  move.l (a2),d0  move.l (a2),d2  move.w #8,d3  sub.w d1,d3  lsr.l d1,d0  lsl.l #8,d2  lsl.l #8,d2  lsl.l #8,d2  lsl.l d3,d2  lsr.l #8,d2  lsr.l #8,d2  lsr.l #8,d2  move.b d0,d5  lsr.l #8,d0  move.b d0,d4  lsr.l #8,d0  move.b d0,d3  lsr.l #8,d0  ;----- mode d'écriture --------  cmp.w #0,4+0+14(a7)  beq sprite32_xor  cmp.w #1,4+0+14(a7)  beq sprite32_or  ;--------------------------------- sprite32_and:  and.b d0,(a0)  and.b d3,1(a0)  and.b d4,2(a0)  and.b d5,3(a0)  and.b d4,4(a0)  bra sprite32_endtst  ;--------------------------------- sprite32_xor:  eor.b d0,(a0)  eor.b d3,1(a0)  eor.b d4,2(a0)  eor.b d5,3(a0)  eor.b d4,4(a0)  bra sprite32_endtst  ;--------------------------------- sprite32_or:  or.b d0,(a0)  or.b d3,1(a0)  or.b d4,2(a0)  or.b d5,3(a0)  or.b d4,4(a0)  ;-------------------------------- sprite32_endtst:  add.l #30,a0  add.l #4,4+0+6(a7)  sub.w #1,4+0+4(a7)  bra sprite32_b1 sprite32_f1:  rts

(Sprite32 n'est pas passé ... tant pis je laisse tomber)

hum:
Version Actuelle <=> Version Optimisée
divu #8,d0 <=> lsr.w #3,d0
cmp.w #0,4+0+4(a7) <=> tst.w 4+0+4(a7)
muls #30,d0 <=> add.w d0,d0; move.w d0,d1; lsl.w #4,d0; sub.w d1,d0;

Tu ne devrais pas écrire par bytes, mais plutôt avec un long à la fois... Ce serait bien plus rapide

en plus oui j'ai oublié ca

Et puis quelques autres trucs... (dont je t'avais déjà fait la remarque dans mes posts précédent)

Si je ne fais pas byte par byte, il est possible que j'obtienne un adress error

Il suffit que tu fasses bien attention à pointer vers une adresse paire

Oauis, c'est vrai. Mais enfin j'ai fais ce prog pour avoir à tout prix de quoi dessiner les sprites, c'est pour cela que j'ai dit à nEurone que diffuser des spources est plus fort que moi ... parceque je prendrais un moment plus tard pour optimiser mes codes, pour l'instant, j'essaie d'agrandir une centrale de programmation on-calc ... quitte à laisser tomber les gains de temps ... chez moi c'est encore l'apprentissage!

Oui, eh bien moi je te donne des conseils pour t'aider à apprendre...

nEUrOne
a écrit : muls #30,d0 <=> add.w d0,d0; move.w d0,d1; lsl.w #4,d0; sub.w d1,d0;

Ce n'est pas une optimisation. Ton code est plus gros.

Le code est bcp plus rapide ... c'est une optimisation, ca dépend de ta priorité après...
L'Optimisation n'est pas forcément celle en taille ...

Kevin> pour une routine de sprite, avoue que la priorité d'optimiser en taille est largement négligeable devant celle d'optimiser en vitesse.
Tails> essaye toujours de remplacer des mulu/muls #n,dn ou divu/divs #n,dn (qui sont des instructions très lentes) par des additions et des décalages.

kevin tu devient lourd... si tu ne sait pas voir sur quel sujet d'optimisation on parle, alors abstient toi!

> pour une routine de sprite, avoue que la priorité d'optimiser en taille est largement négligeable devant celle d'optimiser en vitesse.
Ca dépend dans quelles limites. Remplacer un mulu et un divu par des add, sub et shifts dans une direction ou l'autre (remplacer un divu n'est pas toujours possible, mais de toute façon il n'y en a pas besoin dans une routine de sprite), c'est parfaitement correct (le remplacement du mulu #30 par la suite de quatre instructions coûte 4 octets).
En revanche, dérouler les boucles, donc augmenter de façon très nette la taille, sans que ça ait une grande influence sur la vitesse (jackiechan avait montré que l'influence du déroulement d'une boucle ne dépasse pas 10% sur une Sprite16, alors que la taille augmente de bien plus de 10, n'est pas vraiment une bonne optimisation.
Même en mettant deux shiftings et en déroulant une fois la boucle, tu multiplies par au moins deux la taille de la routine, pour gagner 20% sur la vitesse.
Et je ne parle même pas de ce qui se passe quand on déroule complètement la boucle...
Il est souvent plus intelligent de dessiner le maximum de sprites byte- ou word-aligned et de se contenter d'une routine non déroulée pour les autres sprites.

Euh, c'est plutôt 15% et 30%, les gains (au lieu de 10% et 20% ).
Mais c'est vrai que la taille de la fonction double ou triple.

Faut savoir ce que l'on veut, mais bon, en général dérouler entierement la fct est pas interessant, mieux vaut la dérouler partiellement ...

jackiechan: OK. Il n'en reste pas moins que je pense que ça n'est pas la peine de le faire pour une routine générale (ou alors proposer deux versions, une petite et plus lente, et une plus rapide mais beaucoup plus grosse - ce que je pense qu'on va faire dans ExtGraph pour certains types de routines, car ni Kevin ni Tom n'ont vraiment hurlé, il faut que je redemande confirmation, je demanderai en même temps pour le format de sprite optimisé)...