Arkanoid - Page 8

geogeo> t sûr qu'il y a pas des bugs dans ton code ? Parce qu'il me semble que tu utilises les registres d3-d4 et a2-a5 sans les sauvegarder En principe, gcc s'attend à ce que leur contenu reste inchangé...

Je croyais que GCC sauvegardais tout les registres sauf a0/a1 et d0-d2

Et les performances alors ? GCC ne distingue pas les fonctions asm des fonctions C, donc il devrait sauvegarder tous les registres à chaque fois

Dans ce cas pourquoi mon code ne bug pas?????

C'est un coup de chance. Quand GCC place des paramètres dans les registres, il sauvegarde la valeur précédente (si nécéssaire) dans la variable correspondante avant de charger la valeur du paramètre dans le registre. Si tu voulais utiliser la même fonction deux fois de suite avec un ou plusieurs paramètres qui ne changent pas (dans d3-d7 et/ou a2-a6 bien sûr), gcc aurait parfaitement le droit de ne pas recharger la valeur dans les registres puisqu'en principe la valeur n'aurait pas du être changée (donc... bug dans la plupart des cas)

je ne comprend pas trop le principe des 10 billes
je suppose qu'elle viendrons(les billes) a la suite d'un bonus

mais si une de ces billes passe "en dessous" de la raquette sera -t-elle perdue ou va elle rebondir sur le mur du bas??
si ce n'est pas le cas, comment peut on gerer ces billes sans vir tout l'ecran???

hmm..je sens que personne ne va comprendre ce que j'ai dit...

C'est une démo, bien sûr le jeu va ce construire petit à petit, les balles supplémentaires viendront à la suite d'un bonus et si les balles sortent de l'écran (en bas) elles sont perdus....
La je test lmes collisions avec l'écran, les billes et les divers évenements...

en fait si tu as compris
donc des qu'il y ora un certain nomvbre de billes en plus, elles seront forcement perdues au bout d'un certain temps...
alors que sur un arkanoid"classique" on peut toujours essayer de les ratraper..dommage...

Non tu as pas compris, tu pourras les récupérer, il n'y aura pas de collisions avec le bas de l'écran, la raquette ce chargera de ça, donc tout ce qui touchera raquette sera disponible dans le jeu sauf les monstres (mise à par les grosses balles)...

C'est une démo, pour vérifier les divers collisions rien de plus, la je travaille sur le rippage de sprites, j'ai des petits problèmes sur Atari ST.

g compris que c'etait ne demo
lol
aors je reformule

dans la version finale, le scrolling suivra-t-il(comme sur le dernier sshot) une seule balle(la principale mettons..)??
si oui, on ne pourra alors pas voir la raquette...
et si non comment voit-on les briques cassees,;....

si c'esrt pas ca du tout je me pend

Si il y a une balle, le scrolling se fera avec la balle, si y en a plusieurs, avec la raquette.
Il y aura le temps que tu agisse entre le moment ou la balle arrive et où tu déplace la raquette, je vous assure.
Bah pour les briques cassé, tu les verras pas puisqu'elle sont cassé. Non réellement le scrolling sur Ti92+ et V200 est parfait, seulement un écran 2 fois plus grand. De plus je suis un des premiers à faire ça, on verras le résultat mais vous ne serez pas deçus.
De plus je pense ajouter une option pour désactiver le fond. Par contre il faut que j'optimise la fonction graphique s'occupant d'afficher le fond, elle semble bouffer assez de ressources.

La voici, TIMad, ne m'as toujours pas donner son idée.

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


	section ".data"
	xdef DrawScreen

DrawScreen:
	move.l	d2,-(a7)
	lea	322(a1),a1
	lea	8000(a1),a2
	movea.l	a0,a3
	moveq.l	#11,d2

\rep:
	moveq.l	#15,d3

;Sprite totale	
\b0:
	move.l	(a0)+,d1
	moveq.l	#5,d0
;Gris clair
\s1:
	move.l	d1,(a1)+
	dbf	d0,\s1
	swap	d1
	ror.w	#8,d1
	move.b	d1,(a1)
	
	move.l 	(a0)+,d1
	moveq.l	#5,d0
;Gris foncé
\s2:	
	move.l	d1,(a2)+
	dbf	d0,\s2
	swap	d1
	ror.w	#8,d1
	move.b	d1,(a2)
	
	lea	16(a1),a1
	lea	16(a2),a2
	dbf	d3,\b0
	
	movea.l	a3,a0
	dbf	d2,\rep

	move.l	(a7)+,d2
	rts

move.l d2,-(a7)
>> inutil!
de plus je ne comprend pas trop ta routine...
tu chrges qu'une fois une ligne de sprite que tu recopie 5 fois etc.. enfin des truc qu'il faut que t'explqiues!

Mon motif à placer fait 32x16 pixels, par ligne il en faut 6 plus 16 pixels et par collone 12. Le format du sprite est entrelacé.

move.l d2,-(a7)

Pourquoi inutile? Je comprend pas ce que je dois sauvegarder comme registres...

Tous sauf d0, d1, d2, a0 et a1.

bon je pige pas trop..

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


section ".data"
xdef DrawScreen

DrawScreen:
move.l d2,-(a7) ; inutile
lea 322(a1),a1 ; pkoi pas.. je connais pas le format de sprite, mais si c'est static l'offset je vosi pas trop l'interet de le calculer a chaque fois..
lea 8000(a1),a2 ; a ma limite la ca ce comprend et encore
movea.l a0,a3 ;
moveq.l #11,d2 ; 12 loops

\rep:
moveq.l #15,d3 ; 16 loops

;Sprite totale
\b0:
move.l (a0)+,d1 ; 32 pxl du premier sprite
moveq.l #5,d0 ; 6 loops
;Gris clair
\s1:
move.l d1,(a1)+ ; on recopie les 32 pixels 6 fois a la suite, soit sur 192 pixel
dbf d0,\s1; deja la le dbf est de loin non negligeable => lent
swap d1
ror.w #8,d1
move.b d1,(a1) ; ... ?? .. ??

move.l (a0)+,d1 ;on passe a l'autre plan..
moveq.l #5,d0
;Gris foncé
\s2:
move.l d1,(a2)+; 8000(a1)... mettre dans l'autre dbf??
dbf d0,\s2
swap d1
ror.w #8,d1
move.b d1,(a2) ;...

lea 16(a1),a1
lea 16(a2),a2;//
dbf d3,\b0

movea.l a3,a0
dbf d2,\rep

move.l (a7)+,d2 ; inutile rts

en bref je comprend pas ta methode...

OK je t'explique ligne à ligne:

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


section ".data" 
xdef DrawScreen 

DrawScreen: 
move.l d2,-(a7) ; inutile 
lea 322(a1),a1 ;On commence à x=16 et y=8 (plan0)
lea 8000(a1),a2 ; Plan1
movea.l a0,a3 ; Sauvegarde l'adresse du sprite
moveq.l #11,d2 ; répétion du sprite suivant y

\rep: 
moveq.l #15,d3 ; Réptition pour dessiner les 16 lignes du sprites

;Sprite totale 
\b0: 
move.l (a0)+,d1 ; ligne en cours de 32 pixels
moveq.l #5,d0 ; Répété suivant x 6 fois
;Gris clair 
\s1: 
move.l d1,(a1)+ ; on recopie les 32 pixels 6 fois a la suite, soit sur 192 pixel 
dbf d0,\s1; je sais c'est lent et je cherche une solution
swap d1  ;inverse le sprite, on veux récupére que 16 pixels soit un word
ror.w #8,d1  ;On récupérer le bout du motif
move.b d1,(a1) ; on termine la ligne soit 208 pixels du motif (32*6+16)

move.l (a0)+,d1 ;on passe a l'autre plan.. 
moveq.l #5,d0 ;Répété suivant x 6 fois soit 32*6 pixels
;Gris foncé 
\s2: 
move.l d1,(a2)+; 8000(a1) plan1
dbf d0,\s2 
swap d1  ;récupère un bout du motif soit 16 pixels...
ror.w #8,d1 
move.b d1,(a2) ;... 

lea 16(a1),a1 ;on passe à la ligne suivant soit 320-224 pixels.
lea 16(a2),a2;;idem pour le plan 1 cette fois
dbf d3,\b0 ;et on répéte la ligne suivante

movea.l a3,a0 ;on répéte le motif suivant 16 autre ligns
dbf d2,\rep 

move.l (a7)+,d2 ; inutile 
rts

Oui, tu peux déjà dérouler tes boucles (sans trop te soucier de ce que te dira Kevin ), ça ne te fait perdre que 4 octets par boucle.

swap/ror.w#8 = rol.l#8, ou bien optimisé vitesse (+2 octets, -12 cycles) : move.b -4(a0),d1

Bon je sens que je vais en dire trop

Oups désolé pour le dernier post, je n'avais pas vu l'instruction d'après :
move.b -4(a0),(a1) est "optimale"

A noter que tu pourrais aller dans l'autre sens (-(a0) et pas (a0)+) pour économiser 2 cycles et 2 octets par demi-boucle...

Aussi, grosse erreur ! Tu sauvegardes d2 (qui est inutile) mais pas a2 (que tu dois sauvegarder) !

En fait tu peux te passer de a2 en ajoutant, au milieu de la boucle :
lea 8000-192(a1),a1
puis en remplaçant les occurrences de a2 par a1, puis avec :
lea -8000+16(a1),a1

OK, merci pour tout ça.

donc si je comprend bien t'as un sprite de 32x16 que tu dois recopier sur un GPlan comme une mosaique?

Voilà.

j'aurais bien qqs idées mais ca va etre barbar

Bah oui, après c'est encore tout à fait possible d'optimiser (notamment pour éviter les lectures en trop), mais le gain devient vraiment négligeable (puisqu'avec les suggestions qu'on lui a fait la routine va passer 75% du temps à écrire, et de toute façon c'est incompressible...)

perso je copierai 16 lignes d'ecran.
puis apres par coup de movem je recopie les ligne a la suite... mais bon j'ai pas testé, mais je pense qu'on y gagne

Comment ça 75% du temps? Et pourquoi incompréhensible? je pense que tu trouve ce que je fais inutile et vraiment bête? Tu pense que le meieux est d'utiliser un buffer et de le recopier? Et comment faire pour éviter cette routine à chaque frame en plusu avec du double buffering (ce que je fais).

perso je copierai 16 lignes d'ecran. puis apres par coup de movem je recopie les ligne a la suite... mais bon j'ai pas testé, mais je pense qu'on y gagne

Evidemment, on peut parfaitement faire :

move.l (a0)+,d0
move.l d0,d1
move.l d0,d2
...
movem.l d0-d6,(a1)
movem.l d0-d6,208*16*1(a1)
movem.l d0-d6,208*16*2(a1)
...

(on déborde, mais c'est pas grave )

Comment ça 75% du temps?

Regarde les clocks de la routine et tu verras qu'environ 75% du temps est passé à faire des move.l d1,(a1)+.

Et pourquoi incompréhensible?

erf, j'ai dit incompressible

(bon, OK c'est pas totalement incompressible, puisqu'on peut supprimer 30% du temps que ça prend avec des movem; la vraie question, c'est plutôt : est-ce que c'est utile de sacrifier de la place pour des movem pour une routine qui n'a pas forcément besoin d'être très optimisée?)

heu je ferais pas tout a fait comme ca..
je ferait sa technique pour les 16 premieres lignes puis:
movem.l d0-d6/a1-a7,(a0)+
en bref bourin de base