Arkanoid - Page 12

Sasume
:

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 ?

Parce que:
1. la section par défaut est maintenant .text et pas .data, donc ton code passe dans la mauvaise, donc loin des autres fonctions, donc références non optimisables.
2. le linker n'optimise pas les sections de données.

Et puis pourquoi il y a (avait ?) des histoires de segment sur TI ?

Il n'y a pas de sections normalement, sauf éventuellement la section BSS (tout est mis dans la même section, .text en l'occurrence, c'était .data avant).

Kevin Kofler :
Parce que:
1. la section par défaut est maintenant .text et .data, donc ton code passe dans la mauvaise, donc loin des autres fonctions, donc références non optimisables.

Tu ne veux pas plutôt dire : "la section par défaut est maintenant .text et pas .data" ?

Il n'y a pas de sections normalement, sauf éventuellement la section BSS (tout est mis dans la même section, .text en l'occurrence, c'était .data avant).

Oui, mais pourquoi avant, il y avait cette histoire de section .data ? Je crois me souvenir que si on ne la précisait pas, ça créait des problèmes.

Pollux> Je vais voir ça alors, si tu penses que le gain sera vraiment intéressant, merci.

Le gain va être, pour x congru à -1 modulo 16, de 14*2-4=24 cycles par shift, donc sur une dizaine de shift, ça fait environ 200 cycles, qui est énorme par rapport à la trentaine de cycles d'un déroulement en 3 boucles...

Sasume
:

Kevin Kofler :
Parce que:
1. la section par défaut est maintenant .text et .data, donc ton code passe dans la mauvaise, donc loin des autres fonctions, donc références non optimisables.

Tu ne veux pas plutôt dire : "la section par défaut est maintenant .text et pas .data" ?

Si.

Il n'y a pas de sections normalement, sauf éventuellement la section BSS (tout est mis dans la même section, .text en l'occurrence, c'était .data avant).

Oui, mais pourquoi avant, il y avait cette histoire de section .data ? Je crois me souvenir que si on ne la précisait pas, ça créait des problèmes.

Parce que la section par défaut était .data, tout simplement. On a changé ça dans notre GCC parce que ça posait problème pour certains trucs pour le nouveau linker.

Une petite question:

Si je fait moveq #-1,d0 puis move.l d0,(a0), y a une différence avec move.l #-1,(a0)? Je prend pas en compte moveq #-1,d0?

Perso je pense que la routine est parfaite de plus j'ai optimisé d'autres parties et j'arrive à 70 fps. Je fait cela car je dois réafficher à chaque frame les briques et les briques pour certaines ne seront pas à des positions fixe et comme j'ai fait l'expérience avec une tentative d'arkanoid, l'affichage des briques est lent.

Oui, il y a une différence de taille et de vitesse.

Je présume que move.l #-1,(a0) est plus lent et plus gros?

Oui

je pense que la routine est parfaite

Il vaut mieux éviter de dire ça, parce que certains pourraient te donner tort par pur esprit de contradiction

geogeo
: Perso je pense que la routine est parfaite

Moi pas. Je pense pouvoir diviser la taille au moins par 4.

Toujours aussi drôle Tu veux aussi forker Arkanoid, pdt que t'y es?

Non, juste optimiser (en taille) la routine de sprites pour le défi.
Je n'ai aucune intention de forker les programmes de geogeo, et sa licence ne le permet d'ailleurs pas.

Non, juste optimiser (en taille) la routine de sprites pour le défi.

Je crois que tout le monde se tape du "défi" qui consiste à gagner 50 octets pour perdre 30% de fluidité...

Je voudrais avoir juste un conseil:

J'ai réalisé la gestion de map mais pour l'instant j'affiche la matrice de briques de 13x18 à chaque frame, bien sûr je divise le nombres de frames par secondes par 2. J'ai donc pensé à réaliser un buffer qui contiendera cette map, il fera 6864 octets puis afficher à chaque frames ce buffer et le modifier dans le cas d'une brique cassé...

Voyez vous utile de prendre 6 Ko pour ça? De plus lorsqu'un brique est cassé il faurt restaurer le précédent fond, donc réaffciher le décors, la nouvelle map... pensez vous que des que je casse une brique le jeu ralentira? Et pour avoir des collisions effecticace des billes avec les briques, il faut mieux lire chaque coordonnées de la map ou calculer la position de la bille et donc quelle brique elle touche?

Niveau GamePlay:
-Il existera des briques qui pourrons ce déplacer horizontalement, des briques incassable, des briques difficle à détruire (2 coups) et enfin des briques après destruction et après un certains temps réapparaissent.
Au total il y a 12 briques et il y aura 29 niveaux différent. (j'ai réalisé le premier et c'est assez beau. )

Par contre niveau décors il y a un décors qui passe mal, celui présent dans l'animation, il est trop foncé.

Voyez vous utile de prendre 6 Ko pour ça? De plus lorsqu'un brique est cassé il faurt restaurer le précédent fond, donc réaffciher le décors, la nouvelle map... pensez vous que des que je casse une brique le jeu ralentira?

Je dirais même que c'est utile de prendre ces 6 ko si et seulement si avec une implémentation telle que ce que tu décris, le jeu ralentira (surtout si tu mets une animation lorsque la brique se casse, alors là ça devrait bien ralentir si l'affichage du fond n'est pas négligeable).

Ce que je te conseille, c'est d'abord de voir si le gain en fluidité vaudrait ces 6 ko (pour ça, benche avec et sans affichage du fond -- ce n'est pas un problème qu'il ne soit pas initialisé, puisque la vitesse de tes routines de scrolling est complètement indépendante du contenu).
Ensuite, si ça vaut le coup, alors tu peux enregistrer les tiles sous deux formes _à la fois_ :
- un tableau de 6864 octets représentant la map (graphiquement)
- 'char map[18][13]' représentant le contenu de la map par le numéro de chaque tile
Après, tu crées une routine 'Paint(char newmap[18][13])' qui compare 'newmap' à 'map' et qui n'affiche que les tiles qui ont changé (donc peut-être routine d'affichage de tile supplémentaire...), puis qui memcpy newmap sur map. Ca te permet de bénéficier de l'amélioration en fps, sans pour autant saccader dès qu'une brique est cassée...

Et pour avoir des collisions effecticace des billes avec les briques, il faut mieux lire chaque coordonnées de la map ou calculer la position de la bille et donc quelle brique elle touche?

Heu?

Je dirais même que c'est utile de prendre ces 6 ko si et seulement si avec une implémentation telle que ce que tu décris, le jeu ralentira (surtout si tu mets une animation lorsque la brique se casse, alors là ça devrait bien ralentir si l'affichage du fond n'est pas négligeable).

Ce que je te conseille, c'est d'abord de voir si le gain en fluidité vaudrait ces 6 ko (pour ça, benche avec et sans affichage du fond -- ce n'est pas un problème qu'il ne soit pas initialisé, puisque la vitesse de tes routines de scrolling est complètement indépendante du contenu).
Ensuite, si ça vaut le coup, alors tu peux enregistrer les tiles sous deux formes _à la fois_ :
- un tableau de 6864 octets représentant la map (graphiquement)
- 'char map[18][13]' représentant le contenu de la map par le numéro de chaque tile Après, tu crées une routine 'Paint(char newmap[18][13])' qui compare 'newmap' à 'map' et qui n'affiche que les tiles qui ont changé (donc peut-être routine d'affichage de tile supplémentaire...), puis qui memcpy newmap sur map. Ca te permet de bénéficier de l'amélioration en fps, sans pour autant saccader dès qu'une brique est cassée...

L'idée de comparaison ne me plait pas car si je dois comparer chaque briques (13 par ligne et 18 par colonnes) ça risque d'être très lent.
De plus il faut des effets d'ombres, certaines briques ne sont pas fixe et en effet une destruction d'une brique provoque une animation. Je vais d'abord voir avec un buffer de 6864 octets.

Pour ma dernière question je voulez savoir si il était plus efficace de voir les briques une par une et tester si il y a collisions avec la bille ou carrément calculer les briques proche ou ce situe la bille?

L'idée de comparaison ne me plait pas car si je dois comparer chaque briques (13 par ligne et 18 par colonnes) ça risque d'être très lent.

Tu rigoles ? 250 fois * 22 cycles, ça fait environ 500 cycles, donc si ton jeu tourne à 100 fps, ça prend 50000 cycles, soit 0.5% du processeur
Et je te rappelle que si tu redessines tout à chaque fois, alors tu fais un truc bien plus compliqué (afficher le sprite!), à chaque fois...

Oui j'ai vais tester ses solutions.

Au fait, ne me dit pas que tu nous as demandé comment optimiser la routine de fond alors que le fond est statique?

lol, bien sûr que non.

Voici le premier niveau d'arkanoid, l'image est un peu flou car c'est difficile de prendre un screenshots avec le scrolling...


Sur ce screen le fond est celui qui passe le moins bien je trouve, de plus il faut que je trouve comment réaliser des effets d'ombres correct mais avec 4 niveaux de gris ça semble pas simple.

Au fait, ne me dit pas que tu nous as demandé comment optimiser la routine de fond alors que le fond est statique?

lol, bien sûr que non.

Alors dans ce cas, tu es obligé de tout redessiner à chaque fois, non?


A part ça, le shot a l'air sympa Mais j'ai peur pour les 89...

Alors dans ce cas, tu es obligé de tout redessiner à chaque fois, non?

Oui. Mais je vais réflechir au problème.

A part ça, le shot a l'air sympa Mais j'ai peur pour les 89...

Moi aussi j'ai peur pour les TI89.

Voilà j'en pensé que sauvegarder la map dans un buffer puis dessiner ce buffer à chaque frame et la partie du décors manquante me permettrais de ne pas perdre beaucoups de frames.
J'ai donc réalisé cette fonction qui s'occupe d'afficher dans le buffer ScreenBuffer le contenu de BufferMap.

;C prototype: void CopyBufferMapToScreen (void *src, void *dest);
;
;void CopyBufferMapToScreen (register void *src asm("%a0"),
;		      	     register void *dest asm("%a1"));

	xdef CopyBufferMapToScreen

CopyBufferMapToScreen:
	lea	320(a1),a1
	move.l	#129,d0

;Gris clair	
\bcl_copy_buffermap_plan0:
	move.l	(a0)+,(a1)+
	move.l	(a0)+,(a1)+
	move.l	(a0)+,(a1)+
	move.l	(a0)+,(a1)+
	move.l	(a0)+,(a1)+
	move.l	(a0)+,(a1)+
	move.l	(a0)+,(a1)+
	
	lea	12(a1),a1
	dbf	d0,\bcl_copy_buffermap_plan0
	
	lea	8000-130*40(a1),a1
	move.l	#129,d0

;Gris foncé	
\bcl_copy_buffermap_plan1:
	move.l	(a0)+,(a1)+
	move.l	(a0)+,(a1)+
	move.l	(a0)+,(a1)+
	move.l	(a0)+,(a1)+
	move.l	(a0)+,(a1)+
	move.l	(a0)+,(a1)+
	move.l	(a0)+,(a1)+
	
	lea	12(a1),a1
	dbf	d0,\bcl_copy_buffermap_plan1	
	rts

Dans beaucoup de routines je fais une boucle pour chaque plan et dès que j'essaye d'en faire une pour les 2 plans, la fonction est lente, y a pas un moyen d'optimiser la fonction ci-dessus en faisant une boucle?

Y'aura la capsule spéciale ?

capsule spéciale? Tu parle de la raquette, celle qui tir?

Non, la capsule dorée sans lettre et qui fait de joulis trucs (genre B+N, ou L en autofire )

Ah oui bien sûr.
Par contre tu sais à quoi correspondent chaque lettres sur les capsules??

Houlà, faut que je me rappelle.

R = rétrécissement de la raquette
I = fantome
L = Laser
N = 3 balles qui se régénèrent si l'une des balles tombe trop bas (par contre, si les 3 tombent en même temps...)
V = balle qui tue tout sur son passage (et non B)
S = Ralentissment de la balle (pas de différence)
B = passage au niveau suivant...
C = Colle permettant de rattraper la balle et de la viser où ou veut
D = 5 balles. Si l'une d'elles tombent, elle tombe, point.

Faut que je DL le dsk Amstrad !!!

I fantôme??? Je connais pas ce bonus.

J'ai vu la version Amstrad c'est pas le premier Arkanoid avec 5 couleurs, si tu veut j'ai la version ATARI ST, NES ou PC. (Je me base sur la version ATARI ST car niveau graphique c'est la plus belle).

Pour les effets d'ombres, est ce que je me casse la tête à faire de vrais effets d'ombres ou tout simplement je met des zones noires?