cosinus et sinus - Page 2

Bah normalement la formule que je rendre ne doit pas donner un résultat supérieur à 255. Tout comme je fait avec y, rad=255-rad.

J'ai trouvé ça:

if ((xpos==0) || (xpos+8==LCD_WIDTH-1))
{
  if (rad>127) rad=255-(rad-128);
  else rad=128-rad;
}

Y a pas un moyen de simplifier sans conditions?

255-(rad-128)=127-rad et c'est quasiment la même chose que 128-rad alors tu dois pouvoir virer la condition en gardant 1 des deux expressions (celle qui est la bonne).

Non je ne peux pas en virer une seule, car ça m'obligera d'effectuer un modulo 255?

J'ai essayé les 2 à part, et ça ne fonctionne pas même en valeur absolue.

		if (rad<0) rad=255;	
		if (rad>255) rad=0;

C'est faux dès que tu peux faire varier 'rad' par pas de plus de 1. Utilise plutôt rad&=255, en plus c'est bien plus rapide.

psin=Tbl_psin [rad];

Tu n'as pas besoin de deux tables, puisque comme tu l'as d'ailleurs remarqué, sin(x)=cos(x+pi/2), donc Tbl_psin[rad]=Tbl_pcos[(rad+64)&255]. Si tu veux un peu plus de vitesse, tu peux définir Tbl_pcos pour faire 256+64=320 valeurs, comme ça tu peux écrire Tbl_psin[rad]=Tbl_pcos[rad+64].


Et enfin, chose cruciale (qui doit être la cause de ton pb) : il faut que tu mettes le clipping pour rad (i.e. "rad&=255") juste avant les accès à la table.

Et accessoirement "255 - rad" correspond à "pi*(255/256) - ton_angle", ce qui n'a pas grand intérêt... Utilise plutôt "256 - rad", autrement dit "- rad" (mais cela suppose évidemment que tu fasses le clipping au dernier moment, ce qui est de toute façon indispensable et ne coûte rien).

C'est faux dès que tu peux faire varier 'rad' par pas de plus de 1. Utilise plutôt rad&=255, en plus c'est bien plus rapide.

Pas bête, j'oublie souvent que des opérations binaires peuvent faire le même résultats et souvent bien plus rapidement.

Tu n'as pas besoin de deux tables, puisque comme tu l'as d'ailleurs remarqué, sin(x)=cos(x+pi/2), donc Tbl_psin[rad]=Tbl_pcos[(rad+64)&255]. Si tu veux un peu plus de vitesse, tu peux définir Tbl_pcos pour faire 256+64=320 valeurs, comme ça tu peux écrire Tbl_psin[rad]=Tbl_pcos[rad+64].

Oui, j'avais pour but d'enlever la table Tbl_psin, mais faire une table de 320 octets ça me fait retirer &255.

Et enfin, chose cruciale (qui doit être la cause de ton pb) : il faut que tu mettes le clipping pour rad (i.e. "rad&=255") juste avant les accès à la table.

Oui ça corrige mon problème et donc me facilite le calcul, car je retire les 2 conditions...

Et accessoirement "255 - rad" correspond à "pi*(255/256) - ton_angle", ce qui n'a pas grand intérêt... Utilise plutôt "256 - rad", autrement dit "- rad" (mais cela suppose évidemment que tu fasses le clipping au dernier moment, ce qui est de toute façon indispensable et ne coûte rien).

Ca fonctionne bien mieux.
Merci.

Pas bête, j'oublie souvent que des opérations binaires peuvent faire le même résultats et souvent bien plus rapidement.

Même sans opérations binaires (par exemple si tu n'avais pas pris pi=une puissance de 2), tu aurais pu écrire, pour éviter un modulo :

if (rad<0) rad+=256;
if (rad>=256) rad-=256;

si tu fais varier par pas de moins de 256 (cette contrainte t'obligerait par exemple à écrire "rad = 256-rad" au lieu de "rad = -rad", donc il faut faire encore un peu attention), ou bien dans le cas général :

while (rad<0) rad+=256;
while (rad>=256) rad-=256;

On peut même optimiser encore plus :

if ((unsigned int)rad>=256) {
  if (rad<0) do rad-=256; while (rad<0);
  else do rad+=256; while (rad>=256);
}

mais ça devient un peu inutile parce que la performance ne s'améliore pas dans le pire des cas... (on peut à ce moment-là optimiser en prenant une table de cos 2x trop grande pour supprimer une grande partie des cas de modulo, etc... mais de toutes façons on s'en fout parce que c'est tout sauf critique du point de vue performance )

Je vais rester comme ça.

Y a juste un bug, c'est lorsque rad=0 et qu'il y a collision suivant y, la balle sort de l'écran, ce n'est pas trop génant puisque ce cas n'arrivera jamais dans le jeu.

Non là les optimisations me suffisent, j'ai enfin réussit à faire ce que je voulais.

En remplaçant, -rad par rad=255-rad, je n'ai plus de bugs.

Tout d'abord, juste histoire de jouer le boulet qui s'attarde sur un détail sans importance aucune :

[...] en changeant l'angle de déplacement avec le curseur gauche et droit.

[...]

		if (_keytest ([4]RR_DOWN[/4])) rad-=2;
		if (_keytest ([4]RR_UP[/4])) rad+=2;

[...]

Concernant les variables :

[...]
	// avant _main
short pcos=0, psin=0;
[...]

//64 octets, pcos
const char Tbl_pcos [256] = {127,126,126,126,126,126,125,125,124,123,123,122,121,120,119,118,117,116,114,113,111,110,108,107,105,103,101,99,97,95,93,91,89,87,85,82,80,77,75,72,70,67,64,62,59,56,53,51,48,45,42,39,36,33,30,27,24,21,18,14,11,8,5,2,0,-3,-6,-10,-13,-16,-19,-22,-25,-28,-31,-34,-37,-40,-43,-46,-49,-52,-55,-57,-60,-63,-66,-68,-71,-73,-76,-78,-81,-83,-86,-88,-90,-92,-94,-96,-98,-100,-102,-104,-106,-107,-109,-111,-112,-113,-115,-116,-117,-118,-119,-120,-121,-122,-123,-124,-124,-125,-125,-126,-126,-126,-126,-126,-126,-126,-126,-126,-126,-125,-125,-124,-124,-123,-122,-121,-121,-120,-119,-117,-116,-115,-114,-112,-111,-109,-108,-106,-104,-102,-101,-99,-97,-95,-92,-90,-88,-86,-84,-81,-79,-76,-74,-71,-69,-66,-63,-61,-58,-55,-52,-49,-46,-43,-40,-38,-35,-32,-28,-25,-22,-19,-16,-13,-10,-7,-4,-1,2,5,8,11,14,17,20,23,26,29,32,35,38,41,44,47,50,53,56,59,61,64,67,69,72,75,77,79,82,84,87,89,91,93,95,97,99,101,103,105,106,108,110,111,113,114,115,117,118,119,120,121,122,123,123,124,125,125,125,126,126,126,126,127};
const char Tbl_psin [256] = {0,-3,-6,-9,-12,-15,-18,-21,-24,-27,-30,-33,-36,-39,-42,-45,-48,-51,-54,-57,-60,-62,-65,-68,-70,-73,-75,-78,-80,-83,-85,-87,-90,-92,-94,-96,-98,-100,-102,-104,-105,-107,-109,-110,-112,-113,-115,-116,-117,-118,-119,-120,-121,-122,-123,-124,-124,-125,-125,-126,-126,-126,-126,-126,-126,-126,-126,-126,-126,-125,-125,-124,-124,-123,-123,-122,-121,-120,-119,-118,-117,-115,-114,-113,-111,-110,-108,-106,-105,-103,-101,-99,-97,-95,-93,-91,-89,-86,-84,-82,-79,-77,-74,-72,-69,-66,-64,-61,-58,-56,-53,-50,-47,-44,-41,-38,-35,-32,-29,-26,-23,-20,-17,-14,-11,-8,-4,-1,1,4,7,10,13,16,20,23,26,29,32,35,38,41,44,47,50,52,55,58,61,63,66,69,71,74,76,79,81,84,86,88,90,93,95,97,99,101,103,104,106,108,109,111,112,114,115,116,118,119,120,121,122,122,123,124,124,125,125,126,126,126,126,126,126,126,126,126,126,125,125,124,124,123,122,121,120,119,118,117,116,115,113,112,110,109,107,106,104,102,100,98,96,94,92,90,88,85,83,81,78,76,73,71,68,65,63,60,57,54,52,49,46,43,40,37,34,31,28,25,22,19,16,12,9,6,3,0};

[...]
	// dans _main
	short rad=124;
	
[...]
		for (int i=0;i<10000;i++);
[...]

Les 2 tables Tbl_pcos et Tbl_psin vont de 0 à 255:
0=0
63=pi/2
127=pi
191=-pi/2
255=2pi
[...]

Pourquoi ne pas déclarer rad avant _main ?
Pourquoi ne pas déclarer rad en tant que unsigned char (si ce type existe) pour être sûr que rad reste dans [[0 ; 255]], donc qu'il n'y a pas de débordement de table, et même pour boucler automatiquement le début et la fin des tables sans avoir à ramener rad dans [[0 ; 255 ]] (le proc s'en charge lui-même avec juste le CF qui s'allume) ?
0) rad=255; if (rad>255) rad=0;Ca permettrait de s'affranchir de : if (rad<Sinon, plutôt que ce double-test, pourquoi ne pas faire un modulo 256 ?

Pourquoi ne pas déclarer pcos et psin après les tables pour leur donner des valeurs valides (au lieu de 0 et 0, mathématiquement impossible), voire les déclarer dans _main ?

Sachant que Cos(2pi)=Cos(0) et que Sin(2pi)=Sin(0), pourquoi mettre à la fois 0 et 2pi dans les tables ?
Pourquoi ne pas faire simplement une relation de proportionnalité de coefficient pi/128 entre l'indice rad et l'angle représenté ?
* 0 -> 0
* 64 -> pi/2
* 128 -> pi
* 192 -> 3pi/2
* 256 -> 2pi, avec 256<=>0 grâce à l'overflow (oui, je sais, c'est un abus de langage, puisque l'overflow ne concerne que les signés ...) et 2pi<=>0 grâce à la 2pi-périodicité de sinus et cosinus

Tu n'aurais pas oublié de déclarer i, à tout hasard ?
Concernant la vitesse (linéaire et de rotation) de la balle :

		if (_keytest (RR_DOWN)) rad-=2;
		if (_keytest (RR_UP)) rad+=2;

Si tu n'utilise que les indices pairs, pourquoi faire des tables 2 fois trop grandes ?
cos=vitesse_lin*Tbl_pcos [rad]; psin=vitesse_lin*Tbl_psin [rad];

Il serait peut-être plus intéressant de faire quelque chose comme :	//avant _main
char vitesse_lin=2, vitesse_rot=2;

[...]
		if (_keytest (RR_UP)) vitesse_lin+=1;
		if (_keytest (RR_DOWN)) vitesse_lin-=1;
		if (vitesse_lin<0) vitesse_lin=0;
		if (vitesse_lin>32) vitesse_lin=32;

		if (_keytest (RR_F1)) vitesse_rot+=1;
		if (_keytest (RR_F5)) vitesse_rot-=1;
		if (vitesse_rot<1) vitesse_rot=1;
		if (vitesse_rot>32) vitesse_rot=32;

		if (_keytest (RR_LEFT)) rad+=vitesse_rot;
		if (_keytest (RR_RIGHT)) rad-=vitesse_rot;

[...]

		p

Je pense ne pas avoir besoin de préciser le détail de ceci ...

1) rad=256-rad; // idem

Enfin, pour le rebond :		if (xpos==0) rad=128-rad;	// rebouclage automatique nécessaire, sinon faire un modulo 256 ou un double-test pour rester dans [[0 ; 255]]
		if (xpos+8==LCD_WIDTH-1) rad=128-rad;	// idem
		if (ypos==0) rad=256-rad;		// 256, pas 255, voire rad=-rad, s'il y a rebouclage automatique
		if (ypos+8==LCD_HEIGHT-

Donc tout pareil que Sasume, mais en un seul pavé indigeste ...

@++

Tout d'abord, juste histoire de jouer le boulet qui s'attarde sur un détail sans importance aucune :

C'est pas grave, mais juste pour signaler que c'est un programme de test rien d'autre et que comme tu le vois j'utilise que des fonctions du TIOS, des truc sassez lent pour l'affichage, or je n'utiliserais pas ça dans mon jeu.

Pourquoi ne pas déclarer rad avant _main ?
Pourquoi ne pas déclarer rad en tant que unsigned char (si ce type existe) pour être sûr que rad reste dans [[0 ; 255]], donc qu'il n'y a pas de débordement de table, et même pour boucler automatiquement le début et la fin des tables sans avoir à ramener rad dans [[0 ; 255 ]] (le proc s'en charge lui-même avec juste le CF qui s'allume) ? Ca permettrait de s'affranchir de :

Oui, c'est ce que j'ai fais, une fois les tests finit.

Sinon, plutôt que ce double-test, pourquoi ne pas faire un modulo 256 ?

A mon sens modulo est une chose à eviter je crois, des divisions et multiplications sont effcetué?

Pourquoi ne pas déclarer pcos et psin après les tables pour leur donner des valeurs valides (au lieu de 0 et 0, mathématiquement impossible), voire les déclarer dans _main ?

C'est un programme de test, donc j'ai pas fait attention. psin, pcos... seront dans la strcture des balles, autrements dit, ici ça n'a pas d'importance.

Tu n'aurais pas oublié de déclarer i, à tout hasard ?

i est déclaré dans la boucle, ça me facilite la vie.

Si tu n'utilise que les indices pairs, pourquoi faire des tables 2 fois trop grandes ? Il serait peut-être plus intéressant de faire quelque chose comme :

Programme de test.
J'ai besoin de toute ma table dans le jeu.

Donc tout pareil que Sasume, mais en un seul pavé indigeste ...

Tu sais, réaliser plein de pavé au début puis quand tu trouve une bonne solution tout regrouper c'est mieux que de tout regrouper au début, en tout cas je savais bien qu'il fallait faire toutes ses conditions en une.

Sachant que Cos(2pi)=Cos(0) et que Sin(2pi)=Sin(0), pourquoi mettre à la fois 0 et 2pi dans les tables ?

Par ce que c'est plus facile de gérer la table et de plus, je serais obliger d'effectuer des calculs qui me permetterons d'arriver à 0 ou à 2pi.

Pourquoi ne pas déclarer rad avant _main ?
Pourquoi ne pas déclarer rad en tant que unsigned char (si ce type existe) pour être sûr que rad reste dans [[0 ; 255]], donc qu'il n'y a pas de débordement de table, et même pour boucler automatiquement le début et la fin des tables sans avoir à ramener rad dans [[0 ; 255 ]] (le proc s'en charge lui-même avec juste le CF qui s'allume) ? Ca permettrait de s'affranchir de :

Oui, c'est ce que j'ai fais, une fois les tests finit.

Je ne recommande pas l'utilisation d'un unsigned char. Si le compilo optimise bien (meilleur des cas), ce sera aussi efficace qu'avec un int. Mais si le compilo n'optimise pas parfaitement, il va faire plusieurs fois l'extension de signe => moins efficace.
Et pour ce qui est de le mettre dans une variable globale, c'est moins efficace que dans une variable locale (le compilo ne peut pas forcément le mettre dans un registre). Mais bien entendu, si tu dois t'en servir dans plusieurs fonctions, ce n'est plus possible.

Sachant que Cos(2pi)=Cos(0) et que Sin(2pi)=Sin(0), pourquoi mettre à la fois 0 et 2pi dans les tables ?

Par ce que c'est plus facile de gérer la table et de plus, je serais obliger d'effectuer des calculs qui me permetterons d'arriver à 0 ou à 2pi.

Non, puisque tu dois calculer le modulo 256 (i.e. "&255") avant chaque lecture du tableau, donc tu n'auras jamais la valeur 256.

Oui je sais bien que je n'aurais jamais 256, ce que je veut dire c'est que je peux avoir la valeur 0 et 255 et donc il est inutile de les enlever.

De plus les variables dans ce programme de tests ce trouverons une structure.

0!=255... Ethaniel semblait dire que tu avais 257 valeurs, mais après vérification tu en as bien 256.

Oui j'en ai bien 256, pourquoi 257???

struct mystruct {
...
};

strcut mystruct *test[10]

Comment allouer 10 zones de mystruct dans test en même temps avec calloc?

Tu alloues ton bloc avec calloc, puis tu remplis 'test' avec une boucle.

Ok, je croyais qu'il était possible d'allouer 10 blocs en même temps et d'avoir test avec les bonnes adresses.

Non

Oui oui, il y a bien 256 valeurs, d'indices 0 à 255, mais avec 0->0 et 255->2pi, ce qui est inutile (égalité des premières et dernières valeurs) et anti-pratique (pi devant être représenté par 127.5 ...) : c'est au contraire ingérable, je trouve.
Mieux vaudrait représenter 2pi par l'indice 256 (d'où 64->pi/2, 128->pi et 192->3pi/2), valeur non présente dans la table, ou plutôt présente à l'indice 0 (avec modulo 256, ou mieux &255 comme l'a dit Pollux).
Les tables iraient donc de 0 à 255pi/128 (2pi - pi/128) par pas de pi/128.

Sur un unsigned, il n'y a pas de signe, donc pas d'extension de signe.
Et le char, c'est pour travailler directement en 8 bit, sans avoir besoin de faire une translation pour revenir dans [[0 ; 255]].
Mais si le short est déjà en 8 bits ... (je ne connais pas du tout le C sur TI).

@++

Oui, c'est évident qu'il faut avoir 2pi = 256, sinon il faut calculer tout modulo 255

• Ethaniel slaps itself users around with a small 50lb Unix Manual.

Je viens à l'instant de m'apercevoir que j'ai vraiment fait le GROS boulet : je n'avais pas fait gaffe à la seconde page, donc ai répondu sans avoir lu les posts ./31 à ./40 ...

Faire un modulo 255 ->

[...]
Y a juste un bug, c'est lorsque rad=0 et qu'il y a collision suivant y, la balle sort de l'écran, [...]

Si rad=0, la balle se déplace selon x (aucune composante selon y), donc ne peut pas avoir de collision selon y ...

@++

Oui, c'est évident qu'il faut avoir 2pi = 256, sinon il faut calculer tout modulo 255

Oui et je dépasse la table et je m'oblige donc à la coder en short.

Non sérieusement c'est parfait, d'autant que j'ai ce qu'il me faut.

Si rad=0, la balle se déplace selon x (aucune composante selon y), donc ne peut pas avoir de collision selon y ...

Euh bien sûr mais elle existe cette collision et heuresement, j'ai corrigé le bug ça n'a plus d'importance.

Oui et je dépasse la table et je m'oblige donc à la coder en short.

Tu ne dépasses rien du tout. (256&255) = 0 donc il n'y a pas de dépassement. Je n'avais pas vérifié ta table, mais effectivement tel que tu l'écris c'est faux : tu dois calculer x%255, qui est très lent (au lieu de x%256=x&255).

Je me fiche que je ne peux pas réellement faire 2pi/2..., surtout que ça n'a aucun interêt pour un casse briques que de créer des bugs, ici ça fonctionne très bien et ça me convient.

Pourquoi ce smiley? Ca veut dire que j'ai pas comrpis???

Soit plus explicite!!

Ben ça veut dire qu'il n'y a absolument aucune raison que tu utilises une table fausse alors que tu pourrais en utiliser une qui est juste... Ton code calcule les angles modulo 256, donc nécessairement 2pi doit correspondre mathématiquement à 256 (et pas 255). Après, ton code peut ne pas utiliser le nombre 256 (et donc tu n'as pas du tout besoin de passer aux shorts à cause de ça), mais en tout cas il doit utiliser table_sin[i] = sin(2pi*i/256) et pas sin(2pi*i/255) (sinon ce serait incohérent avec le reste de ton code).

• Ethaniel aussi


Il est dommage que tu t'arrêtes à une version qui marche mais qui n'exploite pas du tout les possibilités d'optimisation que permettent l'algorithmie et l'architecture du processeur.
De plus, il est alors totalement impossible du diriger la balle pile à la verticale ou vers la gauche, ce qui est un peu dommage et illogique.
En bref, ne te contente pas du minimum, surtout quand il est tout pourri ...

Je ne sais pas si Sasume partage mon opinion, mais telle est la mienne.


Quelqu'un pourrait-il SVP me faire un petit topo des types de variables utilisés en C sur TI (nom, nombre de bits utilisés, ...) ?
Je n'y connais rien, donc n'ai rien compris à la phrase 'je m'oblige donc à la coder en short'.

@++

[edit]Le temps que je rédige, Pollux a déjà répondu ...
• Ethaniel agrees with Pollux[/edit]

[edit2]En relisant le quote de Sasume, je me suis aperçu que j'avais manqué à tous mes principes ...[/edit2]