Arkanoid - Page 3

J'ai trouvé le problème, ça vient de ses 2 lignes:

not.w	d3
and.l	d3,d2

Elle ce trouve au début de la fonction, elle sert à trouver le nombre d'octets suivant x?

Ça sert à effacer la partie basse de x (les 4 premiers bits) pour après calculer l'offset selon x.
D'ailleurs ça me fait penser que c'est peut-être optimisable parce qu'au début je n'avais pas pensé à un détail qui m'a fait rajouter du code et cette partie devient redondante maintenant.
Mais en fait, je ne vois pas trop pourquoi ça pose problème puisque de toute façon, après on n'utilise que d2.w...
Et au fait, dans mon code, j'avais bien écrit and.w je ne sais pas pourquoi tu l'as réécrit en and.l

OK je viens de trouver le problème.

Au point de vue de l'optimisation je peut optimiser quoi?
Les parties de scrolling sur 32 bits ne sont pas optimisable?

Je n'ai rien trouvé d'optimisable
Si quelqu'un trouve quelque chose...

Là je suis en train de réaliser les fonctions qui s'occuperons d'afficher un nombre ou du texte à l'écran mais avec des polices spéciales. Le mieux est de mettre les polices dans un fichier externe ou dans le programme?

De plus, la fonction FastSprite8_OR_R n'est pas faite pour ça? Je pense réaliser une table de 2400 octets par polices, heuresement que j'ai mon logiciel qui me sort un format de police.

Tu peux afficher des caractères avec FastSprite8_OR, mais elle n'est pas optimisée pour, c'est tout. Donc il est possible de gagner encore un peu de vitesse en l'optimisant pour...


Mais pourquoi as-tu besoin d'une si grande puissance graphique ?
Tu affiches combien d'objets ?

Dans le cas ou la bille parcours 1 pixeks suivant x et y par frames, il faudra 238 fps par second pour parcourir aller du haut vers le bas en 1 seconde, bien sûr c'est trop, maintenant, il me reste que 50 fps, donc la billes fera 50 pixels par secondes donc elle mettera 5 secondes pour aller du haut vers le bas.

Rien qu'avec ça je justifie l'importance d'avoir un nombre de frames le plus élevé possible.

Voici un aperçu du projet qui avance assez vite:


Là j'ai fait une collision avec tout l'écran de 288x238 pixels mais normalement l'espace de jeu sera un peu plus petit en largeur.

IL y a 5 gros balles sur le jeu, une au centre et une dans chaque coin.

Dans ce screen c'est la vitesse normale des routines, je n'ai pas mis de boucles d'attente rien pour ralentir la vitesse.

Dans les jeux de casse briques, pour faire varier la vitesse de la balle, on applique un facteur de vitesse soit cos*v et sin*v? Ou on applique une attente sur la balle?

on change juste le vecteur directeur.. en géné c'est du (1,1) mais si tu fait du (2,1) c deja plus rapide, et vu que la vitesse depend de l'angle dans ce genre de jeu, c'est ce qu'il faut.
j'avait fait une sorte de brikout avec Xlib avec un fond d'ecran en 4 gray + les briques sans scroll avec gestion d'une 20 eine de boulles de toutes les tailles (le moteur etait flexible) et oui il faut une tres grande puissance graphique, puisqu'avec ca, Xlib etait deja en mal..

OK, et avec un vecteur directeur de (1,1), tu avais une vitesse plus rapide ou plus lente que le screen que je viens de mettre?

plus rapide
mais bon c'est tout a fait normale car les briques etaient affiché en x%16=0.
de toute maniere les routines de sasume sont equivalentes a celles de Xlib je pense..

Tu as un screen du jeu?

j'avais posté un screen du jeu sur le site de la Xteam, mais je sais pas si il y est encore faut demandé a godzil... d'ailleur sur ce frm aussi il me semble... mai ca date de 8 mois..

Ah, j'ai longtemps cherché et rien.

L'air du jeu fera 222x128 pixels et donc 66 pixels réservé en largeur pour des informations...
A vu d'oeil je dois tourner au alentours de 50 fps avec 10 balles en mouvement et déplacement de la 'caméra'.

Vous les voyez comment les collisions entre billes? Elle ce repousse seulement ou prennent des trajectoire différente en fonction du point de collision?

Qu'elles rebondissent vraiment l'une contre l'autre.

OK, je viens de faire ça.

Un problème ce pose pour les collisions, puisque la vitesse des billes est paramètrable cela indique le nombre de pixels par déplacement et donc pour des collisions entre billes elle ne sera pas parfaite, les billes ce fusionnerons, il faut donc que je puisse les mettre à une bonne distance.

Il faut juste que je detecte ou ce situe la première bille par rapport à la deuxième bille et que en fonction je calcul la bonne distance entre les 2 billes?

ca fait n! detections de collision bille/bille, ca risque de bien ralentir ton moteur

Bah je ne pense pas faire autrement.

Je pense qu'il faut procéder comme ceci :
- Tu déplaces les billes selon leur vecteur de vitesse
- Ensuite, tu vérifies les collisions entre les balles. Soit d la distance minimale entre 2 balles (égale à la somme des rayons respectifs des deux balles), tu regardes si la distance entre les deux balles qui sont en collision est inférieure à d. Si c'est le cas, ça veut dire que les deux balles se recouvrent au moins partiellement, dans ce cas, tu prends la différence entre d et la vraie distance et tu déplaces tes balles sur cette distance selon leur nouveau vecteur de déplacement en réponse à la collision.
- Tu affiches tes balles.

Voilà, ceci devrait être fonctionnel.
Tu les calcules comment, les collisions ?

Pourquoi tu as besoin de tant de billes ?

Je pense qu'il faut procéder comme ceci :
- Tu déplaces les billes selon leur vecteur de vitesse
- Ensuite, tu vérifies les collisions entre les balles. Soit d la distance minimale entre 2 balles (égale à la somme des rayons respectifs des deux balles), tu regardes si la distance entre les deux balles qui sont en collision est inférieure à d. Si c'est le cas, ça veut dire que les deux balles se recouvrent au moins partiellement, dans ce cas, tu prends la différence entre d et la vraie distance et tu déplaces tes balles sur cette distance selon leur nouveau vecteur de déplacement en réponse à la collision.
- Tu affiches tes balles.

Voilà, ceci devrait être fonctionnel. Tu les calcules comment, les collisions ?

C'est ce que je fait et ça bug. Or je n'ai pas de vecteurs de déplacements, mais je suis en train d'essayer un truc.

Si, tu as des vecteurs de déplacement.

Tu n'as pas répondu à ma question : tu calcules comment tes collisions ?

Jackos> "n!" ? Je dirais plutôt n.(n-1)/2 (=40 pour 10 balles)

En effet, c'est n(n-1)/2
C'est déjà plus acceptable

Tu n'as pas répondu à ma question : tu calcules comment tes collisions ?

Comme dans la méthode que tu viens de décrire.
Calcul de la distance entre le centre des 2 billes, si cette distance est inférieurs à la taille de la plus grosse balle suivant x et y alors collision.

Pour les vecteurs de directions, oui c'est simple à récupérer.

J'ai du mal m'exprimer : comment calcules-tu la réponse aux collisions ?
P.S. : pourquoi pas : n!/(2*(n-2)!) ?