Arkanoid - Page 9

Bah oui mais tes registres sont pas illimités... Donc si tu veux vraiment tout remplir au fur et à mesure (avec des (a0)+, d'ailleurs au passage je te rappelle que movem *,(a0)+ n'existe pas ), tu es obligé de relire => tu perds tout ce que tu as gagné avec le movem puisque c'est 2x plus lent, or comme je l'ai dit dans mon post précédent tu pas dépasser 50% plus rapide : résultat, gain négatif ou nul.

geogeo :
Sasume je voudrais savoir un truc:
J'ai regardé la source de FastGraySPrite32_OR_R en détail et je me demande si on peu l'optimiser, pour cela il suffirais seulement d'utiliser ta routine de scrolling de 32 pixels et de la répéter pour chaque ligne?? En bref ce baser sur la fonction de scrolling.

Oui, c'est tout à fait possible. Tu as une vieille version de fonction daffichage de sprite, je n'avais pas encore implémenté cette technique.

oups pour le +
bon peut importe.. perso je suis sur qu'on gagne mais la fonction est enorme

Bah fais le alors si tu en es convaincu Si tu fais une copie, tu ne gagneras rien, ou vraiment pas grand chose.

je la ferai des que j'aurai un peu de temps, la je doit bosser
si si ca arrive en ingé de bosser

Voici ma nouvelle routine pour dessiner un motif en mosaique:

;C prototype: void DrawScreen (void *sprt, void *dest);
;
;void DrawScreen (register long *sprt asm("%a0"),
;		 register void *dest asm("%a1"));


	section ".data"
	xdef DrawScreen

;Motif de 32x32 répété sur une zone de 234x200 pixels
DrawScreen:
	movem.l	d3-d7/a2-a3,-(a7)
	lea	256(a0),a0
	lea	7988(a1),a1
	lea	8000(a1),a2
	movea.l	a0,a3
	
	;Réptition 6 motifs par colonnes soit 192 pixels de hauteur
	moveq.l	#5,d7

;Répétion du motif en hauteur
\draw_up
	moveq.l	#31,d6
;Répétition du motif sur 32 pixels de hauteur et 216 pixels de largeur.
\rep:
	move.l	-(a0),d0
	move.l	d0,d1
	move.l	d0,d2
	move.l	d0,d3
	move.l	d0,d4
	move.l	d0,d5
	move.w	(a0),-(a2)
	movem.l	d0-d5,-(a2)
	
	move.l	-(a0),d0
	move.l	d0,d1
	move.l	d0,d2
	move.l	d0,d3
	move.l	d0,d4
	move.l	d0,d5
	move.w	(a0),-(a1)
	movem.l	d0-d5,-(a1)
	
	sub.l	#14,a1
	sub.l	#14,a2
	dbf	d6,\rep
	movea.l	a3,a0
	dbf	d7,\draw_up
	movem.l	(a7)+,d3-d7/a2-a3
	rts

La sauvegarde des registres est correcte? Cette routine est optimisable? Mais je me demande si cette routine est plus lente que celle que j'ai diffusé avant car effectuer move.l d0,* ça prend du temps énorme?

La sauvegarde des registres est correcte, la routine peut être légèrement accélérée si tu enregistres ton sprite à l'envers : tu pourras utiliser des move.l (a0)+,... qui sont plus rapides que des move.l -(a0),....
Tu peux aussi remplacer tes suba.l #14,an par des suba.w #14,an.
Les move.l d0,... sont ce qu'il y a de plus rapide.
Tu peux encore accélérer en allouant, à l'initialisation, un bloc qui contient le sprite de 208x32 pixels et tu le recopies en une seule fois dans tes registres en 1 movem.

Je vais éviter d'allouer des blocs de mémoire pour ce genre de choses.
Merci pour tout ses conseils.

Par contre j'ai un problème avec FastGraySprite32_OR_R et FastGraySprite32_MASK_R, il semble qu'il y a d'autres choses à modifier pour que ça s'adapte à mon buffer de 320x200 pixels.

Peut-être...
Vérifie déjà que la fonction marche correctement sur un buffer classique...

Elle fonctionne très bien sur un buffer classique.

Je suis en train de réaliser une fonction affichant un sprite de 8x8 à n'importe quel endroit dans mon buffer de 320x200 pixels, pour cela j'utilise cette algo:

;C prototype: void Font0_DrawChar (short x, short y, void *sprite, void *dest);
;
;void Font0_DrawChar (register short x asm("%d0"),
;		      register short y asm("%d1"),
;		      register void *sprite asm("%a0"),
;		      register void *dest asm("%a1"));

	section ".data"
	xdef Font0_DrawChar

Font0_DrawChar:
	movem.l	d3-d7/a2-a6,-(a7)
	
	;y*40
	lsl.w	#3,d1
	move.w	d1,d2
	add.w	d2,d2
	add.w	d2,d2
	add.w	d2,d1
		
	moveq.l	#$0F,d3			;15=0b1111
	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,a1			;Ce place dans la source
	
	;Masks
	moveq.b	#-1,d1			;Tout les bits de 2^8 activé.
	lsl.b	d0,d1			; d1 = mask1
	move.b	d1,d2
	not.b	d2			; d2 = mask2
	
	;d0=Bit à décaler
	;d1=mask1
	;d2=mask2

	moveq.l	#7,d7
	
;Dessine le caractère
\rep_draw_char:
	move.b	(a0),d3
	lsl.b	d0,d3
	
	move.b	(a0)+,d4
	rol.b	d0,d4
	move.b	d4,d5
	and.b	d2,d5
	or.b	d5,d3
	move.b	d3,8000(a1)
	move.b	d3,(a1)+
	
	swap.b	d4
	move.b	d4,8000(a1)
	move.b	d4,(a1)+
	
	adda.l	#38,a1
	
	dbf	d7,\rep_draw_char
	
	movem.l	(a7)+,d3-d7/a2-a6
	rts

J'utilise la méthode de sasume de scrolling mais ça bug et je ne vois pas pourquoi, sans doute des masques et d'autres trucs faux?

PS: Ici j'ai tout sauvegardé car je verrais après ce que je doiut resatuarer, idem pour d7, j'aurais plus utiliser autre chose.

[EDIT] Le sprite est en noir&blanc soit 8x8 pixels donc 8 octets...

C'est n'importe quoi...
Fais un débug ligne par ligne de ton code et tu comprendras ce qui ne va pas...

Mieux : essaie de réécrire une routine à partir de rien, comme ça tu comprendras peut-être ce que tu fais.

P.S. : Comment se fait-il que swap.b ne soit pas rejeté par a68k ?

Oaui c'est ce que je suis en train de faire, partir de rien, parce que le contenu de d0... est faux.

Il n'y a pas que ça de faux.
Mais au fait, je te signale que tu as des routines d'affichage de sprite 8x8 que je t'ai passées. Pourquoi tu ne les utilises pas ? (À moins que je ne t'ai passé que des 16 et 32)

Car je ne peux affciher quand mode OR et je pense qu'il est possible de réaliser une fonction avec ton idée de scrolling que tu utilise pour 32 pixels sauf que ici c'est pour 8 pixels. Je cherche à apprendre comment fonctionne tout ça.

De plus je pense que ce n'est pas bien d'utiliser des fonctions sans les comprendre.

Donc ne recopie pas bêtement la fonction...

Ce que j'utilise pour le scrolling est adapté pour faire du scrolling, pas pour afficher 1 sprite.
Ce que tu peux faire, c'est éventuellement utiliser les masques dans d1 et d2 puis des and dessus, mais c'est la seule particularité qui se rapprochera de la routine de scrolling (qui n'est pas que de moi d'ailleurs). Mais tout ça te sera inutile avec un sprite 8x8 car ce sera bien plus lent que la technique que j'utilise dans la routine que je t'ai passée. Ça n'est bénéfique que pour des sprites de 32 pixels de largeur.

Je ne comprends pas pourquoi tu ne peux afficher qu'en OR ? Avec quoi ?

OK je comprend.
Avec FastGraySprite8_OR_R je ne peux afficher quand mode OR ce qui est logique, pour faire du REPLACE il faut que j'efface la zone d'affichage du sprite puis que j'affiche en mode OR? Or je voudrais bien implanter ça dans cette fonction, je ne vais pas te dérange plus, je vais me débrouillier.

OK, bonne chance.

./246> Tu n'as rien compris movem n'a absolument aucun intérêt, et est même néfaste, si tu recharges les registres à chaque fois. Essaye plutôt d'implémenter les optimisations que je t'ai données, ce sera bien plus efficace (et si tu ne me crois pas, fais un bench...)

Ah bon ma fonction est plus lente que l'autre.
Pour TIMad avait conseillé l'utilisation des movem. J'avais fait tes optimisations et heuresement que j'ai sauvegardé ça.

Sasume :
P.S. : Comment se fait-il que swap.b ne soit pas rejeté par a68k ?

Il arrive que A68k accepte un peu tout et n'importe quoi.

TIMad avait conseillé l'utilisation des movem

Lis ./241...

swap.b ?

Kevin Kofler :
Il arrive que A68k accepte un peu tout et n'importe quoi.

Et apparemment, tu n'es pas pour changer ça :

Bugs.txt
A68k accepts some incorrect extensions like moveq.w, dbra.s or btst.w.
I don't know whether I should fix this one because some sources seem to rely on this. Kevin Kofler

De toute façon, j'ai l'impression qu'il faudrait pas mal de changements pour corriger ce problème, non ?

En effet, il faut rajouter des tests un peu partout. Et certaines sources qui marchaient très bien ne marcheraient plus. Par exemple, on trouve plein de moveq.b ou moveq.w qui n'empêchent pas le code de marcher, même s'ils sont évidemment faux.

Moui, c'est clair que ça serait assez bête de changer ça si ça demande beaucoup de modifications et qu'en plus après des sources ne seront plus assemblables...
Dommage, c'est quand même mieux je trouve de ne pouvoir écrire que du code correct. Ça prête à confusion, sinon...

Ça fait un bon point en plus pour AS

Si tu ne veux pouvoir écrire que du code correct, utilise l'assembleur GNU, il vérifie correctement les opcodes, lui.