Arkanoid - Page 7

Oui avec des routines en ASM 68K voir GNU 68K, je mixte.
OK je vais suivre ton conseil.

De plus il semble y avoir un problème quand je programme mes routines en ASM 68K en utilisant a6 comme paramètre, a6 est utilisé par GCC par un pointeur frame? Est-ce que si je programme en A68K GNU je peux utiliser ce registre (a6)?

De plus je dois sauver quoi comme registres en ASM 68K et quoi en GNU 68K?

[EDIT] Ah oui mon format:
format entrelacé, suivant sprites 8,16,32, premier ligne plan0, deuxième ligne plan1, 3ème ligne plan0, 4ème ligne plan 1...

Mon buffer de travail fait 320x200 pixels soit 8 Ko par plan.

Est-ce que si je programme en A68K GNU je peux utiliser ce registre (a6)?

Je ne suis pas sûr.

De plus il semble y avoir un problème quand je programme mes routines en ASM 68K en utilisant a6 comme paramètre, a6 est utilisé par GCC par un pointeur frame?

Tu peux quand même l'utiliser à l'intérieur d'une fonction ASM comme variable temporaire (à condition évidemment de le restaurer à la fin )

De plus je dois sauver quoi comme registres en ASM 68K et quoi en GNU 68K?

Pareil, d0-d2/a0-a1. Enfin tu peux changer avec de l'ASM inline, mais ça ne sera pas vraiment plus efficace.

Tu peux quand même l'utiliser à l'intérieur d'une fonction ASM comme variable temporaire (à condition évidemment de le restaurer à la fin )

Euh si a6 est un paramètre de la fonction, comment veut tu que je le restaure.
Bon je vais essayer de ce pas en ASM GNU68K.

a6 est un paramètre de la fonction

Miam, quelle bonne idée Et il est où l'intérêt, par rapport au fait d'utiliser a0 comme tout le monde?

Je déconseille l'utilisation de %a6 pour le passage par registres.

Et je déconseille l'utilisation de a6 sans le % aussi (i.e. avec GTC )

Miam, quelle bonne idée Et il est où l'intérêt, par rapport au fait d'utiliser a0 comme tout le monde?

Figure toi que j'ai beaucoup de paramètres à passer et dont que je doit déborder sur a6.

a6 est très important donc j'ai laissé tombé et j'ai donc enlever un argument pour développer 2 fonctions au lieu de une.

Et je déconseille l'utilisation de a6 sans le % aussi (i.e. avec GTC )

Je vais pas tester.

geogeo>utiliser la pile c'est pas inderdit non plus. Si tu utilises une un nombre important de registres, gcc les sauvegardera lui-même donc, équilibre entre les registres et la pile
(Enfin, je veux dire que les variables stockées dans des registres-paramètres devront être écrites en mémoire pour pouvoir utiliser ces registres comme paramètres )

Je sais que la pile existe mais pour cette fonction je préférer éviter. En tout cas le problème est résolue.

Avec la pile ça aurait compliqué la fonction et produit un code plus gros...

Voici une version alpha de chez alpha:
http://perso.wanadoo.fr/tisofts/arkanoid/arkanoid1.zip

Quelqu'un pourrais tester sur TI92+ et V200 et dire si il n'y a aucun bug (j'entend par là pas de plantage ou bugs graphique).

La démo est simple, environnement graphique sans briques avec le décors de base et 10 billes en mouvement dans ce décors. La zone graphique fait 320x200 donc 224x200 pixels correspondent à la zone de jeu. De plus la démo semble fluide, si les collisions son bizarre dite le moi.

Ah oui PolySnd v2.0 tourne derrière en tâche de fond, bien sûr sans son mais l'interruption est là.
Par contre l'adpatation sur TI89 me fait assez peur du à la résolution de l'écran.

ergl, utiliser tous les registres pour les paramètres ça doit baisser les performances plutôt que de les améliorer...

J'ai fait ça à une fonction qui le mérité malheuresement.

Ah oui désolé je viens d'ajouter dans le pack les 2 fichiers indispensable (ark_gfx et ark_snd).

ça doit baisser les performances plutôt que de les améliorer

J'ai fait ça à une fonction qui le mérité malheuresement.

Elle méritait qu'on baisse ses performances? Amende pour excès de vitesse : utilisez tous les registres d'adresse comme paramètre.

lol

Elle méritait qu'on baisse ses performances? Amende pour excès de vitesse : utilisez tous les registres d'adresse comme paramètre.

Tu n'as pas lu ce que j'ai écrit, si je passais les paramètres par la pile, j'aurais était obligé de ralonger le code et donc de ralentir la routine. En tout cas pour l'instant c'est fluide et assez rapide je pense.

Tu n'as pas lu ce que j'ai écrit, si je passais les paramètres par la pile, j'aurais était obligé de ralonger le code et donc de ralentir la routine.

Je serais curieux de voir ça.

quoi c la routine qui a besoin de 7 params ?

OK alors je devais réalisé une fonction qui avait pour but de dessiner 5 sprites différent de différente taille dans des zone précise au dessus de l'écran. Les 4 sprites qui compose la barre en haut et l'autre formant le cadre.
Il me fallait:
a0 pour la destination plan0
a1 pour la destination plan1
a2 sprite1
a3 sprite2
a4 sprite3
a5 sprite4
a6 sprite5

Il y avait un cas ou je devais transformer 2 sprites de 8x8 en 32x8 soit passer de char à long.
Mais le problème est résolus j'ai pas envie de me prendre la tête avec ça.

Heu... Je comprends pas. T'as pas envisagé de mettre les sprites à la suite et de ne passer qu'une seule adresse ?

Bah en fait les sprites risque de changer pas tous mais certains. En tout cas si j'ai fait ça c'est qu'il y a une raison, je sais passer par la pile quand il le faut...

En tout cas si j'ai fait ça c'est qu'il y a une raison, je sais passer par la pile quand il le faut...

Montre nous ton code et on va voir s'il y a effectivement une raison. Perso, j'ai de gros doutes là-dessus.

Euh j'ai plus le code puisque j'ai retiré un paramètre et j'ai crée une autre fonction.
La première fonction

;C prototype: void DrawSquareUp (unsigned char *sprt1, unsigned char *sptr2, unsigned char *sprt3, unsigned char *sprt4, void *dest);
;
;void DrawSquareUp (register unsigned char *sprt1 asm("%a2"),
;		  register unsigned char *sprt2 asm("%a3"),
;		  register unsigned char *sprt3 asm("%a4"),
;		  register unsigned long *sprt4 asm("%a5"),
;		  register void *dest asm("%a0"));

	section ".data"
	xdef DrawSquareUp

DrawSquareUp:
	movem.l	d0-d2/a1,-(a7)
	lea	8000(a0),a1
	moveq.l	#7,d5
	
bcl_draw_sprite8:
	clr.l	d0
	clr.l	d3
	
	move.b	(a4)+,d0
	move.b	(a4)+,d3
	
	;Corner left
	move.b	(a2)+,(a0)+
	move.b	(a2)+,(a1)+
	
	;Up x 3
	move.b	d0,(a0)+	
	move.b	d0,(a0)+
	move.b	d0,(a0)+
	move.b	d3,(a1)+	
	move.b	d3,(a1)+
	move.b	d3,(a1)+
	
	;Doors
	move.l	(a5),(a0)+
	move.l	4(a5),(a1)+
	
	;Up x 12
	;Long gris clair
	clr.l	d1
	clr.l	d2
	move.b	d0,d1
	rol.w	#8,d0
	or.w	d0,d1
	move.l	d1,d2
	swap.l	d1
	or.l	d1,d2
	
	;Long gris foncé
	clr.l	d1
	clr.l	d4
	move.b	d3,d1
	rol.w	#8,d3
	or.w	d3,d1
	move.l	d1,d4
	swap.l	d1
	or.l	d1,d4
	
	move.l	d2,(a0)+
	move.l	d2,(a0)+
	move.l	d2,(a0)+
	move.l	d4,(a1)+
	move.l	d4,(a1)+
	move.l	d4,(a1)+
	
	;Doors
	move.l	(a5)+,(a0)+
	move.l	(a5)+,(a1)+
	
	;Up x 3
	move.l	d2,(a0)+	
	move.l	d4,(a1)+
	
	;Corner right
	move.b	(a3)+,-1(a0)
	move.b	(a3)+,-1(a1)
		
	lea	12(a0),a0
	lea	12(a1),a1
	dbf	d5,bcl_draw_sprite8
	movem.l	(a7)+,d0-d2/a1
	rts

La deuxième fonction:

;C prototype: void DrawSquareSide (unsigned char *sprt, void *dest);
;
;void DrawSquareSide (register unsigned char *sprt asm("%a2"),
;		      register void *dest asm("%a0"));

	section ".data"
	xdef DrawSquareSide

DrawSquareSide:
	movem.l	a1/a3,-(a7)
	movea.l	a2,a3
	lea	320(a0),a0
	lea	8000(a0),a1
	
	moveq.l	#5,d6
\bcl_draw_all_left:
	moveq.l	#31,d7
	movea.l	a3,a2
	
\bcl_draw_left8:
	move.b	(a2),(a0)
	move.b	(a2)+,27(a0)
	move.b	(a2),(a1)
	move.b	(a2)+,27(a1)
	lea	40(a0),a0
	lea	40(a1),a1
	dbf	d7,\bcl_draw_left8
	dbf	d6,\bcl_draw_all_left
	movem.l	(a7)+,a1/a3
	rts

Mais ça n'as plus rien à voir avec le problème.

Un petit screen de l'avancement du projet, je compte être fidèle à Arkanoid revenge of DOH sur ATARI ST.

http://perso.wanadoo.fr/tisofts/arkanoid/screens/screen4.gif

Franchement, ton scrolling est grave lourd. Arkanoid suppose vraiment qu'on voie tout l'écran de jeu. (Monster est lui aussi lourd pour la même raison.)

C'est pour ça que je demande des tests, moi j'aime bien sur real TI c'est vraiment jouable, on verras avec la raquette et les briques mais si je concentre le scrolling sur une zone quand il y a plusieurs bille c'est très jouable... De plus les fonds seront clair pour pas trop géner.

[EDIT] Le scrolling laisse vraiment du temps pour agir comparé à monster ou les briques sont trsè proche de la raquette ce qui le rend injouable, dans le cas contraire d'arkanoid il y a un espace minimum entre la raquette et les briques assez élevé. De plus le scrolling de monster ne ce fait qu'en horizontal. Par contre sur TI89 le scrolling risque de poser un problème.

./204> C'est vraiment pas malin... Pourquoi? L'allocateur de registre de la fonction qui appelle DrawSquareUp a deux possibilités :

- ne pas utiliser les registres An : ouille ouille ouille côté performance...
- ou bien les utiliser, mais alors il faut les restaurer au dessus de l'appel de la fonction :

movem.l a2-a6,-(a7)
move.l Plane0(pc),a0
move.l Plane1(pc),a1
lea sprite1(pc),a2
lea sprite2(pc),a3
lea sprite3(pc),a4
lea sprite4(pc),a5
lea sprite5(pc),a6
jsr DrawSquareUp
movem.l (a7)+,a2-a6
...

DrawSquareUp:
  movem.l *,-(a7)
  ...
  movem.l (a7)+,*
  rts

Alors que ce serait tellement plus simple de faire :

move.l Plane0(pc),a0
move.l Plane1(pc),a1
jsr DrawSquareUp
...

DrawSquareUp:
  movem.l */a2-a6,-(a7)
  lea sprite1(pc),a2
  lea sprite2(pc),a3
  lea sprite3(pc),a4
  lea sprite4(pc),a5
  lea sprite5(pc),a6
  ...
  movem.l (a7)+,*/a2-a6
  rts

En gros, même si le compilo ne fait pas la bêtise de réserver a2-a6 et de ne pas les utiliser, tu économises quand même deux movem, soit 8 octets et pas mal de cycles. Donc non, ton idée n'est pas bonne, surtout que si le compilo réserve a2-a6, tu vas avoir du code à proprement parler horrible.


A part ça, le screenshot a l'air pas mal, quoique je me méfierais du fond foncé qui risque de baver horriblement on-calc et qui empêchera peut-être de distinguer les balles dans certains cas.

Que signifie */a2-a6?

De plus tu me montre un cas ou on sais que ça sera toujours les même sprites d'affiché, impossibilité de changer l'affichage? Or moi il me faut ses arguments car l'environnement graphique peut changer...

A part ça, le screenshot a l'air pas mal, quoique je me méfierais du fond foncé qui risque de baver horriblement on-calc et qui empêchera peut-être de distinguer les balles dans certains cas.

Le fond est très clair et rend bien sur Real-TI, suffit de tester mais si beaucoup aime pas, je peux remédier au problème.

a0 pour la destination plan0
a1 pour la destination plan1
a2 sprite1
a3 sprite2
a4 sprite3
a5 sprite4
a6 sprite5

tu fais une structure qui contient les 5 sprites..
apres (a3)+ powa!!!

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é...