Optimization needed ! - Page 1

Qui est capable d'optimizer encore + cette routine ?

//Special Scroll routines for a buffer of 320 pixels wide
//(from T.Nussbaumer, Thanx to K.Kofler for the mod)
void ScrollLeft320(unsigned short* buffer,unsigned short lines) {
register short* tmpbuffer = buffer;
register short tmplines = lines;
tmpbuffer += (tmplines<<4) + (tmplines<<2);
tmplines--;
asm volatile (
"0:
lsl.w -(%0);roxl.w -(%0);roxl.w -(%0);roxl.w -(%0);roxl.w -(%0)
roxl.w -(%0);roxl.w -(%0);roxl.w -(%0);roxl.w -(%0);roxl.w -(%0)
roxl.w -(%0);roxl.w -(%0);roxl.w -(%0);roxl.w -(%0);roxl.w -(%0)
roxl.w -(%0);roxl.w -(%0);roxl.w -(%0);roxl.w -(%0);roxl.w -(%0)
dbra %1,0b"
: "=a" (tmpbuffer), "=d" (tmplines)
: "0" (tmpbuffer), "1" (tmplines));
}

En particulier, cela accelerait il le traitement si l'on fait une fonction sans arguments ?
C'est à dire avec un nombre de lignes constants et un buffer donné du genre :
void ScrollLeft320()
{asm volatile (...le code ici...) }

heu, si je me rappelle bien, faut changer la methode ... nan? (d'apres ce qu'il avait dit, il avait grave chié pr faire ce codes là)

heu, si je me rappelle bien, faut changer la methode ... nan?

Comment ca ?

d'apres ce qu'il avait dit, il avait grave chié pr faire ce codes là

Qui ca ?
Thomas Nussbaumer ?
Où as tu vu qu'il en avait grave chié ???

Attends, dis tt de suite ce que tu veux faire !
Si tu veux faire un jeu, avec des tiles, ou surtout des tiles annimes, genre 16*16, le mieux serait de reafficher tous les tiles de l'ecran (comme BigDyna)

Ca fait un certain tps que j'utilise plus ce genre de methodes !

C'est pour faire un Scrolling. Je ne peux pas utiliser ta methode, car effacer l'ecran + reafficher 80 tiles 16x16 + afficher plusieurs sprites (joueur+ennemi) maskés à chaque passe avec les routines de extgraph en C , eh ben c meme pas la peine !

Si si c'est franchement la peine.
Fais un essai, tu verras, honnetement !
Au pire, je peux bosser avec toi sur l'adaptation d'une routine ASM vers le C, specifique a ton programme.

Dans mon nouveau bomber (dans bigdyna aussi au passage) je reaffiche ~150 sprites (full screen clippe sur 92+) plus ~10 sprites de 16*26 pour le bomber et les ennemis. Tout ca a chaque boucle du jeu.

Ca fait une bonne dose par rapport a ton truc non ? (presque le double !)

En plus avec cette routine que tu as ecrite plus haut, tu ne peux faire que du pixel par pixel

Si si c'est franchement la peine.
Fais un essai, tu verras, honnetement !
Deja fait, et la vitesse etait honorable k lorsk je scrollais par paquet de 16pixels (un tile !)

En plus avec cette routine que tu as ecrite plus haut, tu ne peux faire que du pixel par pixel
C exactement ce k je veux, donc c parfait.

Le prob, je le repete, viens des routines de sprites en C trop lente.
Donc a - k tu te mettes à updater extgraph pour avoir de belles routines de sprites en ASM, cette solution me parait la meilleure. (en fait g presk une vitesse suffisante, faudrait plus k'un tout petit peu d'optimization, genre comme je le dis au debut faire une routine purement ASM avec aucun arguments.)

Bah je te dis, pas de pb.
Pour plus de rapidite en ASM, j'utilise qu'un seul pointeur pour les deux plans de l'ecran (les deux buffers ne sont qu'en fait un seul, deux fois plus grand), j'utilise pas de boucle, etc...

Montre moi la routine qui doit afficher les tiles, ou dis moi quelle est la largeur de l'ecran en octets (30 octets ? --> 8*30 = 240 pixels), dis moi quel est le format de tes sprites, etc...

c pour zelda ?

Oui.
Avec cette methode je scrolle de maniere tres rapide de 2 pixels par passe pour un scroll gauche/droite et de 1 pixel par passe pour un scroll haut bas (mais bon un scroll haut/bas c trop facile :-) )

Selon FlashZ il suffirait k je synchronize le tt pour k l'on ne voit pas la difference avec du 1 pixel par passe, et pis c'est vrai k la synchronie donne bcp mieux à l'ecran, meme si l'on perd en speed.

Enfin bon j'aimerais bien faire le scroll parfait, du 1 pixel par passe avec synchronie

bin si tu fais un scroll 1 pixel par passe tres rapide tu as juste a ajouster une routine d'attente pour que les deux scrollings mettent autant de tps chacun (tu utilises tjs extgraph ?)

JE REPETE : DU PIXEL PAR PIXEL NE SERT A RIEN :

- le refresh des grays est souvent moins rapide que deux cycles de scroll
- l'ecran 'baveux' permet de ne se rendre compte de rien du tout
- faire du scroll 2*2 ou 3*3, ce n'est pas visible a l'oeuil... cf BigDyna ou SMA...

bin oui en plus tu as raison

je viens de retomber sur ce topic...
FlashZ> serais-tu prêt à me faire le même proposition, au sujet de routines de sprite en ASM (pr Krypton) ?

bah file moa ta routine ASM par mail, en me disant exactement les parametres... pour aghnar, on n'a rien mis au point finalement
je te jure pas que j'aurai le tps...

pour faire un truc rapide, j'ai besoin en entree de :
- coord x
- coord y
- sprite addr

(sachant que les deux plans du sprite doivent se coller, et derriere les deux plans, le mask)

et il me faut aussi la largeur de ton plan video...
30 octets ?

tiens, pendant que les proposition affluent, ca te dirais pas de faire un pitit tuto pour ti-fr, sur les prites,affichage rapide gray ...

flashz> je pense que tu as l'intention de leur filer la routine graphique, je pense notamment de celle qu'on avait parlé sur aol.
pour le tuto, bah si tu n'as pas le temps, je peux peut-etre le faire, moi, vu que c pas très long

Juste comme ca : SMA fait du 18x18 en vitesse max standard et 44x44 en vitesse max dechirante

malheuresement, je n'ai po de routine ASM
Juste celle d'Extgraph, en C

Pour la largeur du plan, oui, c'est un plan standard de 30 pixels de large.

erf vivement GFXl......

erf, comme tu dis...

On prend les paris ? Y'aura rien que toi pour l'utiliser !

bein ouai comme tous mes programmes

PpHd> peut-être pas...

nEUrOne et HerveRV> vous avez laissé tomber cette idée ?

euh, quelle idée ?

le tuto

non, t'inquiète pas.

je fais un tuto des que rf marche vite et bien et en réseau
je fais un tuto si y a pas mal d'intéressés pour le rotozoom que j'ai fais, même s'il n'est pas hyper pratique à utiliser, mais il est rapide et je l'ai pas encore optimisé (stade de développement

HerveRV: moi je suis tres interessé par ton tuto sur le rotorzoom.

moi, personnellement, ça ne m'interesse pas trop (du moins actuellement), mais je penses qu'il y en a d'autres que ça interesse