Re: Mr ToutLeMonde et la programmation NES...

[vincent2105]

Bah ça fait plaisir d'entendre ça. Par moment c'est un peu la traversée du desert le coding. 

Sinon, j'ai calé ma seconde interruption pour de nouveau bankswitcher la chr rom afin de recupérer le tileset du cockpit et afficher la partie basse. 
Mais faudra que j'ajuste, comme on l'avait vu y'a un moment

[vincent2105]

Ce soir, j'ai commencé la routine de scrolling. 
Première étape : organiser (avec un script python) les datas de ma bande horizontale de 128*8 tiles  afin de pouvoir écrire colonne par colonne. 
Pour l'instant, je ne fais que scroller en boucle 32 colonnes.
Au moment de tester sur NES, blackout. J'ai mis 3/4 d'heure avant de m'apercevoir que ma carte sd avait un problème, ça m'a fait une occasion de relire mon code 
Bref ça passe avec une autre carte sd. 
Par contre, les mots "status, weapons, area" passent vraiment pas bien à l'écran.

[brokestudio]

La capture est petite donc difficile de dire, mais si ta police ne fait qu'1 pixel de large sur les barres horizontales des lettres, ça ne se retranscrit vraiment pas bien à l'écran (surtout CRT). Sauf avec certaines couleurs bien contrastées. Dans ton cas, peut être qu'en changeant juste de couleur ça peut suffire. A tester :)

[vincent2105]

 mais si ta police ne fait qu'1 pixel de large sur les barres horizontales des lettres, ça ne se retranscrit vraiment pas bien à l'écran (surtout CRT). 

C'est tout à fait ça, les caractères sont déformés, ça ressemble plus à grand chose. Et d'un autre coté, je ne veux pas une police "impeccable", j'aimerais qu'on ait l'impression d'être dans le cockpit.
Je ferai quelques tests avec les polices de bases de graphicsgale, sinon je chercherai autre chose.

[vincent2105]

Bon honte à moi, j'ai encore changé d'exercice :p 

Bref, je suis en train de programmer un moteur de metasprite.
J'en suis au stade où je veux donner la possibilité à chacun des metasprites d'avoir sa propre routine de déplacement. Avec une trentaine d'ennemis en prévision, et vu qu'on n'a pas de JMP indexé, je voulais voir si on avait pas une alternative. Et je suis tombé sur le RTS trick : https://wiki.nesdev.com/w/index.php/RTS_Trick

Après une première lecture, il me semble que ça fait l'affaire, je vais approfondir 

[upsilandre]

Si c'est juste un jmp indexé que tu veux doit y avoir moyen de faire plus simple avec le jmp indirect (dirigé vers une table de jmp). A priori l'interet du RTS_trick c'est si vraiment tu veux indexer des subroutines (donc si tu veux pouvoir utilisez tes routines a partir de different endroit de ton code)

[vincent2105]

Je viens de tester le JMP indirect, c'est bon, maintenant faut voir si j'arrive à greffer ça au reste de mon code. :)

[vincent2105]

Ca marche !  
J'avais déjà ébauché un moteur de metasprite y'a quelques mois, mais c'était rapidement devenu bancal.
Cette fois, j'ai plusieurs listes d'ennemis,  je peux en choisir une,  et chaque ennemi a ses propres anims sur 2 frames et peut appeler sa propre routine de déplacement. Je suis satisfait. 
Maintenant, faut que je rajoute les collisions entre sprites, détection de background, et les armes.

Pour en revenir au JMP indirect, c'est quand même fou que je ne m'en sois pas servi plus tôt :p

[vincent2105]

Bon, je me retrouve avec mes premiers glitchs sur NES (ca passe sur ému) :/
Je suis pas emballé à l'idée de tout reprendre, mais bon ! 
Pour l'instant, les ennemis ne détectent pas le background. 

[upsilandre]

a voila je comprend mieux tes questions :)
Essaye sur Mesen pour voir si ca glitch. Mesen est plus précis.

[vincent2105]

Oui, ça glitch sur la moitié haute de link (sur NES, les sprites ennemis ont aussi ce problème). 
C'est un bon début. J'aurais du y penser plus tôt :) 

ROM : https://drive.google.com/open?id=0B0HKOrG7iEpfS3dLNWZ4RnZHU3c

[brokestudio]

Est-ce que je peux me permettre de squatter ce topic pour demander un ptit coup de main ?

Je cherche à gérer des projectiles qui ciblent le joueurs. Pas à tête chercheuse, mais au moment où ils sont lancés, ils visent le joueur.

De ce que j'ai compris, il faut que je calcul un angle à partir des deltas X/Y entre le point de départ du projectile et le joueur, que j'utilise ensuite pour calculer les vitesses X et Y.

Dans mes recherchent je suis tombé sur cette fonction "atan2" http://codebase64.org/doku.php?id=base:8bit_atan2_8-bit_angle qui permet de récupérer l'angle à partir des positions X et Y de chaque object.

Outre le fait que cette fonction me dépasse un peu (la trigonométrie, tout ça, c'est pas vraiment mon rayon), mon problème est que je ne sais pas comment utiliser cet angle ensuite ?

Si quelqu'un à ne serait-ce qu'une piste, je suis preneur, d'avance merci :)

[upsilandre]

Effectivement quand on veut convertir des coordonnées x,y en angle et vice et versa on passe par la tangente (ou l'inverse de la tangent, atan ou arctan ou tan-1) dont la fonction est justement de definir le rapport enter ces 2 valeurs et sur une vieille machine on utilise simplement une table de conversion. Le plus difficile c'est plutot la division je pense pour definir le rapport entre x et y et ca doit etre l'essentiel du bout de code que t'as linké j'imagine.

Mais de toute facon dans ton ca t'as pas besoin d'angle, t'as juste besoin de calculer le coefficient directeur de la droite entre l'emeteur du projectile et la cible donc c'est juste une division entre delta x et delta y ce qui reste quand meme le plus chiant a faire. Je pense qu'il doit y avoir des approximations rapide possible. Les division sur cpu 8bit c'est un grand sujet avec divers approche.

[Tryphon]

Ils ont quelle trajectoire tes projectiles ? Si c'est rectiligne, Upsilandre a raison, t'as pas besoin d'arc tangente, juste un vecteur directeur que tu divises par ce qu'il faut pour qu'il ait la bonne longueur.

Si c'est des paraboles, pareil, tu peux te passer de l'arc tangente.

Comment sont définies tes trajectoires ?

[brokestudio]

Ce sont des trajectoires rectilignes.

De ce que j'ai compris sur d'autres forums, l'angle obtenu avec atan2 est à utiliser avec deux tables (X et Y) contenant la vitesse pour chaque angle. Mais même là je bloque.

Si je calcule le coefficient directeur de la droite j'en fais quoi ensuite ? Je le multiplie par ma vitesse ? Pour la division, ça me parait un peu lourd à effectuer sur de la NES.

[upsilandre]

Ce que t'as besoin pour deplacer ton projectile c'est de savoir de combien t'incremente sa coordonnée Y chaque fois que t'incremente X (ou l'inverse) et c'est ca le coeficient directeur, la valeur d'incrementation.
Donc ce que tu veux c'est juste savoir combien de fois y a delta Y dans delta X (ou l'inverse) pour avoir ta valeur d'incrementation. Du coup c'est juste une simple division mais un peu inevitable meme si tu utilise des approches approximatives ou des trick a base de table.

Ensuite faudra traiter tout les cas different (deltaY > ou < a deltaX? delta X negatif ou positif? delta Y negatif ou positif?) et faudra sans doute travailler avec des valeurs de coordonné en subpixel (gentre  16bit a virgule fixe, 8bit + 8bit, mais j'imagine que c'est deja plus ou moins le cas?) parce que avec des coordonnée 8bit ca sera trop peu je pense.

[vincent2105]

Est-ce que je peux me permettre de squatter ce topic pour demander un ptit coup de main ?

Je cherche à gérer des projectiles qui ciblent le joueurs. Pas à tête chercheuse, mais au moment où ils sont lancés, ils visent le joueur.

...

Tu as bien fait de poser la question, j'allais bientôt y venir 
Je vais essayer de trouver une solution à la "mr toutlemonde" 

[upsilandre]

Je pense que ca se complique a partir du moment ou ce qu'on veut c'est une vitesse lineaire quelques soit l'angle (et c'est ce qu'on veut dans ce cas) du coup ouai faudra peut etre du atan en plus, a creuser (pas le temps dans l’immédiat) mais c'est intéressant

[vincent2105]

Juste pour revenir sur mes glitchs, en passant de 7 à 5 ennemis, plus de problème (j'ai pas testé avec 6 ennemis sur NES, car Mesen affichait encore des glitchs). D'un côté ça me rassure, la partie "logique" de mes routines n'est pas en cause, je pense qu'en bufferisant, ca devrait aller mieux. Je suis assez confiant.

Pour le moment, je vais étudier la question "projectile".

[upsilandre]

merde c'est vrai y a cette histoire de projectile.
Pour l'instant j'ai pas trouvé mieux que de devoir utiliser une division + une multiplication + 2 tables trigo (atan et cos, mais ca c'est pas trop un probleme vu la place qu'il te reste sur ta rom) mais c'est un calcule a faire une seule fois au moment de l’émission, y a plus besoin ensuite pendant le deplacement du projectile (donc peut importe le nombre de projectile a l'ecran ca augmentera pas la charge de calcule).
Je sais pas si c'est viable.
c'est vrai que je m'etais jamais posé la question mais y a rarement des trajectoires de projectile non prédéfinie dans les jeu 8bit.

[Tryphon]

Y'a pas besoin d'atan.

Tu prends la position de ton ennemi (x0, y0)
la position du joueur (x1, y1)

tu calcules le vecteur vitesse (dx, dy) = (v*(x1 - x0)/d, v*(y1 - y0)/d)
où :
v est la vitesse du projectile en pixels par frame (typiquement 1 ou 2)
d est la distance entre le joueur et l'ennemi (d = racine carrée ( (x1 - x0)^2 + (y1 - y0)^2) )

Et à chaque mise à jour de l'ennemi, tu fais x0 = x0 + dx, y0 = y0 + dy

Les calculs chiants (longs) sont la racine carrée et la division, où ça vaut le coup de faire une table.

Mais pas d'arc tangente !

[upsilandre]

t'es en train de dire que de faire 2 division, 2 multiplication, 2 carré et une racine carré c'est mieux que de faire juste une multiplication et une division?
Les cos et les atan c'est pas grave c'est juste des tables. On est sur cpu 8bit, y a juste des addition et des soustraction, faut eviter les multiplications et les divisions. Ca me parait trop lourd ce que tu propose.

[Tryphon]

Les racines carrées c'est juste des tables, la division aussi éventuellement.

J'ajoute que je n'ai qu'une division (le coef v/d est commun aux deux coords). v étant constante (ou au pire une puissance de 2), tu peux tout à fait imaginer faire une table à deux entrées x, y, (et même une demi-table, vu la symétrie en x, y)qui renvoie le coef v/d.

De plus, tu ne les fais qu'une fois. Je pense que, si nous utilisons des tables tous les deux, c'est rigoureusement équivalent.

De plus, toi tu devras gérer différents cas suivant le quadrant dans lequel tu situes ton tir, moi pas. Enfin, je pense que tu calcules atan(y/x) non ? Donc t'as aussi une division. Puis ton cosinus, tu le multiplies par la vitesse ? T'as aussi une multiplication :)

[upsilandre]

Si on regarde le bout de code que broke a linké y aurait pas forcement grand chose a ajouter j'ai l'impression car ce bout de code calcule deja le coef directeur (en faisant apparement une approximation de la division avec une table log2, j'ai deja vu ca ca doit marcher) et le atan

on ajoutant ca on doit obtenir le delta_x du missile (la valeur a incrémenter a chaque frame)

lda x1
sbc x2
bcs *+4
eor #$ff
tax
rol octant

lda y1
sbc y2
bcs *+4
eor #$ff
tay
rol octant

lda log2_tab,x
sbc log2_tab,y
bcc *+4
eor #$ff
tax

lda octant
rol
and #%111
tay

lda atan_tab,x
eor octant_adjust,y

tay
lda cos_table,y

resterait plus qu'a multiplier le registre a par le registre y (qui contient le coeficient directeur) pour avoir delta_y.

[Tryphon]

Désolé, je parle pas le 6502 (et mon 6809 est trop lointain). Mais si tu calcules cos(atan(y/x)), alors en plus t'auras des erreurs d'arrondis.

Non vraiment, à tous points de vue (élégance, fiabilité, écriture, performances), je pense que c'est mieux de passer par un vecteur directeur normé.

[upsilandre]

Les racines carrées c'est juste des tables, la division aussi éventuellement.

J'ajoute que je n'ai qu'une division (le coef v/d est commun aux deux coords). v étant constante (ou au pire une puissance de 2), tu peux tout à fait imaginer faire une table à deux entrées x, y, (et même une demi-table, vu la symétrie en x, y)qui renvoie le coef v/d.

De plus, tu ne les fais qu'une fois. Je pense que, si nous utilisons des tables tous les deux, c'est rigoureusement équivalent.

De plus, toi tu devras gérer différents cas suivant le quadrant dans lequel tu situes ton tir, moi pas. Enfin, je pense que tu calcules atan(y/x) non ? Donc t'as aussi une division. Puis ton cosinus, tu le multiplies par la vitesse ? T'as aussi une multiplication :)

oui c'est bien ce que j'ai dis, juste une division et une multiplication devrait suffire au total (et tu peux adapter la table cosinus si tu veux une vitesse autre que 1 pixel par frame).
et dans le bout de code le gars gère deja l'octant en appliquant une sorte de masque. En tout cas si Antoine veut partir de ce bout de code deja en 6502 y a probablement moyen

[upsilandre]

En gros tu passe par Pythagore au lieu de la trigo donc tu remplaces les tables trigo par des tables de racine carré. Ca devrait effectivement revenir au meme je pense.

[Tryphon]

Tout à fait. Les erreurs d'approximation en moins.

Et je maintiens que calculer cos(arctan alpha) c'est une hérésie
(ça doit faire un truc en 1/racine(alpha^2 + 1))

[upsilandre]

Je pense que ta methode par Pythagore devrait aussi donner un truc plus clean (et plus precis effectivement) au niveau du code car ca peut se reduire a 2 division plutot qu'une division et une multiplication (+ le masque des octant), si t'as mis en place une solution pour la division autant en faire 2.

[upsilandre]

quoique j'ai oublié la racine carré dans ta methode. Ca peut etre chiant.

[Tryphon]

C'est pour ça que je ferais une table des 1/sqrt(x^2 + y^2) avant. Et sauf erreur, ça revient exactement au même que de faire une table des arctan(cos t)