Page 7 sur 8

Re: (Forth) BOIDS et la gestion des objets

Publié : 09 mars 2017 09:32
par Daniel
Dans dcmoto les options Exec, Read, Write définissent le type de point d'arrêt, en complément de l'adresse :
- Exec = arrêt lorsque le contenu du registre PC est égal à l'adresse
- Read = arrêt lorsque le programme lit le contenu de l'adresse
- Write = arrêt lorsque le programme écrit à cette adresse

Zéro, un ou plusieurs types de points d'arrêt peuvent être cochés simultanément, l'arrêt se produit au premier rencontré.
On voit alors l'adresse et l'instruction au point d'arrêt. Il n'y a aucune trace du déroulement du programme avant l'arrêt.

Re: (Forth) BOIDS et la gestion des objets

Publié : 09 mars 2017 10:59
par Dominique
Ok merci Daniel, c'est clair.

J'utilisais toujours avec exec. Maintenant Read et Write peuvent effectivement s'avérer très très utiles.

Re: (Forth) BOIDS et la gestion des objets

Publié : 09 mars 2017 11:28
par __sam__
Dans le fond, un exec est une sorte de read restreint au "fetch" de l'op-code.

Re: (Forth) BOIDS et la gestion des objets

Publié : 09 mars 2017 23:07
par Dominique
Read et Write montrent que $A7C0 n'est affecté que par CLS.
Comme CLS est fait deux fois : Au lancement du programme et après l'écran de saisie des paramètres, ça limite fortement l'emploi du ORA #$01.

Parfait, toujours ça de gagné.

Re: (Forth) BOIDS et la gestion des objets

Publié : 10 mars 2017 01:32
par __sam__
Tu peux très facilement émuler le CLS en ASM, et ce sera encore plus rapide que la routine du sytème!

Code : Tout sélectionner

  PSHS D,X,Y,U <== sauvegarde des reg utilisés
  LDD #200 <== A=0, B=200 en une seule opération
  LDX #0 
  LEAY ,X
  LDU #8000 <== fin mémoire écran
LBL:
  PSHU A,X,Y <== 5 octets à la fois sont mis à 0
  PSHU A,X,Y
  PSHU A,X,Y
  PSHU A,X,Y
  PSHU A,X,Y
  PSHU A,X,Y
  PSHU A,X,Y
  PSHU A,X,Y <== total 8x5 = 40 octets à 0 
  DECB
  BNE LBL
  PULS D,X,Y,U,PC <== récup regs sauvegardés + retour

Re: (Forth) BOIDS et la gestion des objets

Publié : 10 mars 2017 08:03
par Dominique
Parfait _sam_ ; Je garde ça sous le coude pour le mettre dans le définitif quand on aura fait la bascule Forth ASM. CLS n'affecte pas la vitesse des Boids et je suis à la limite de la capacité de l'éditeur Forth. Le CLS du Forth est naturellement

Code : Tout sélectionner

                     c_cls
 5ADC C60C                    LDB    #$0C               
 5ADE 3F                      SWI    
 5ADF 02                      FCB $02               
 5AE0 0EB6                    JMP    NEXT 

Re: (Forth) BOIDS et la gestion des objets

Publié : 10 mars 2017 15:03
par __sam__
Il y a aussi une séquence d'appel à PUTC (SWI $02), à ne faire qu'une fois et qui demande à l'affichage du texte de rester sur la mémoire "FORME". Sur TO, il faut envoyer $1B puis $68. J'imagine que sur MO c'est pareil.

Re: (Forth) BOIDS et la gestion des objets

Publié : 10 mars 2017 17:22
par Daniel
Non, sur MO5 les séquences d'échappement sont différentes. La séquence $1B $68 est l'équivalent de SCREEN ,,8.

Re: (Forth) BOIDS et la gestion des objets

Publié : 10 mars 2017 18:01
par Dominique
Alors, voyons si j'ai bien compris :

Dans mon programme
1) Tout ce qui est affichage et effacement des sprites Boids se fait directement; pour l'effacement par des AND des bits
de D (un masque genre D=11000011) directement dans l'adresse écran - Pour l'affichage du Sprite c'est un OR des bits
de D (qui contient l'octet du sprite) directement dans l'adresse écran ; Aucun risque donc car aucun appel à la ROM.
2) Mais après la touche "Q" je reviens au Forth pour afficher du texte et là oui je fais appel à la ROM par l'intermédiaire
du mot Forth : TYPE.
TYPE demande dans la pile U l'adresse de la chaine de caractères à afficher et le nombre de caractères.
(AdresseChaine, n ....) TYPE affiche sur l'écran n caractères situés à l'adresse AdresseChaine.
Type fait bien appel à SWI $02

Code : Tout sélectionner

                      cf_type
 4B72 4B74                    FDB c_type
                      c_type
 4B74 3716                    PULU   A,B,X              
 4B76 E35E                    ADDD   -$02,U             
 4B78 3606                    PSHU   B,A
                      type1                
 4B7A ACC4                    CMPX   ,U                 
 4B7C 1024FA2C                LBCC   PULL              
 4B80 E680                    LDB    ,X+                
 4B82 3F                      SWI    
 4B83 02                      FCB $02               
 4B84 20F4                    BRA    type1  
Donc TYPE serait susceptible de faire appel à l'écran Forme..

3) De toute façon après cet écran d'affichage et de saisie des paramètres je fais un CLS.
Auquel cas je vais forcer un ORA #$01 dans $A7C0 après CLS.

edit : Message envoyé avant d'avoir lu le message de Daniel au dessus

Re: (Forth) BOIDS et la gestion des objets

Publié : 10 mars 2017 22:41
par __sam__
Daniel a écrit :Non, sur MO5 les séquences d'échappement sont différentes. La séquence $1B $68 est l'équivalent de SCREEN ,,8.
Ok ca à l'air d'être la séquence $1B $75 qui convient (p136 du manuel de l'assembleur MO5). Je ne vois pas pourquoi ils n'ont pas utilisés la même séquence d'échappement, mais ce sont les mystères d'avoir 2 équipes concurrentes en interne.

Re: (Forth) BOIDS et la gestion des objets

Publié : 11 mars 2017 00:27
par Dominique
Voici le premier essai avec obstacle - Je vous le montre "en direct" tel que je le vois lors de mon premier test.
Des choses à améliorer : Ils sont un peu brusques sur l'obstacle, j'en vois quelques uns étrangement immobiles avant de repartir.


ça me donne une idée : Pourquoi ne pas faire un obstacle mobile... un chien de berger :roll:


Re: (Forth) BOIDS et la gestion des objets

Publié : 11 mars 2017 11:40
par Mokona
On peut en conclure qu'un mouton est plus fluide qu'un MO5. Non ? :)

Re: (Forth) BOIDS et la gestion des objets

Publié : 13 mars 2017 17:17
par Dominique
Je planche en ce moment sur les paramètres vitesses et ce n'est pas une mince affaire.
Comme le dit Mokona, ils sont très brusques et je me creuse la tête pour résoudre les problèmes de fluidité.

Comme rappelé ici
viewtopic.php?f=25&t=7774#p124760

Le déplacement du Boid est la somme de trois déplacements - cohésion, séparation et alignement - sans parler de celui des obstacles
que je viens de rajouter.

Pour faire simple disons que je calcule chaque vitesse de façon proportionnelle à la distance.
Et c'est là que le bât blesse.
Prenons par exemple la "séparation".

Deux Boids se voient à 50 unités de distance. Selon la loi de séparation, chacun aura une vitesse en sens inverse = 50/N (j'ai choisi N=20, mais peu importe);

Supposons qu'en raison des autres déplacements 2 Boids ne s’aperçoivent de leur proximité qu'à 25 unités de distance. Leur vitesse en sens inverse sera de 25/N, soit deux fois moins.

Ce n'est pas réaliste. On s'attend à ce que plus ils risquent de se rencontrer, plus ils doivent chercher à s'éloigner.
Je dois changer ma méthode de calcul des vitesses pour quelles soient inversement proportionnelles aux distances.
Tout en conservant la rapidité de calcul.

Voilà voilà...

Re: (Forth) BOIDS et la gestion des objets

Publié : 09 juil. 2020 00:12
par __sam__
Je déterre ce sujet parce que Fouloscopie vient de sortir une vidéo qui est en relation...

Re: (Forth) BOIDS et la gestion des objets

Publié : 09 oct. 2021 23:32
par __sam__
Pour revenir sur le sujet des BOIDS, YouTube vient de me proposer cette vidéo dans lequel l'auteur modifie l'algo pour faire apparaitre une notion d'espèce (les BOIDS s'alignent sur ceux de la même espèce etc), ainsi qu'une notion de champ de vision pour chaque BOID:

(sa chaine contient des trucs sympas comme une extension continue du jeu de la vie (si j'ai bien compris), autrement discrète, et obtient des trucs vraiment étonnants, proche du vyvant.