Re: Mr ToutLeMonde et la programmation NES...

par Invité Jeu 19 Oct 2017 - 16:36

une question : tu as choisi de n'avoir que 32 angles, mais qu'est ce qui t'empêchais d'en avoir 64, 128 ou 256 ? Je me doute qu'il y a une raison, mais je n'arrive pas à voir où ça coince justement

je pense que pour limiter la taille des tables, les angles sont codés sur 5 bits (au lieu de 8), donc 32 angles possibles .

Voir même 16, pour pouvoir en stocker deux par octet.

Ca peut le faire,in game le manque de précision passerait probablement inaperçu .

par upsilandre Jeu 19 Oct 2017 - 17:00

Je pense surtout que comme dit Typhon la précision est quand meme pas top et pas symetrique, c'est plus ou moins précis selon la direction. En reduisant a 32 angles on lisse un peu tout ca tout en reduisant les tables finales (qui sont quand meme 4 donc ca fait 128 octets au lieu de 1024) et en ayant suffisement d'angles au final pour ses besoins, donc c'est un bon compromis a priori.
descendre a 16 pour compresser en nibble ca me parait un peu too much, ca fait vraiment pas beauocup d'angle different d'autant que ca ajoute des cycles CPU pour la décompression et la priorité c'est quand meme les ressources CPU.

par vincent2105 Jeu 19 Oct 2017 - 17:23

J'avais même pas compris qu'il y avait un pb de symétrie. MDR

(Avec ma routine, oui je l'avais constaté)
Et de toute façon, je pense que vu que les vitesses sont en word et pas en byte, niveau index ca limite à 128 angles.

par Invité Jeu 19 Oct 2017 - 18:12

upsilandre a écrit:Je pense surtout que comme dit Typhon la précision est quand meme pas top et pas symetrique, c'est plus ou moins précis selon la direction. En reduisant a 32 angles on lisse un peu tout ca tout en reduisant les tables finales (qui sont quand meme 4 donc ca fait 128 octets au lieu de 1024) et en ayant suffisement d'angles au final pour ses besoins, donc c'est un bon compromis a priori.
descendre a 16 pour compresser en nibble ca me parait un peu too much, ca fait vraiment pas beauocup d'angle different d'autant que ca ajoute des cycles CPU pour la décompression et la priorité c'est quand meme les ressources CPU.

Tu as qd même une marge de manoeuvre avec la hauteur du sprite qui permet de compenser, on est pas sur la précision du pixel, mais d'une box .
Sinon je pense aussi que 32 est un bon compromis, mais si avec 16,ça le fait tout aussi bien, c'est tjrs ça de pris je pense, cependant ça va rajouter du CPU sur le second nibble .

par brokestudio Jeu 19 Oct 2017 - 18:28

vincent2105 a écrit:@brokestudio, une question : tu as choisi de n'avoir que 32 angles, mais qu'est ce qui t'empêchais d'en avoir 64, 128 ou 256 ? Je me doute qu'il y a une raison, mais je n'arrive pas à voir où ça coince justement

edit : y'a peut être un lien avec ce qu'a expliqué upsilandre ; mais c'est encore bien flou :/
Et puis la table atan est bien calibré, elle va de $00 a $1f pour un octant (donc sort des valeurs de $00 a $ff au final une fois le mask appliqué) donc ca exploite au mieux l'octet.

Au final j'ai modifié ma table et je travaille sur 64 angles. Ca ne change rien aux performances vu que l'angle renvoyé va de $00 à $FF, c'est même un shift en moins. Et oui comme tu l'as dit, vu que je suis en word je ne peux monter qu'à 128 avec ces tables. Pour monter à 256 il faut que je découpe les tables en deux avec les octets de poids fort dans une et les octets de poids faible dans l'autre. Pourquoi pas ...
C'est sûr que ça fait des grosses tables, mais au pris de la mémoire flash aujourd'hui ... Very Happy

par Invité Jeu 19 Oct 2017 - 18:30

C'est sûr que ça fait des grosses tables, mais au pris de la mémoire flash aujourd'hui ...

Ca dépend, tu entends quoi par grosse table ??,car même si la ROM ne coûte rien, le banking ,lui, coûte du CPU !!

par brokestudio Jeu 19 Oct 2017 - 18:33

64 valeurs * 2 vu qu'on est sur du word * 2 pour X et Y * 2 pour PAL et NTSC = 512 bytes si je ne dis pas d'ânerie.

C'est pas la fin du monde mais ça commence à faire. Disons qu'entre ça et les deux tables de la fonction atan2, ça me force à faire un bankswitch dont je me serais passé mais finalement ça passe plutôt bien niveau perf, et j'ai gagné en intérêt et en challenge niveau gameplay. Donc jusqu'ici c'est tout benef :)

par Invité Jeu 19 Oct 2017 - 18:35

Ok, effectivement c'est peu pour une table,pour moi 4/5 KO maxi ça va encore (tout dépend pk bien sur) .

par upsilandre Jeu 19 Oct 2017 - 18:55

cela dit tes tables sont pas obligé d'etre word pour stocker une vitesse. Pour la vitesse un octet suffirait (t'as pas des vitesse de 200 pixels par frame, vu tes tables c'est moins de 4 pixels par frame ce qui est deja beaucoup, et t'as pas besoin d'une precision au 1/256eme de pixel, au 1/32eme ca doit suffire). mais par contre ca obligerait a ajouter une phase de conversion pour transformer ta vitesse en word 16bit. Je sais pas si c'est tres intéressant (le seul interet serait peut etre d'eviter le bank switching, bof).

par brokestudio Jeu 19 Oct 2017 - 19:04

Non ça résoudrait même pas le problème de bank switching, et là vu que c'est dans une autre bank c'est plus gênant. Et effectivement ça évite une conversion donc je gagne un peu en vitesse.

par Invité Jeu 19 Oct 2017 - 19:18

mais par contre ca obligerait a ajouter une phase de conversion pour transformer ta vitesse en word 16bit

Pk transformer la vitesse en word ??

par upsilandre Jeu 19 Oct 2017 - 19:22

Parce que les coordonnées sont en word 8.8

par Invité Jeu 19 Oct 2017 - 19:24

Et quel est l'intérêt d'ajouter le vitesse au 2 ??, tu la rajoutes seulement à la partie subpixel normalement non ??
ou alors elle est aussi en 8.8 ??

par upsilandre Jeu 19 Oct 2017 - 19:28

ba les vitesses ne font pas forcement moins d'un pixel par frame, ici ca va jusqu'a 3-4 pixels par frame par exemple. Et puis y a aussi les valeurs negatives des vitesses qui donne le sens.donc ce que t'as besoin c'est d'ajouter un word 8.8 signé a tes coordonnées

par Invité Jeu 19 Oct 2017 - 20:01

upsilandre a écrit:ba les vitesses ne font pas forcement moins d'un pixel par frame, ici ca va jusqu'a 3-4 pixels par frame par exemple. Et puis y a aussi les valeurs negatives des vitesses qui donne le sens.donc ce que t'as besoin c'est d'ajouter un word 8.8 signé a tes coordonnées

Ah effectivement . Wink

par vincent2105 Jeu 19 Oct 2017 - 20:20

J'avais compris que la vitesse était un word 8.8, mais signé, ça non.
Je pensais bêtement qu'on obtenait une vitesse et ensuite, en fonction de la position du tireur par rapport à la cible, on choisissait d'ajouter ou soustraire.
Les nombres signés (complément à 2 ??), j'avais survolé au début, mais je m'en suis passé jusqu'a maintenant, alors pour le 8.8 signé, je suis complétement largué pale

par brokestudio Jeu 19 Oct 2017 - 20:39

Les deux sont possible. La première demo de twin dragons fonctionne comme ça, avec des vitesses uniquement positives, et j'avais un flag qui me donnait la direction et selon le cas je faisais une addition ou une soustraction.

par vincent2105 Jeu 19 Oct 2017 - 21:31

Ok, mais si je comprends, tu serais obligé de retravailler tes tables pour travailler avec des nombres signés non ?
ou alors c'est déjà le cas ? je vois que dans tes tables on a uniquement des valeurs genre $0xxx ou $Fxxx

par brokestudio Jeu 19 Oct 2017 - 21:56

C'est déjà le cas. Tu as en effet les valeurs positives en $0xxx et les négatives en $Fxxx.

par Invité Ven 20 Oct 2017 - 9:12

Et au niveau de ton angle, les tirs peuvent aller jusqu'à 360°, ou tu limites entre 0 et 90 ??
Parce que tu peux couvrir un large spectre d'angle tout en réduisant les tables avec un pas de 2(ou plus) par exemple .

par brokestudio Ven 20 Oct 2017 - 9:16

Je suis pas sur d'avoir compris ta question. Les tirs peuvent aller jusqu'à 360°.

par Invité Ven 20 Oct 2017 - 9:17

Oui j'ai corrigé, donc pk ne pas mettre les angles dans une table mais avec des pas de 2 ou plus, 0,2,4,5 ou 0,3,6,9 ??
Donc en fonction de ton X/Y l'angle serrait de +3° ou -3° max par rapport à l'angle réel, je pense que dans le jeu ça générait pas la perte de précision .
je suppose qu'actuellement ils sont avec des pas de 1 non ??

par vincent2105 Ven 20 Oct 2017 - 9:23

Je dirais que le tir peut aller dans toutes les directions donc 360°. Si ce n'est pas le cas, alors, j'ai vraiment tout compris de travers.

Perso, il me manque trop de bases pour comprendre l'ensemble de ta solution (notamment la routine http://codebase64.org/doku.php?id=base:8bit_atan2_8-bit_angle, ) .
Je vais creuser de mon côté encore un peu pour me divertir. Mr ToutLeMonde et la programmation NES... - Page 6 418468

Mr ToutLeMonde et la programmation NES... - Page 6 418468

par brokestudio Ven 20 Oct 2017 - 9:24

Désolé je ne te suis pas Sad

La fonction atan2 me renvoie un angle sur 8bit donc 360/256=1,41. J'ai un donc déjà un pas de 1,41°.

Je converti ce résultat pour l'utiliser dans ma table où je me limite à 64 angles différents. Soit un pas de 360/64=5,625°.

Je ne suis pas sûr que ça t'aide, mais je suis peut être pas bien réveillé aussi :)

par Invité Ven 20 Oct 2017 - 9:25

t'inquiètes, tu as répondu à ma question, dsl de pas avoir été clair Wink

En voulant simplifier mon résonnement et ma question, je me rends compte que j'étais pas clair du tout Embarassed

par brokestudio Ven 20 Oct 2017 - 9:26

Très honnêtement Vincent je n'ai pas cherché à comprendre en détails la fonction atan2 pour le moment. J'ai compris qu'à partir des deltas x et y elle me renvoyait un angle sur 8bits et c'est tout ce qui m'intéressait pour le moment. Mais j'y reviendrai plus tard pour la décortiquer.

par vincent2105 Ven 20 Oct 2017 - 9:33

Ah ca m'intéressera alors Wink

Sinon, tu utilises quel assembleur ? j'utilise NESASM3 , apparemment toi non.
Et j'en profite, dans la routine atan2 on a des bcs *+4. Ou atterrissons nous dans l'exemple suivant ? je dirais au STA.

Code:: BCS *+4 LDA LDY LDX STA STY

par brokestudio Ven 20 Oct 2017 - 9:41

J'utilise ca65 mais je n'en ai pas vraiment testé d'autres avant et celui là me semble bien complet et flexible.

Dans ton exemple tu atterrira au ldx.
La notation *+x est "l'équivalent" des labels anonymes quand l'assembleur ne le supporte pas.
Ca m'a pas l'air ben pratique d'ailleurs !

Code:: bcs *+4 lda ldy ldx sta sty

est équivalent à :

Code:: bcs :+ lda ldy : ldx sta sty

par upsilandre Ven 20 Oct 2017 - 16:44

moi tant qu'on a les + et les - pour les branchement je suis content. C'est dure de s'en passer ensuite. j'utilise asm6

Code:: -- ldx #0 - lda $2002 bne - cpx #69 beq + cpx #96 beq ++ jmp -- + ldx #0 ++ lda #0

par brokestudio Ven 20 Oct 2017 - 16:49

L'équivalent en ca65 serait ça :

Code:: : ldx #0 : lda $2002 bne :- : lda $2002 bne :- cpx #69 beq :+ cpx #96 beq :++ jmp :-- : ldx #0 : lda #0

Pas si éloigné, mais c'est vrai que la notation avec le même nombre de caractère entre le label et l'opcode de "branchement" est un peu plus lisible.

par Invité Ven 20 Oct 2017 - 18:41

franchement je trouve cette notation de label purement dégueulasse, ça rend le code vraiment illisible et difficile à suivre .