Arkanoid - Page 11

Et lorsque l'écran est fixe, ce n'est pas le meilleur des cas?

Je le sais bien mais comme la partie fixe est situé dans une zone divisible par 32, la fonction de scrolling est rapide. De plus l'écran sera le plus souvent mobile que fixe.

On est bien d'accord sur ce qui _devrait_ se passer, mais tes chiffres ont l'air de dire que précisément, le cas "partie fixe" n'est pas le meilleur des cas (puisqu'on peut atteindre plus de 70 fps), et en plus il n'y a pas de grosse différence par rapport au pire des cas...

Alors j'ai optimisé le tout est j'arrive à presque 68 fps constant avec scrolling et 70 fps partie fixe. Mais il s'avère que lorsque la caméra passe d'un état fixe à un état mobile et inversement, le fps monte en flèche de 5 point pour arriver des fois à 75 fps, ce qui ce traduit par une accélération de la bille assez visible. De plus 70 fps c'est un score très très convaincant.

bah synchronise ta boucle infinie

Ouais, ou essaye de rajouter un code de compensation correspondant à l'écart théorique entre le fps le plus lent possible et le fps qu'on devrait obtenir sans compensation. Mais je ne comprends pas du tout les pics à 75 fps Comment tu expliques ça?

Pour l'instant non mais je synchroniserais avec une interruption.
J'essaye d'avoir le maximum de fps.

Ouais, ou essaye de rajouter un code de compensation correspondant à l'écart théorique entre le fps le plus lent possible et le fps qu'on devrait obtenir sans compensation. Mais je ne comprends pas du tout les pics à 75 fps Comment tu expliques ça?

Je comprend pas aussi cette écart.

geogeo
: De plus je me rend compte que si je lit le contenu du sprite avec des (a0)+, la routine est plus lente mais très faiblement.

Ben c'est bizarre... Si tu ne changes que ça (à la place de -(a0), tu mets (a0)+, mais e changeant évidemment l'ordre des lignes du sprite), tu ne devrais pas être plu lent d'aprè la doc de Motorola...

En ce qui concerne le pb du fps variable, est-ce que tu utilises la fonction qui scrolle ton grand buffer et qui l'affiche sur le buffer de 3840 octets ?

Pollux :
(je te conseille qd même de ne pas montrer ta routine à Kevin, il va te gueuler dessus sinon parce que tu "perds" 2x4 octets avec des boucles déroulées, et tu "perds" 2x2 octets en passant par un registre temporaire )

Pas besoin de me la montrer, je vois tout.
Et en effet, mon seul commentaire au sujet de cette routine est: !

Pas besoin de me la montrer, je vois tout.

Argl, je n'y avais pas pensé

Et en effet, mon seul commentaire au sujet de cette routine est:

Bah, toujours est-il que même si on peut gagner 12 octets dessus en la rendant 2x plus lente, c'est carrément rentable pour une routine critique comme celle-là (différence de 50% en temps d'exécution entre la version originale et celle là!). Si vraiment tu es à 12 octets près, alors tu réécris une routine en ASM, et tu les gagnes sans problème... Ou alors tu optimises tes formats de données, par exemple en évitant les tableaux de chaînes. C'est n'importe quoi de sacrifier le tiers du temps d'exécution pour économiser 12 octets

En ce qui concerne le pb du fps variable, est-ce que tu utilises la fonction qui scrolle ton grand buffer et qui l'affiche sur le buffer de 3840 octets ?

Oui j'utilise cette fonction.

Ben c'est simplement parce qu'il y a des instruction de décalages de bits dont le temps d'exécution dépend du nombre de décalages...

C'est bien ce que je pensais.

Sasume> erf, évidemment Mais le truc, c'est qu'avec un écran fixe, le décalage vaut 0, donc en principe le temps est minimal, non? A moins que la routine de scroll soit pas hyper bien programmée... Je peux voir à quoi elle ressemble, avec tout le code d'initialisation des shifts?

La voici:

;C prototype: void CopyScreenBufferToScreen (short x, short y, void *src, void *dest1, void *dest2);
;
;void CopyScreenBufferToScreen (register short x asm("%d0"),
;		      register short y asm("%d1"),
;		      register void *src asm("%a0"),
;		      register void *dest1 asm("%a2"),
;		      register void *dest2 asm("%a3"));

	section ".data"
	xdef CopyScreenBufferToScreen

CopyScreenBufferToScreen:
	movem.l	d3-d7,-(a7)
	lsl.w	#3,d1
	move.w	d1,d2
	add.w	d2,d2
	add.w	d2,d2
	add.w	d2,d1			;d1=y*40
		
	moveq.l	#$0F,d3			;15=0b1111=décalage sur 32 bits
	move.w	d0,d2			;d2=x
	and.w	d3,d0			;d0=Bit à décaler
	
	not.w	d3
	and.w	d3,d2 			;d2=octet	
	lsr.w	#3,d2
	add.w	d2,d1			;Octet ou ce commence la copie
	
	adda.w	d1,a0			;Ce place dans la source
	
	lea.l	8000(a0),a1		;Prépare plan1
	
	move.l	#127,d7			;Prépare la boucle de 128 pixels
	
	moveq.l	#-1,d1			;Tout les bits de 2^32 activé.
	lsl.w	d0,d1			; d1 = mask1
	move.w	d1,d2
	not.w	d2			; d2 = mask2
	
	;d0=Bit à décaler
	;d1=mask1
	;d2=mask2
	;d7=boucle
\LineStart:
	move.l	(a0)+,d3
	lsl.l	d0,d3

	move.l	(a0)+,d4
	rol.l	d0,d4
	move.w	d4,d5
	and.w	d2,d5
	or.w	d5,d3
	move.l	d3,(a2)+	; 1

	move.l	(a1)+,d5
	lsl.l	d0,d5

	move.l	(a1)+,d6
	rol.l	d0,d6
	move.w	d6,d3
	and.w	d2,d3
	or.w	d3,d5
	move.l	d5,(a3)+

	and.w	d1,d4
	move.l	(a0)+,d3
	rol.l	d0,d3
	move.w	d3,d5
	and.w	d2,d5
	or.w	d5,d4
	move.l	d4,(a2)+	; 2

	and.w	d1,d6
	move.l	(a1)+,d5
	rol.l	d0,d5
	move.w	d5,d4
	and.w	d2,d4
	or.w	d4,d6
	move.l	d6,(a3)+

	and.w	d1,d3
	move.l	(a0)+,d4
	rol.l	d0,d4
	move.w	d4,d6
	and.w	d2,d6
	or.w	d6,d3
	move.l	d3,(a2)+	; 3

	and.w	d1,d5
	move.l	(a1)+,d6
	rol.l	d0,d6
	move.w	d6,d3
	and.w	d2,d3
	or.w	d3,d5
	move.l	d5,(a3)+

	and.w	d1,d4
	move.l	(a0)+,d3
	rol.l	d0,d3
	move.w	d3,d5
	and.w	d2,d5
	or.w	d5,d4
	move.l	d4,(a2)+	; 4

	and.w	d1,d6
	move.l	(a1)+,d5
	rol.l	d0,d5
	move.w	d5,d4
	and.w	d2,d4
	or.w	d4,d6
	move.l	d6,(a3)+

	and.w	d1,d3
	move.l	(a0)+,d4
	rol.l	d0,d4
	move.w	d4,d6
	and.w	d2,d6
	or.w	d6,d3
	move.l	d3,(a2)+	; 5

	and.w	d1,d5
	move.l	(a1)+,d6
	rol.l	d0,d6
	move.w	d6,d3
	and.w	d2,d3
	or.w	d3,d5
	move.l	d5,(a3)+

	and.w	d1,d4
	move.l	(a0)+,d3
	rol.l	d0,d3
	move.w	d3,d5
	and.w	d2,d5
	or.w	d5,d4
	move.l	d4,(a2)+	; 6

	and.w	d1,d6
	move.l	(a1)+,d5
	rol.l	d0,d5
	move.w	d5,d4
	and.w	d2,d4
	or.w	d4,d6
	move.l	d6,(a3)+

	and.w	d1,d3
	move.l	(a0)+,d4
	rol.l	d0,d4
	and.w	d2,d4
	or.w	d4,d3
	move.l	d3,(a2)+	; 7

	and.w	d1,d5
	move.l	(a1)+,d6
	rol.l	d0,d6
	and.w	d2,d6
	or.w	d6,d5
	move.l	d5,(a3)+
	
	swap.w	d4
	swap.w	d6

	move.w	d4,(a2)+
	move.w	d6,(a3)+

	addq.l	#8,a0
	addq.l	#8,a1

	dbf	d7,\LineStart
	
	movem.l	(a7)+,d3-d7
	rts

Copie 240x128 pixels du buffer de 320x200 pixels.

Au passage, Pollux, tu peux me dire ce que je peux optimiser dans cette routine stp (en vitesse) ?

geogeo> Donc tu n'as pas encore implémenté le "vrai" scrolling (i.e. ce dont parlait Kevin, par opposition à un scrolling sur qqch qu'on redessine à chaque fois), contrairement à ce qui a été dit en ./299 et ./300 ? Parce que ton format d'entrée n'est pas le même que celui de sortie, donc je ne pense pas que tu t'amuses à rajouter une fonction de copie...

Sasume> Ca m'a l'air plus que correct (en tout cas pour la boucle interne), mais uniquement tant que d0<=8... Si d0=15 par exemple, la routine n'est pas efficace du tout... Il faudrait remplacer d0 par 16-d0 et les 'rol.l d0,d3' par 'swap d3/ror.l d0,d3', et 'lsl.l d0,d3' par un truc du même style (même si ça risque d'être un peu moins efficace pour le lsl, c pas grave parce que c'est seulement une fois sur 8).

La fonction que tu vois s'occupe directement d'afficher à l'écran une partie de ma zone de 320x200 pixels de mon buffer et ce sans passer par d'autres buffers. Dans ton sens oui ce n'est pas réellement du vrai scrolling mais ça le devient à cause du mouvement de la 'caméra'.

OK... Donc c'est parfaitement normal que tu aies un fps variable, mais par contre quand l'écran est fixe, tu dois avoir un fps différent selon l'endroit où tu t'arrêtes (ce que tes posts ne mentionnaient pas).

Ah oui mon écran fixe est unique et ce situe dans la zone 0,72,239,199. C'est une zone divisble par 32, donc aucun décalage dans la fonction de copie de buffer à l'écran.

En fait si il y a plus de 1 bille, la caméra ce situe sur la zone fixe que je viens d'indiquer, si il y a une bille, la caméra suit la bille.

Pollux
: Si d0=15 par exemple, la routine n'est pas efficace du tout... Il faudrait remplacer d0 par 16-d0 et les 'rol.l d0,d3' par 'swap d3/ror.l d0,d3'

... ce qui double encore la taille de la fonction, qui est déjà excessive!

sauf que c'est à geogeo de voir là, et je pense qu'il n'avait pas besoin de toi pour faire son choix

Vu ce que je veux implanter par la suite il me faut le maximum de vitesse possible, la taille des données je m'en contre fiche surtout que ça ce compte grand maximum en centaines d'octets.

Tu trouves ça normal de gaspiller des centaines d'octets juste pour gagner quelques fps insignifiants?

Et au fait, le section ".data" n'est plus nécessaire avec TIGCC 0.95, et il est même plutôt néfaste.

nan t'as pas saisi le problème, il n'a pas envie de gaspiller de précieux fps pour quelques octets insignifiants

Ah d'accord, merci pour cette info.

Tu trouves ça normal de gaspiller des centaines d'octets juste pour gagner quelques fps insignifiants?

Les octets perdus seront récupéré dans autre chose.

Kevin Kofler :
Et au fait, le section ".data" n'est plus nécessaire avec TIGCC 0.95, et il est même plutôt néfaste.

Ah ?
Pourquoi ça devient néfaste ?
Et puis pourquoi il y a (avait ?) des histoires de segment sur TI ?

Au sujet de la fonction, je suis bien de l'avis de Kevin, elle est déjà bien grosse comme ça, ça m'ennuierait de doubler sa taille sans pour autant gager beaucoup de fps.
On peut éventuellement utiliser du code auto-modifiant sinon... Mais le fait de devoir changer beaucoup dinstruction comme la boucle est déroulée risque de ralentir pas mal, donc il vaudrait mieux réenrouler, éventuellement... Donc au finale, je ne suis pas sûr que l'on gagerait vraiment. Faudrait tester, j'ai un peu de mal à me rendre compte.

Je pense que c'est bien plus efficace de rajouter une version rol/ror, quitte effectivement à réenrouler la boucle (un facteur 2 ou 3 aurait un effet relativement faible sur le fps comparé à rol/ror, mais ça peut être intéressant de laisser déroulé si c'est vraiment *la* routine critique), de toute façon le gain sera gigantesque, et en plus on gagnera sur le plan de la régularité (moins de saccades puisque le pire des cas sera traité plus efficacement)