Arkanoid - Page 24

Mais ton code, il vérifie des séquences de bits consécutives, non ?

Là, tu comptes l'indice du bit à poids le plus fort, pas le nombre de bits à 1.

Oui, je pensais que c'était ça qu'il voulait

Je comprend pas, j'essaye de transformer la routine en C en ASM et la routine en ASM ne fonctionne par parfaitement.

Voici la routine en ASM:

;C prototype: BOOL CollideSprite32 (short x0,short y0,short x1,short y1,unsigned char h,void *sprite0,void *sprite1)
;
;BOOL CollideSprite32 (register short x0 asm ("%d0"),
;		       register short y0 asm ("%d1"),
;		       register short x1 asm ("%d2"),
;		       register short y1 asm ("%d3"),
;		       register unsigned char h asm ("%d4"),
;		       register void *sprite0 asm ("%a0"),
;		       register void *sprite1 asm ("%a1"));

	xdef CollideSprite32

CollideSprite32:
	;if (x0>x1)
	cmp.w	d2,d0
	bhi.s	_x0_superior
	sub.w	d0,d2
	bra.s	_continue
_x0_superior:
	sub.w	d2,d0
	move.w	d0,d2
	exg	a0,a1
	exg	d1,d3
	;dx->d2
_continue:
	cmp.w	#32,d2
	bge.s	_no_collide
	cmp.w	d3,d1
	bge.s	_y1_superior
	sub.w	d1,d3
	move.w	d3,d1
	lsl.w	#2,d3
	add.l	d3,a0
	bra.s	_continue1

_y1_superior:	
	sub.w	d3,d1
	move.w	d1,d3
	lsl.w	#2,d3
	add.l	d3,a1
_continue1:
	cmp.w	d4,d1
	blt.s	_test_collide
	move.l	#0,d0
	rts
	
_test_collide:
	addq.l	#1,d1
	move.l	(a0)+,d0
	move.l	(a1)+,d3
	lsl.l	d2,d3
	and.l	d0,d3
	tst.l	d3
	beq.s	_continue1
	moveq.l	#1,d0
	rts
		
_no_collide:
	moveq.l	#0,d0
	rts

Et voici la routine en C que j'essaye de transforme, cette routine fonctionne parfiatement:

//Teste collision entre sprite de 32 pixels
short TestCollideSprite32 (short x0, short y0, short x1, short y1, unsigned char h, unsigned long *sprite0, unsigned long *sprite1)
{
	short dx,dy,i;
		
	//Sprite 0 à droite de sprite 1
	if (x0<x1) dx=x1-x0;
	else
	{
		//Si sprite0 est à droite de sprite 1 juste
		//echanger les variables
		dx=x0-x1;
		SWAPDATA (sprite0,sprite1);
		SWAPDATA (y0,y1);
	}
	
	if (dx>=32) return 0; //Aucune collision
	
	if (y0<y1)
	{
		dy=y1-y0;
		sprite1+=dy;
	}
	else
	{
		dy=y0-y1;
		sprite0+=dy;
	}
		
	for (i=dy;i<h;i++,sprite0++,sprite1++)
	{
		if ((((unsigned long)*sprite1)<<dx) & (((unsigned long)*sprite0)))
			return 1;
	}
	
	return 0;
}

Désolé de mettre autant de code mais j'y suis depuis beaucoups trop de temps et je ne vois pas mon erreur.

T'es sûr qu'elle fonctionne correctement, la routine en C ?
Moi je verrais pluôt (*sprite1)>>dx

Je t'assure quelle fonctionne correctement et que la logique est bien <<dx.

Si sprite0 est avant sprite1, ça veut dire que si une partie de sprite1 est en collision avec sprite0, c'est forcément par son bord gauche, or en le décalant vers la gauche, tu perds l'info du bord gauche, donc ça ne peut pas être ça.

Ah bon pourtant j'ai testé énormément cette routine pixel après pixel et ça fonctionne.
Tu verrais quoi parce que j'y suis depuis toute la journée et je m'en sort pas.

Kevin> Quand on fait [code]a>>b[/code], la partie gauche de a est forcément remplie de 0 ?

geogeo> Est-ce utile que je code ça à ta place ?

Une fois n'est pas coutume

Je vais m'en passer mais ce que je ne comprend pas c'est pourquoi ma routine en C fonctionne à merveille? TIGCC apporte des modifications?

Une fois n'est pas coutume

Regarde les sources du jeu avant de parler!

Tu sais très bien ce que je veux dire
(et puis les sources non merci, vu ce que tu poste de temps en temps je préfere m'abstenir)

Ce que j'aime bien c'est que moi je ne dois pas poster dans tes topics quand tu me le demande alors que toi tu te le permet, tu ne te souvient pas ce que je t'ai dit. Tu me les brise ok.

geogeo
: Je vais m'en passer mais ce que je ne comprend pas c'est pourquoi ma routine en C fonctionne à merveille? TIGCC apporte des modifications?

Ou bien je me suis trompé dans mon raisonnement.
Réfléchis, fais des shémas sur papier avec tes deux sprites qui se chevauchent (pas de 16 pixels évidemment, mais une autre valeur), et conclues-en ce qu'il y a à conclure. Plutôt que de partir d'une routine existante sans forcément bien la comprendre.

Tout dépend de quel sprite on considère immobile, dans ma routine le sprite0:
Donc mon décalage vers la gacuhe ce justifie car lorsque mon sprite1 entre en collision avec un pixel avec le sprite0 suivant la gacuhe ou la droite il y a forcement 1 pixel de sprite1 qui entre dans la zone de sprite0 donc un décalage de 31 bits vers la gauche et ainsi de suite...

geogeo
: Ce que j'aime bien c'est que moi je ne dois pas poster dans tes topics quand tu me le demande

Alors oui, et ça peut être pour deux raisons :
• La première c'est dans le cas ou tu poste ds mon topic de bug repport de gcc, t'a absolument rien comprit au problème ni aux deux lignes de code que j'ai posté, mais tu viens quand même me prendre pour un neu² et sortir que je me suis planté.
• La deuxième c'est quand les 24 pages de ton topic ne te suffisent plus et que tu te répend dans des topics qui n'ont rien à voir.
Dans les deux cas c'est justifié

Bon je viens d'appliquer le décalage dans l'autre sens et ça fonctionne pareil mais la routine en ASM bug pareil. J'ai dû faire une erreur de manipulation de registres sans doute.

Dans ta routine, tu te débrouilles pour que x0 soit forcément inférieur à x1, ce qui implique que ce sera forcément la bordure gauche de sprite1 qui sera en collision avec la bordure droite de sprite0.
Donc déjà, ton décalage ne peut pas détruire la bordure gauche de sprite1.

Ce n'est pas normal que ça soit pareil dans les deux sens.
Tu utilises quoi comme sprites pour tester ?

Au fait, j'ai l'impression qu'il y a aussi un problème avec les y : il me semble que tu as inversé sprite0+=dy et sprite1+=dy

no_collide: moveq.l #0,d0 move.w (a7)+,d3 rts

Je m'ennuyais, donc j'ai essayé de le faire en ASM.
;short CollideSprite32 (register short x0 asm ("%d0"),
;		       register short y0 asm ("%d1"),
;		       register short x1 asm ("%d2"),
;		       register short y1 asm ("%d3"),
;		       register unsigned char h asm ("%d4"),
;		       register void *sprite0 asm ("%a0"),
;		       register void *sprite1 asm ("%a1"));

	xdef CollideSprite32

CollideSprite32:
	move.w	d3,-(a7)
	;if (x0>x1)
	cmp.w	d2,d0
	bls.s	_x1_superior
	exg.w	d0,d2
	exg.w	d1,d3
	exg.l	a0,a1
_x1_superior:
	sub.w	d0,d2
	;dx->d2

	cmpi.w	#32,d2
	bge.s	_no_collide
	cmp.w	d3,d1
	bge.s	_y0_superior
	sub.w	d1,d3
	move.w	d3,d1
	lsl.w	#2,d3
	add.w	d3,a0
	bra.s	_continue1

_y0_superior:	
	sub.w	d3,d1
	move.w	d1,d3
	lsl.w	#2,d3
	add.w	d3,a1
_continue1:
	cmp.w	d4,d1
	bge.s	_no_collide

	addq.w	#1,d1
	move.l	(a0)+,d0
	move.l	(a1)+,d3
	lsr.l	d2,d3
	and.l	d3,d0
	beq.s	_continue1
	move.w	(a7)+,d3
	rts
		
_

Est-ce que ça marche ? Je n'ai pas testé.
On peut probablement l'accélérer avec un dbf pour la boucle, mais là je vais me coucher.
Sinon, fais gaffe, tu avais fait pas mal d'erreurs portant sur la taille de l'opérande (.w au lieu de .l ou l'inverse)

geogeo :
Je comprend pas, j'essaye de transformer la routine en C en ASM et la routine en ASM ne fonctionne par parfaitement.

tigcc -S

Sasume
: Kevin> Quand on fait [code]a>>b[/code], la partie gauche de a est forcément remplie de 0 ?

Non, si a est signé et négatif, alors elle est remplie de 1.
Si a est signé, >> est compilé en asr, pas lsr.

Je comprend mieux mes erreurs maintenant. Je vais tester ça.
Donc en gros ma routine était faite à l'envers.

Kevin Kofler
:

Sasume
: Kevin> Quand on fait [code]a>>b[/code], la partie gauche de a est forcément remplie de 0 ?

Non, si a est signé et négatif, alors elle est remplie de 1.
Si a est signé, >> est compilé en asr, pas lsr.

OK, c'est ce qui me semble le plus logique.
Mais il me semble que le standart ne précise rien, donc il faudrait l'indiquer dans la doc (enfin, en tout cas je ne l'ai pas vu, mais peut-être que ça y est).

Le standard dit que c'est "implementation-defined". La définition de TIGCC est la plus logique, étant donné que le 68k gère les asr.

Oui oui, j'aurais juste préféré trouver ça dans la doc directement...

Les fonctions de collisions ainsi que les fonctions de copie de masque fonctionnent à merveille maintenant merci sasume.
De plus les routines sont très rapide et le jeu n'a pas perdu énormément de fps soit environ 2.

J'ai un petit problème de gestion de Bonus et je voudrais savoir ce que vous en pensez, voici la liste des Bonus.

L (Rouge) = Laser.
E (Bleu)   = Grande raquette.
M (Blanc)= 3 billes qui ce régénère.
S (OR)     = Ralentissement de la bille (vitesse d’origine).
C (Vert)  = Colle permettant de rattraper la balle et de la viser où on veut.
P (Gris)   = Vie supplémentaire.
B (Rose)  = Passage au niveau suivant...
D (Cyan) = 5 balles. Si l'une d'elles tombent, elles tombent toute.
I (Vert)   = Traînée Fantôme.
R (Noir)  = Rétrécissement de la raquette. 
M (Rose) = Bille de feu.
T (Bleu)   = Double raquette moyenne. 
OR           = Combinaison

Par défaut vous verrez quoi comme combinaison de Bonus de préférence de petites combinaison pour laisser le Bonus OR qui réalisera des combinaison complexe...

A savoir qu'il n'y a aucunes contraintes car le moteur est capable de gérer toutes les combinaisons meêm Bonus Colle avec Bonus vaisseau de tir, à savoir que chaque Bille à son appartenance à une raquette et donc les Bonus récolté par la raquette du joueur n'auront effet que pour les Billes appartenant à la raquette du joueur et non la raquette de l'IA... voir tout le jeu...

Mais enfin, c'est ton jeu, à chaque ligne de code tu vas nous demander notre avis ?