[mOved] Crash Bandicoot - Page 3

Alors peut-être n'as tu pas non plus besoin de routine de scaling ^^

ben si parce que je dois afficher les objets avec une taille selon leur éloignement

^^ Donc tu as besoin d'une routine clippée

pas forcément pasque je peut bloquer les objets avant qu'ils ne soient affichés hors de l'écran mais clippée c'esrt mieux

GoldenCrystal>Non, pas forcément

limmt> Mais tu comptes afficher combien de sprites comme ça ?
Je croyais que tu voulais précalculer les zoom sur les sprites ?

en précalculant le zoom avec 4 vues c pas beau et plus y'arua trop de psrites différents donc pas assez de mem
en moyenne y'a environ 10 sprites comme ca par frame

Mmh, je pense avoir compris ce que tu veux faire : tu précalcules le niveau, mais tu comptes mettre des objets (des items en gros) sur ta map en plus.
Déjà, tu n'aurais besoin que du clipping vertical > Ça simplifie énormément les choses.
Mais pourquoi tu ne précalcules pas les zooms, comme pour le reste du niveau ?

qu'entends tu par "reste du niveau"??

Sasume > ben imagine que un ennemi surgisse par derrière, si il est pas affiché tu le vois pas...
De même imaginons (avec un efort surhumain) qu'il y ait des virages (on imagine hein...), ben si un ennemi est en dehors de l'écran par là, il va apparaître comme par magie à un moment

10 sprites, ça fait beaucoup quand même.
Bonne chance

y'aura pas de virages
ca peut faire plus que 10 dans le cas ou tu ouvre plusieurs caisses sans prendre les pommes que y'a dedans

erf, sans vouloir te faire peur, sais-tu le nombre de cycles que peut prendre le dessin d'un sprite étiré ?

normalement ca ne l'étire pas ca le diminue juste

étiré/diminué, même fonction, même combat... Le temps de dessin dépend de la taille à afficher...

Au fait, je viens de me rendre compte que ma fonction pouvait être largement optimisée dans le principe : je n'affiche qu'un pixel à l'écran à la fois, alors que je pourrais y aller par paquets de 8 (je les mets pixel par pixel dans un registre que je copie à l'écran après). Ça devrait être plus rapide, non ? À tester.

y'a-t-il bcp de différence entre un bset/bclr vers la mémoire et un bset/bclr vers un registre ?

Je pense, au moins 4 cycles à mon avis pour l'accès mémoire.

Oui, c'est ça.

Un peu juste à mon avis...

À mon avis ça accélèrera quand même
(surtout pour les gros sprites qui prennent le plus de temps à être affichés)

surtout si tu opères par longword (mais ça peut être chiant au niveau de la mémoire quand tu appliques le longword)

4/8

Heu...Bit Instructions

.b/.l   register .l    memory .b
           only        only
bchg     8/12          8/12
bclr    10/14          8/12
bset     8/12          8/12
btst     6/10       

Je sais pas si c'est vraiment une optimisation de travailler avec des registres dans ce cas ^^ (plutôt une désoptimisation en fait, puisqu'il faudrait ajouter un move pr la lecture et un autre pr l'écriture )

Tu n'aurais pas oublié cette ligne par hasard ?

The time taken to calculate the effective address must be added to instructions that affect a memory address.

Me fierais plus jamais à timing.txt

Je le trouve assez illisible, personnellement.

Cependant, je ne comprends pas pourquoi pour faire un bset.b dn,(am) il faut 1 lecture et 2 écritures.

Y'a pas ça dans genlib ?
S'il y a, tu copies-colles la source de la fonction.

Et je te fous un proces.

Je *veux* voir ça

GenLIB n'est pas en source ouverte () ?