Forum Liberty Basic France
• Index
Reprise du message précédent
Cassiope, peut-tu me donner la portée horizontale de la sonde en pixels de carte
J'ai vu que c'était 500 et 1500m, mais vu les fonctions du bas où j'ai vu le mot "scale" je préfère demander.
Je pense pouvoir avancer la dessus, en feintant ( parce que la distance est fixe) ...Merci . ....0+.
................
Une idée pour le sonar:
Le rayon est de 100, ça fait un carré de 200 par 200.
Si on divise par 10, ça fait un tableau de 400 par 400, des cases se 10.
J'ai vu que les cases de la carte étaient de 8
Le tableau de la carte existe, donc si on transfère le contenu du tableau carte dans le tableau scope en fonction de l'avancement du SM . ( convers pol/cartesien) Ce qui peut se faire de façon optimisée à 5 ou 10° prés. Et pas forcément à chaque tour.
Il "suffit" alors, de faire une lecture tournante du tableau scope, et d'allumer les points en fonction de son contenu. indépendamment du balayage,mais synchrone avec lui.
Et on peut meme introduire une variable aléatoire, pour que ce ne soit pas toujours les memes pixels qui s'allument à chaque tour, à l'intérieur de la case 10x10
N'oublions pas que ce qu'on voit sur un scope, c'est trés loin d'etre une photo. Et que l'image n'est pas exactement la meme à chaque balayage ( propagation fluctuente)
Edité par Roland Le 23/12/2012 à 00h27
Cassiope, peut-tu me donner la portée horizontale de la sonde en pixels de carte
J'ai vu que c'était 500 et 1500m, mais vu les fonctions du bas où j'ai vu le mot "scale" je préfère demander.
Je pense pouvoir avancer la dessus, en feintant ( parce que la distance est fixe) ...Merci . ....0+.
................
Une idée pour le sonar:
Le rayon est de 100, ça fait un carré de 200 par 200.
Si on divise par 10, ça fait un tableau de 400 par 400, des cases se 10.
J'ai vu que les cases de la carte étaient de 8
Le tableau de la carte existe, donc si on transfère le contenu du tableau carte dans le tableau scope en fonction de l'avancement du SM . ( convers pol/cartesien) Ce qui peut se faire de façon optimisée à 5 ou 10° prés. Et pas forcément à chaque tour.
Il "suffit" alors, de faire une lecture tournante du tableau scope, et d'allumer les points en fonction de son contenu. indépendamment du balayage,mais synchrone avec lui.
Et on peut meme introduire une variable aléatoire, pour que ce ne soit pas toujours les memes pixels qui s'allument à chaque tour, à l'intérieur de la case 10x10
N'oublions pas que ce qu'on voit sur un scope, c'est trés loin d'etre une photo. Et que l'image n'est pas exactement la meme à chaque balayage ( propagation fluctuente)
Edité par Roland Le 23/12/2012 à 00h27
____________________
Roro
Roro
Je ne comprend pas tout de ce que tu expliques Roland mais TOUT est dans mon code.
Code VB :
Comme je l'ai dis plus haut, la carte des profondeurs a une définition de 1km (8 pixel = 1km), je ne pouvais pas faire plus petit...!
Faudra que je me débrouille avec ça
On peut tricher avec TOUT pour peu que l'ensemble soit cohérant, utilisable et plutôt réaliste pour tenter de piloter le soum.
La FUNCTION scale() n'est la QUE pour convertir la valeur en pixels de déplacement des manches de commande à l'écran, en valeurs utilisables dans les calculs.
Par exemple pour la commande de profondeur (celle du haut), le manche peut être déplacé de 83 pixels vers le haut ou le bas : la fonction scale() renverra une valeur de +/- 20° qui est l'angle réel des "ailerons" de profondeur du sous-marin.
Pour la commande de direction c'est toujours 83 pixels droite/gauche mais scale() renverra +/- 30°.
Pour le moteur j'ai choisi une valeur de +/-100 mais c'est arbitraire, on peut facilement changer ça suivant la valeur la plus facile à intégrer pour le calcul de la vitesse du soum...!
@+
Edité par cassiope01 Le 23/12/2012 à 11h54
Code VB :
'--------------------------------------------------------------------------------------- ' Features of rescue submarine DSRV: ' dim. 15m x 2.4m x 2.6m ' mass : 30.5 t/surface, 38.6 t/diving (max 5000 ft = 1524 m) (implosion: 2500 m) ' speed : 4.1 kts max 2.5 kts transit 1.5 kts search ' speed of ascent max 100ft/min (30.4m/min) ' 7CV , 1 hélice pivotante (vertical +/-20° max, horizontal +/-30° max) ' autonomie max : 30h ' sonar obstacles (max range 8000 yards = 7.3152km) <---- portée du sonar. ' depth sonde (range sonde bathymétrique) 0-5000 ft (1524m) '---------------------------------------------------------------------------------------
Comme je l'ai dis plus haut, la carte des profondeurs a une définition de 1km (8 pixel = 1km), je ne pouvais pas faire plus petit...!
Faudra que je me débrouille avec ça
On peut tricher avec TOUT pour peu que l'ensemble soit cohérant, utilisable et plutôt réaliste pour tenter de piloter le soum.
La FUNCTION scale() n'est la QUE pour convertir la valeur en pixels de déplacement des manches de commande à l'écran, en valeurs utilisables dans les calculs.
Par exemple pour la commande de profondeur (celle du haut), le manche peut être déplacé de 83 pixels vers le haut ou le bas : la fonction scale() renverra une valeur de +/- 20° qui est l'angle réel des "ailerons" de profondeur du sous-marin.
Pour la commande de direction c'est toujours 83 pixels droite/gauche mais scale() renverra +/- 30°.
Pour le moteur j'ai choisi une valeur de +/-100 mais c'est arbitraire, on peut facilement changer ça suivant la valeur la plus facile à intégrer pour le calcul de la vitesse du soum...!
@+
Edité par cassiope01 Le 23/12/2012 à 11h54
____________________
Devise Shadocks : "Mieux vaut mobiliser son intelligence pour des conneries, que mobiliser sa connerie pour des choses intelligentes"
Coluche disait : "C'est parce que la vitesse de la lumière est plus rapide que celle du son que certains peuvent paraîtrent brillants jusqu'à ce qu'ils ouvrent la bouche."
Devise Shadocks : "Mieux vaut mobiliser son intelligence pour des conneries, que mobiliser sa connerie pour des choses intelligentes"
Coluche disait : "C'est parce que la vitesse de la lumière est plus rapide que celle du son que certains peuvent paraîtrent brillants jusqu'à ce qu'ils ouvrent la bouche."
Web
Ok, bien reçu pour le rapport Km/pixels. Et là, y'a un problème:
Portée de la sonde=1550m (soit 8 pixels...) Or les cases de la map font 8 pixels => portée de la sonde=1 case map
.Ce n'est pas grave, ça se corrige avec des coeffs. C'est ce que j'ai fait pour afficher la sonde.
Cela implique que:
Soit l'échelle de la carte change, soit la portée de la sonde augmente.
L'idéal, pour moi, serait une portée de 1/8 , 1/10, ou 1/20ème de carte.
Les valeurs min/max des commandes n'ont pas grandes importances, car il faut obligatoirement leur appliquer des coeffs .
Ce qui compte, c'est la valeur finale. Par exemple: la vitesse de défilement de l'azimut en fonction de l'angle de barre et de la vitesse d'avancement.
Je l'ai fait, et j'ai du appliquer des coeffs pour que ça se rapproche de la réalité.
Coeffs, qui sont à ajuster plus finement...bien sûr...
Jette un oeil sur ça: Enfer de Trigo.zip
Je crois que je ne suis plus trés loin. ( fichier: "Tc " )
Je me suis inscrit sur un site où on peut poser des questions de maths.
Cette satanée conversion est la clé de voute de ton prog.
On va voir ce que ça donne.... ...à+.
En tous cas, c'est super, on va pouvoir "ronger" un moment.
Edité par Roland Le 23/12/2012 à 12h47
Portée de la sonde=1550m (soit 8 pixels...) Or les cases de la map font 8 pixels => portée de la sonde=1 case map
.Ce n'est pas grave, ça se corrige avec des coeffs. C'est ce que j'ai fait pour afficher la sonde.
Cela implique que:
Soit l'échelle de la carte change, soit la portée de la sonde augmente.
L'idéal, pour moi, serait une portée de 1/8 , 1/10, ou 1/20ème de carte.
Les valeurs min/max des commandes n'ont pas grandes importances, car il faut obligatoirement leur appliquer des coeffs .
Ce qui compte, c'est la valeur finale. Par exemple: la vitesse de défilement de l'azimut en fonction de l'angle de barre et de la vitesse d'avancement.
Je l'ai fait, et j'ai du appliquer des coeffs pour que ça se rapproche de la réalité.
Coeffs, qui sont à ajuster plus finement...bien sûr...
Jette un oeil sur ça: Enfer de Trigo.zip
Je crois que je ne suis plus trés loin. ( fichier: "Tc " )
Je me suis inscrit sur un site où on peut poser des questions de maths.
Cette satanée conversion est la clé de voute de ton prog.
On va voir ce que ça donne.... ...à+.
En tous cas, c'est super, on va pouvoir "ronger" un moment.
Edité par Roland Le 23/12/2012 à 12h47
____________________
Roro
Roro
Roland:
C'est pas du tout ça.
La carte a une définition de 1km. (8 pixels = 1km)
Le SONAR a une portée de 8 km. (8000 yards = 7.3152km) (mais on peut aussi tricher)
Donc le rayon du sonar doit scruter 8 cases de la MAP, devant le soum dans le sens de sa marche.
Et ce rayon est l'hypothénuse de l'angle que fait la "route" (azimut) actuelle du soum par rapport au nord, qui est toujours l'orientation de lecture de la MAP(x,y), comme posée sur la table de lecture des cartes.
Tout le défi consiste à déterminer les coordonnées x,y sur la MAP() de chacune de ces 8 ou 10 cases correspondantes à la trajectoire actuelle du soum puisqu'elles se trouvent devant lui dans le sens de sa marche...
@+
Edité par cassiope01 Le 23/12/2012 à 13h50
Ok, bien reçu pour le rapport Km/pixels. Et là, y'a un problème:
Portée de la sonde=1550m (soit 8 pixels...) Or les cases de la map font 8 pixels => portée de la sonde=1 case map
Portée de la sonde=1550m (soit 8 pixels...) Or les cases de la map font 8 pixels => portée de la sonde=1 case map
C'est pas du tout ça.
La carte a une définition de 1km. (8 pixels = 1km)
Le SONAR a une portée de 8 km. (8000 yards = 7.3152km) (mais on peut aussi tricher)
Donc le rayon du sonar doit scruter 8 cases de la MAP, devant le soum dans le sens de sa marche.
Et ce rayon est l'hypothénuse de l'angle que fait la "route" (azimut) actuelle du soum par rapport au nord, qui est toujours l'orientation de lecture de la MAP(x,y), comme posée sur la table de lecture des cartes.
Tout le défi consiste à déterminer les coordonnées x,y sur la MAP() de chacune de ces 8 ou 10 cases correspondantes à la trajectoire actuelle du soum puisqu'elles se trouvent devant lui dans le sens de sa marche...
@+
Edité par cassiope01 Le 23/12/2012 à 13h50
____________________
Devise Shadocks : "Mieux vaut mobiliser son intelligence pour des conneries, que mobiliser sa connerie pour des choses intelligentes"
Coluche disait : "C'est parce que la vitesse de la lumière est plus rapide que celle du son que certains peuvent paraîtrent brillants jusqu'à ce qu'ils ouvrent la bouche."
Devise Shadocks : "Mieux vaut mobiliser son intelligence pour des conneries, que mobiliser sa connerie pour des choses intelligentes"
Coluche disait : "C'est parce que la vitesse de la lumière est plus rapide que celle du son que certains peuvent paraîtrent brillants jusqu'à ce qu'ils ouvrent la bouche."
Web
Hey, je parle de la portée de la sonde: 1500m en H 500m en Vertic
Dans le bout que j'ai mis, j'ai donné à la sonde une portée de 50 cases-carte, soit: 400Km.
Scope sonde 220 pxl: pas de 5. 5x50=250 (moins les bouts)=200 pxl
Je te signale que j'ai vérifié la validité du truc en mettant un obstacle sur la carte, qui apparait clairement sur le scope sonde. ( ne le cherche pas, il n'est pas sur le bout puisque je l'ai mis sur MA carte.
Mais dis ! Tu as mis Rod sur le coup, sans meme prendre la précaution d'isoler ton problème de sprite.
Ce qui risque de se passer, c'est simple à deviner:
Il va nous griller. Que dis-je . Nous crâmer... Nous carboniser....
Ce bel os, Rod va se jeter dessus comme un morphale, et il n'en laissera pas une miette, nous n'aurons plus qu'à aller nous coucher.
Dans le bout que j'ai mis, j'ai donné à la sonde une portée de 50 cases-carte, soit: 400Km.
Scope sonde 220 pxl: pas de 5. 5x50=250 (moins les bouts)=200 pxl
Je te signale que j'ai vérifié la validité du truc en mettant un obstacle sur la carte, qui apparait clairement sur le scope sonde. ( ne le cherche pas, il n'est pas sur le bout puisque je l'ai mis sur MA carte.
Mais dis ! Tu as mis Rod sur le coup, sans meme prendre la précaution d'isoler ton problème de sprite.
Ce qui risque de se passer, c'est simple à deviner:
Il va nous griller. Que dis-je . Nous crâmer... Nous carboniser....
Ce bel os, Rod va se jeter dessus comme un morphale, et il n'en laissera pas une miette, nous n'aurons plus qu'à aller nous coucher.
____________________
Roro
Roro
Bonjour!
C'est un peu difficile pour moi d'être présent ici par ce que je n'ai pas de temps, mais j'aimerais bien comprendre sur quel type de conversion polaire/cartésien vous parlez (et éventuellement pourquoi vous en avez besoin). Dans tous les cas c'est assez simple...
Si vous êtes sur un plan à 2 dimensions (x et y) il n'y a qu'à effectuer 2 opérations pour convertir une coordonnée polaire en coordonnée cartésienne. Voir....
Si vous être dans un espace à 3 dimensions, faudrait savoir si vous êtes dans un référentiel sphérique ou cylindrique. Mais là encore , la conversion dans un référentiel cartésien (X,Y,Z) est très simple.
Dans tous les cas, faut faire attention car le logiciel traite les angles en radians et non en degrés (faut préalablement faire une conversion)..
C'est un peu difficile pour moi d'être présent ici par ce que je n'ai pas de temps, mais j'aimerais bien comprendre sur quel type de conversion polaire/cartésien vous parlez (et éventuellement pourquoi vous en avez besoin). Dans tous les cas c'est assez simple...
Si vous êtes sur un plan à 2 dimensions (x et y) il n'y a qu'à effectuer 2 opérations pour convertir une coordonnée polaire en coordonnée cartésienne. Voir....
Si vous être dans un espace à 3 dimensions, faudrait savoir si vous êtes dans un référentiel sphérique ou cylindrique. Mais là encore , la conversion dans un référentiel cartésien (X,Y,Z) est très simple.
Dans tous les cas, faut faire attention car le logiciel traite les angles en radians et non en degrés (faut préalablement faire une conversion)..
Salut chris, merci à toi.
Si tu lances ce code submarine_simulator.zip , et que tu cliques sur le bouton "MAP", tu comprendras vite le propos et ce qu'il reste à faire...
- visualiser (en 2D) ce que le sous-marin a devant lui (portée 8km), strictement à la profondeur où il évolu actuellement, dans le sens de sa marche, dans l'écran du SONAR, et tout ça en lisant la MAP() qui est un simple tableau à 2 dimensions (100x50) contenant les profondeurs, et dont chaque case représente 1km².
- visualiser aussi ce qu'il y a sous lui toujours dans le sens de sa marche (disons 500m AV/AR et 1500m de profondeur)
- trouver les bons facteurs d'échelle pour que ce soit exploitable (pseudo-réaliste) par le pilote.
- faire les bon calculs pour que les affichages représentent du mieux possible les actions du pilote sur les commandes dont il dispose pour piloter.
Effectivement la conversion polaire/cartésien n'est pas le plus difficile, mais d'intégrer tout ça efficacement et proprement dans le code, sachant que le SONAR tournant oblige à TOUT intégrer dans la boucle... ça c'est un sacré défi...
A mon humble avis, la quantité de calculs ralentira tellement cette boucle que la rotation du SONAR ne sera plus réaliste très longtemps
( en fait, trop dépendant de la puissance de l'ordi sur lequel le programme sera lançé ! )
Joyeuses fêtes de fin d'année
@+
Edité par cassiope01 Le 24/12/2012 à 11h11
Si tu lances ce code submarine_simulator.zip , et que tu cliques sur le bouton "MAP", tu comprendras vite le propos et ce qu'il reste à faire...
- visualiser (en 2D) ce que le sous-marin a devant lui (portée 8km), strictement à la profondeur où il évolu actuellement, dans le sens de sa marche, dans l'écran du SONAR, et tout ça en lisant la MAP() qui est un simple tableau à 2 dimensions (100x50) contenant les profondeurs, et dont chaque case représente 1km².
- visualiser aussi ce qu'il y a sous lui toujours dans le sens de sa marche (disons 500m AV/AR et 1500m de profondeur)
- trouver les bons facteurs d'échelle pour que ce soit exploitable (pseudo-réaliste) par le pilote.
- faire les bon calculs pour que les affichages représentent du mieux possible les actions du pilote sur les commandes dont il dispose pour piloter.
Effectivement la conversion polaire/cartésien n'est pas le plus difficile, mais d'intégrer tout ça efficacement et proprement dans le code, sachant que le SONAR tournant oblige à TOUT intégrer dans la boucle... ça c'est un sacré défi...
A mon humble avis, la quantité de calculs ralentira tellement cette boucle que la rotation du SONAR ne sera plus réaliste très longtemps
( en fait, trop dépendant de la puissance de l'ordi sur lequel le programme sera lançé ! )Joyeuses fêtes de fin d'année
@+
Edité par cassiope01 Le 24/12/2012 à 11h11
____________________
Devise Shadocks : "Mieux vaut mobiliser son intelligence pour des conneries, que mobiliser sa connerie pour des choses intelligentes"
Coluche disait : "C'est parce que la vitesse de la lumière est plus rapide que celle du son que certains peuvent paraîtrent brillants jusqu'à ce qu'ils ouvrent la bouche."
Devise Shadocks : "Mieux vaut mobiliser son intelligence pour des conneries, que mobiliser sa connerie pour des choses intelligentes"
Coluche disait : "C'est parce que la vitesse de la lumière est plus rapide que celle du son que certains peuvent paraîtrent brillants jusqu'à ce qu'ils ouvrent la bouche."
Web
Le problème est simple à décrire,
Imagine:
A gauche: Une fenetre représentant un poste de pilotage de bateau.
Deux commandes:
Le moteur, qui imprime au bateau une vitesse: +V ; -V ( en bananes flambées par secondes)
La barre, qui donne au gouvernail un angle par rapport à l'axe du bateau: +Téta ; -Téta
A Droite: Une autre fenetre, rectangulaire bleue (c'est la mer).Axes x,y (horizontal, vertical. Si on parle de la fenetre. Et Ouest/Est - Nord/ Sud. Si on parle de la mer )
A l'instant "T" zéro. le bateau est en xa,ya dans la fenetre de droite.
Connaissant: V et téta que seront xb et yb à l'instant "T"+ quelques secondes( ou quelques jours) ?
ou: xb,yb = xa,ya ((( f ))) de v,téta
Le facteur temps s'annulant dans les opérations, on doit pouvoir manger les bananes.
.......
Oups! légère erreur:
Pour que le temps s'annule ce n'est xb,yb . Mais delta x,delta y. qui sont fonction de V et téta.
Edité par Roland Le 24/12/2012 à 17h09
Imagine:
A gauche: Une fenetre représentant un poste de pilotage de bateau.
Deux commandes:
Le moteur, qui imprime au bateau une vitesse: +V ; -V ( en bananes flambées par secondes)
La barre, qui donne au gouvernail un angle par rapport à l'axe du bateau: +Téta ; -Téta
A Droite: Une autre fenetre, rectangulaire bleue (c'est la mer).Axes x,y (horizontal, vertical. Si on parle de la fenetre. Et Ouest/Est - Nord/ Sud. Si on parle de la mer )
A l'instant "T" zéro. le bateau est en xa,ya dans la fenetre de droite.
Connaissant: V et téta que seront xb et yb à l'instant "T"+ quelques secondes( ou quelques jours) ?
ou: xb,yb = xa,ya ((( f ))) de v,téta
Le facteur temps s'annulant dans les opérations, on doit pouvoir manger les bananes.
.......
Oups! légère erreur:
Pour que le temps s'annule ce n'est xb,yb . Mais delta x,delta y. qui sont fonction de V et téta.
Edité par Roland Le 24/12/2012 à 17h09
____________________
Roro
Roro
Cassiope, inutile de te casser le neurone sur le prog en C. Je l'ai regardé, il ne contient pas la formule magique.
Tout juste si il a mis un vague coeff de ralentissement de l'évolution verticale en fonction de l'angle de barre, qui d'ailleurs ne rime à rien.
Si tu veux bien me donner ton avis sur la clarté de l'énnoncé du problème . Dans mon dernier post.
Ca serait sympa....... à+.
Tout juste si il a mis un vague coeff de ralentissement de l'évolution verticale en fonction de l'angle de barre, qui d'ailleurs ne rime à rien.
Si tu veux bien me donner ton avis sur la clarté de l'énnoncé du problème . Dans mon dernier post.
Ca serait sympa....... à+.
____________________
Roro
Roro
Coucou! .....Meme pas mal aux cheveux!
J'ai vu que tu était passé sur le site, alors pour illustrer mon idée de transfert de la carte dans le scope, voici un petit bidouillage.
Le tableau de transfert n'apparait qu'aprés un clic sur up/down ou sur Haut/Bas/Droite....
Je l'avais mis en dynamique avec le reste; avec 9x9 ça marchait. Avec 15x15 le prog ne répondait plus.
Afficher des nombres, ça coute cher!
Et il est possible que j'ai inversé le banc d'arguein avec la fosse du Japon. (le profond et le pas profond)
Code JB :
c'est une autre histoire pour lire le tableau en partant du centre, et en tournant.
Et encore plus raide pour éffacer derrière.
NOTE: Il doit bien exister des scopes à balayage vertical ou transversal. (les écrans à transfert de charges...)
Edité par Roland Le 30/12/2012 à 14h59
J'ai vu que tu était passé sur le site, alors pour illustrer mon idée de transfert de la carte dans le scope, voici un petit bidouillage.
Le tableau de transfert n'apparait qu'aprés un clic sur up/down ou sur Haut/Bas/Droite....
Je l'avais mis en dynamique avec le reste; avec 9x9 ça marchait. Avec 15x15 le prog ne répondait plus.
Afficher des nombres, ça coute cher!
Et il est possible que j'ai inversé le banc d'arguein avec la fosse du Japon. (le profond et le pas profond)
Code JB :
' Submarine DSRV Simulator...1 Km = 8 pxl: diam=2x7
nomainwin
WindowWidth = 900'600
WindowHeight = 450
UpperLeftX = int((DisplayWidth-WindowWidth) / 10)
UpperLeftY = 10 'int((DisplayHeight-WindowHeight) / 12)
dim info$(1,1)
Fcolor$ = "brown"'darkgreen
statictext #w.ma, "Map:", 10, 240, 25, 20
BUTTON #w.map, "Open", [openMap], UL, 40, 240, 50, 20
BUTTON #w.clo, "Close", [closeMap], UL, 95, 240, 50, 20
BUTTON #w.ha, "haut", [haut], UL, 165,250, 40, 20
BUTTON #w.ga, "gauche", [gauche], UL, 125, 275, 40, 20
statictext #w.map, "Map", 175, 278, 25, 20
BUTTON #w.dr, "droite", [droite], UL, 205, 275, 40, 20
BUTTON #w.ba, "bas", [bas], UL, 165, 300, 40, 20
statictext #w.ni, "niveau:", 255, 240, 35, 40
textbox #w.niv, 295, 240, 40, 20
BUTTON #w.u, "up", [up], UL, 340, 240, 30, 20
BUTTON #w.d, "down", [down], UL, 375, 240, 40, 20
graphicbox #w.sonar, 5, 20, 210, 210
graphicbox #w.scope, 225, 20, 210, 210
graphicbox #w.g, 440, 20, 440, 380
open " Scope" for window_nf as #w
#w "trapclose [exit]"
' ------------------------------------------ init graphics -----------------------------------------
#w.sonar "down ; fill ";Fcolor$
#w.scope,"down ; fill ";Fcolor$
'#w.scope "color 0 ";75+a*5
#w.sonar "backcolor 0 80 0 ; home ; circlefilled 100"
#w.sonar "flush ; discard"
Print #w.g, "When leftButtonDown [ButtonLeftDown]"' a suprimer
Print #w.g, "When leftButtonUown [ButtonLeftUp]"
' -------------------------------------------- init var. ------------------------------------
#w.niv,"120"
pi=3.1416
dc = 8 ' dim of a map cell in pixels.
Xmax = 100 ' nber of X cells for the map
Ymax = 50 ' nber of Y cells for the map
dim map(Xmax,Ymax) ' map
dim scope(15,15)' transfert map de 25 à 50
dsrvX = 30 ' current x pos Submarine
dsrvY = 10 ' current y pos "
olddsrvX = dsrvX ' old x pos Submarine
olddsrvY = dsrvY ' old y pos "
xa=dsrvX:ya=dsrvY
'--------------------------------- Ouverture du prog -----------------------
GOSUB [ReadMapFile]
'----------------------------------------------------------------
'wait
#w.g "down ; fill ";"white"
'-------------------------------------- DEBUT -------------------------
[sonar] ' called time loop
' scan
r = r+1-360*(r=360) ' 360 -> 1
for a=1 to 20 ' radar effect
#w.sonar "color 0 ";75+a*5;" 0 ; size 1 ; delsegment "; drawSegment - 1
#w.sonar "home ; north ; turn ";r+a;" ; go 100 ; segment drawSegment"
next
#w.sonar, "flush ; discard"
'-------------------------------- INIT SCOPE -------------------------
sx=1:sy=1 '............transfert map-->scope
xb=xa+14
yb=ya+14
if yb >Ymax-1 then yb=Ymax-1
if xb >Xmax-1 then xb=Xmax-1
for x=xa to xb
for y=ya to yb
scope(sx,sy)=map(x,y)
sy=sy+1
next y
sy=1:sx=sx+1
next x''''''''''''''''''''''''''''''''''''
'---------------------------------------------------------------
gosub [compute] ' calculate all values
gosub [DispDSRVpos] ' on map if opened
gosub [dispScope]
timer 16, [sonar]
wait
[openTab]
#w.g "color black" '.........Tableau verif
xx=10:yy=20
for x=1 to 14
for y=1 to 14
#w.g, "PLACE "; xx; " "; yy
#w.g, "\"; scope(x,y)
yy=yy+25
next y
yy=20
xx=xx+30
next x '''''''''''''''''''''''''''''''''
wait
[haut]
ya=ya-1:dsrvY=dsrvY-1
if dsrvY < 1 then dsrvY=1
if ya < 1 then ya=1
goto [openTab]
wait
[gauche]
xa=xa-1:dsrvX=dsrvX-1
if dsrvX < 1 then dsrvX=1
if xa < 1 then xa=1
goto [openTab]
wait
[bas]
ya=ya+1:dsrvY=dsrvY+1
if dsrvY >Ymax-1 then dsrvY=Ymax-1
if ya > Ymax-2 then ya =Ymax-2
goto [openTab]
wait
[droite]
xa=xa+1:dsrvX=dsrvX+1
if dsrvX >Xmax-1 then dsrvX=Xmax-1
if xa > Xmax-1 then xa=Xmax-1
goto [openTab]
wait
[up]
pro=pro-5
#w.niv,str$(pro)
goto [openTab]
wait
[down]
pro=pro+5
#w.niv,str$(pro)
goto [openTab]
wait
'---------------------------------- SCOPE Display ------------------
[dispScope]
print #w.niv, "!contents? var$"
pro = val(var$)
#w.scope,"fill ";Fcolor$
#w.scope "color green ; size 2" 'passe de 3 à 2 pour test
for xsco=1 to 14
for ysco=1 to 14
' scan
prof=scope(xsco,ysco)
if prof < pro then
print #w.scope, "set ";xsco*20;" ";ysco*20
' print #w.scope, "set ";xsco*20+4;" ";ysco*20
' print #w.scope, "set ";xsco*20+4;" ";ysco*20+4
' print #w.scope, "set ";xsco*20;" ";ysco*20+4
' print #w.scope, "set ";xsco*20+8;" ";ysco*20
' print #w.scope, "set ";xsco*20;" ";ysco*20+8
end if
next ysco
next xsco
#w.scope, "flush ; discard"
return
[compute] ' to simulate inertia, commands could be divided by 10 ?
return
wait
[DispDSRVpos] ' display the current position of the DSRV on the map.
if mapDisp and olddsrvX<>dsrvX and olddsrvY<>dsrvY then
Dcolor$ = "0 ";255-map(olddsrvX,olddsrvY);" 255"
#map "size 1 ; backcolor ";Dcolor$;" ; color ";Dcolor$
#map "place ";olddsrvX*dc;" ";olddsrvY*dc;" ;boxfilled ";olddsrvX*dc+dc;" ";olddsrvY*dc+dc
#map "backcolor red ; color red"
#map "size ";dc-1;" ; set ";dsrvX*dc+dc/2;" ";dsrvY*dc+dc/2 ' current x,y pos Submarine
#map "flush ; discard"
olddsrvX = dsrvX
olddsrvY = dsrvY
end if
return
[openMap] ' when click on MAP button
opmap=1
UpperLeftX = UpperLeftX + 10
UpperLeftY = UpperLeftY + WindowHeight
WindowWidth = 810
WindowHeight = 462
open "DSRV Map" for graphics_nf_nsb as #map
#map "trapclose [closeMap]"
#map "down ; fill black"
Xg = 250
for c = 1 to Xg ' deep scale
#map "backcolor black ; color yellow "
if c=1 or c mod 10 = 0 or c=Xg then #map "place ";5+(c-1)*int((WindowWidth-20)/Xg);" 18;|";c
#map "color black ; place ";10+(c-1)*int((WindowWidth-20)/Xg);" 25"
#map "backcolor 0 ";255-c;" 255 ; boxfilled ";12+c*int((WindowWidth-20)/Xg);" ";25+20
next
#map "backcolor black ; color yellow ; place ";WindowWidth-46;" 40 ;|x10 m"
#map "backcolor 253 238 153 ; place 0 26 ; boxfilled 10 44"
' MAP reading...
for y=0 to Ymax
for x=0 to Xmax
Dcolor$ = "0 ";255-map(x,y);" 255"
if map(x,y) = 0 then Dcolor$ = "253 238 153"
#map "place ";x*dc;" ";50+y*dc;" ; backcolor ";Dcolor$;" ; color ";Dcolor$
#map "boxfilled ";x*dc+dc;" ";50+y*dc+dc
next
next
' display the current position of the DSRV on the map.
Dcolor$ = "0 ";255-map(olddsrvX,olddsrvY);" 255"
#map "backcolor ";Dcolor$;" ; color ";Dcolor$
#map "place ";olddsrvX*dc;" ";olddsrvY*dc;" ;boxfilled ";olddsrvX*dc+dc;" ";olddsrvY*dc+dc
#map "backcolor red ; color red"
#map "size ";dc-1;" ; set ";dsrvX*dc+dc/2;" ";dsrvY*dc+dc/2 ' current x,y pos Submarine
#map "flush ; discard"
olddsrvX = dsrvX
olddsrvY = dsrvY
wait
[ReadMapFile]
filename$ = "map.txt"
if fileExists(DefaultDir$, filename$) then
open filename$ for input as #grid
for y=0 to Ymax
LINE INPUT #grid, grid$
for x=0 to Xmax : map(x,y)=val(word$(grid$,x+1)) : next
next
close #grid
else
notice "No file ";upper$(filename$)
goto [exit]
end if
return
[closeMap]
if mapDisp then mapDisp = 0
close #map: opmap=0
WindowWidth = 835 ' restore #w setup
WindowHeight = 505
UpperLeftX = int((DisplayWidth-WindowWidth) / 10)
UpperLeftY = 10
wait
FUNCTION fileExists(path$, filename$)
'DIM info$(1,1) must be declared at the start of the prog.
files path$, filename$, info$( ' path$ = 'DefaultDir$' generally.
fileExists = val(info$(0, 0)) 'not zero if true
END FUNCTION
' Sub ButtonLeftUp handle$, xClick, yClick 'prise de cotes
' Print #w.g, "Place ";xClick;" ";yClick 'a suprimer
' Print #w.g, "\x=";xClick
' Print #w.g, "\y=";yClick
' End Sub
[exit]
timer 0
if opmap=1 then close #map:opmap=0
if mapDisp then close #map:opmap=0
close #w
end
c'est une autre histoire pour lire le tableau en partant du centre, et en tournant.
Et encore plus raide pour éffacer derrière.
NOTE: Il doit bien exister des scopes à balayage vertical ou transversal. (les écrans à transfert de charges...)
Edité par Roland Le 30/12/2012 à 14h59
____________________
Roro
Roro
En tout cas tu t'amuses bien
____________________
Devise Shadocks : "Mieux vaut mobiliser son intelligence pour des conneries, que mobiliser sa connerie pour des choses intelligentes"
Coluche disait : "C'est parce que la vitesse de la lumière est plus rapide que celle du son que certains peuvent paraîtrent brillants jusqu'à ce qu'ils ouvrent la bouche."
Devise Shadocks : "Mieux vaut mobiliser son intelligence pour des conneries, que mobiliser sa connerie pour des choses intelligentes"
Coluche disait : "C'est parce que la vitesse de la lumière est plus rapide que celle du son que certains peuvent paraîtrent brillants jusqu'à ce qu'ils ouvrent la bouche."
Web
Quand on coupe un saucisson en rondelles, la surface exploitable augmente.
Tes codes, c'est pareil....
Sur le forum de maths, j'ai reçu la réponse de quelqu'un qui dit pouvoir m'aider, mais qui m'a demandé un schéma ?
Je lui ai fait un zouli dessin.
Si tu a l'esprit à la "net'promenade" Le nom c'est 'Forum de math". J'ai mis mon deuxième prénom Valentin03
c'est dans "Lycée" , conv polaire-cartésien.
Si tu y va, cherche avec "terroriste", ou à topic le plus vu. Ca bastonne pas mal.
Edité par Roland Le 25/12/2012 à 19h09
Tes codes, c'est pareil....
Sur le forum de maths, j'ai reçu la réponse de quelqu'un qui dit pouvoir m'aider, mais qui m'a demandé un schéma ?
Je lui ai fait un zouli dessin.
Si tu a l'esprit à la "net'promenade" Le nom c'est 'Forum de math". J'ai mis mon deuxième prénom Valentin03
c'est dans "Lycée" , conv polaire-cartésien.
Si tu y va, cherche avec "terroriste", ou à topic le plus vu. Ca bastonne pas mal.
Edité par Roland Le 25/12/2012 à 19h09
____________________
Roro
Roro
J'ai saupoudré la sonde de sinus et cosinus. Elle affiche dans plusieurs azimuts, mais il y a des angles où il n'y a rien.
Si tu veux que la sonde n'y voit que dans l'axe du Soum ( cahier des charges), il suffit de coupler avec l'azimut.
Mais ça serait mieux si elle était orientable. Pour cela, il faudrait ajouter un afficheur 3 digits et une mollette.
Je trouve tes afficheurs un peu gros, ça bouffe de la place.
Pour les angles où il n'y a rien, c'est possible que ça vienne des coeffs que j'ai mis un peu à l'arrache.
Il faudrait brancher les anglophonistes sur le changement de système de coordonnées.
Parce que du côté des matheux, c'est pas impossible qu'il y en aient qui confondent etre une grosse tête, et avoir la grosse tête........à+.
Si tu veux que la sonde n'y voit que dans l'axe du Soum ( cahier des charges), il suffit de coupler avec l'azimut.
Mais ça serait mieux si elle était orientable. Pour cela, il faudrait ajouter un afficheur 3 digits et une mollette.
Je trouve tes afficheurs un peu gros, ça bouffe de la place.
Pour les angles où il n'y a rien, c'est possible que ça vienne des coeffs que j'ai mis un peu à l'arrache.
Il faudrait brancher les anglophonistes sur le changement de système de coordonnées.
Parce que du côté des matheux, c'est pas impossible qu'il y en aient qui confondent etre une grosse tête, et avoir la grosse tête........à+.
____________________
Roro
Roro
Roland:
Dans mon code la position du soum sur la carte c'est dsrvX et dsrvY et la routine [DispDSRVpos] se charge de l'afficher sur la carte...!
Tu fais évoluer dsrvX dsrvY dans la routine [compute] (c'est là que tous les calculs d'interraction entre les commandes du pilote et le soum sont prévus) et tu verras le point rouge bouger sur la carte, plus simple que ça je vois pas !
Attention : dsrvX et dsrvY ne sont pas en pixel mais en coordonnées x,y dans MAP().
J'ai dit que la MAP faisait 100km sur 50km donc 8 pixels = 1 km, mais rien n'empêche de décider d'une autre échelle, par exemple une case de la MAP() = 100m x 100m, ce qui réduira l'aire de jeu à 10km x 5km, mais comme le soum mesure 15m ça peut être pas mal. A cette échelle, dsrvX et dsrvY ne bougeront que si le soum a parcouru au moins 100m...!
@+
Edité par cassiope01 Le 26/12/2012 à 11h37
Je ne suis pas arrivé à reporter la position du SM sur la carte. 
Dans mon code la position du soum sur la carte c'est dsrvX et dsrvY et la routine [DispDSRVpos] se charge de l'afficher sur la carte...!
Tu fais évoluer dsrvX dsrvY dans la routine [compute] (c'est là que tous les calculs d'interraction entre les commandes du pilote et le soum sont prévus) et tu verras le point rouge bouger sur la carte, plus simple que ça je vois pas !
Attention : dsrvX et dsrvY ne sont pas en pixel mais en coordonnées x,y dans MAP().
J'ai dit que la MAP faisait 100km sur 50km donc 8 pixels = 1 km, mais rien n'empêche de décider d'une autre échelle, par exemple une case de la MAP() = 100m x 100m, ce qui réduira l'aire de jeu à 10km x 5km, mais comme le soum mesure 15m ça peut être pas mal. A cette échelle, dsrvX et dsrvY ne bougeront que si le soum a parcouru au moins 100m...!
@+
Edité par cassiope01 Le 26/12/2012 à 11h37
____________________
Devise Shadocks : "Mieux vaut mobiliser son intelligence pour des conneries, que mobiliser sa connerie pour des choses intelligentes"
Coluche disait : "C'est parce que la vitesse de la lumière est plus rapide que celle du son que certains peuvent paraîtrent brillants jusqu'à ce qu'ils ouvrent la bouche."
Devise Shadocks : "Mieux vaut mobiliser son intelligence pour des conneries, que mobiliser sa connerie pour des choses intelligentes"
Coluche disait : "C'est parce que la vitesse de la lumière est plus rapide que celle du son que certains peuvent paraîtrent brillants jusqu'à ce qu'ils ouvrent la bouche."
Web
Oui, j'ai du me planter quelque part. Car j'ai fais avec: dsrvX et dsrvY, et le soum montait en y au lieu de descendre.
Note: je ne mets pas à [compute]. Parce que à compute, c'est le déplacement en fonction de: Vitesse/Angle de barre.(Polaire/Cartésien), et que dans mon bidouillage, je déplace en cartésien (Haut/Bas/Droite/Gauche)
Ce que fait aussi le gars dans le prog en: C (Avant/arrière/Haut/bas)
Si tu veux faire fonctionner le scope du sonar, il y a la solution de changer l'echelle de la carte.
Et de faire une carte plus grande en l'affichant dans une fenêtre avec ascenseurs ( si c'est possible ?)
J'essaie de réduire les afficheurs ! ? % § ..&..@ 3 # ^^ ! ....@+.
Edité par Roland Le 26/12/2012 à 13h42
Note: je ne mets pas à [compute]. Parce que à compute, c'est le déplacement en fonction de: Vitesse/Angle de barre.(Polaire/Cartésien), et que dans mon bidouillage, je déplace en cartésien (Haut/Bas/Droite/Gauche)
Ce que fait aussi le gars dans le prog en: C (Avant/arrière/Haut/bas)
Si tu veux faire fonctionner le scope du sonar, il y a la solution de changer l'echelle de la carte.
Et de faire une carte plus grande en l'affichant dans une fenêtre avec ascenseurs ( si c'est possible ?)
J'essaie de réduire les afficheurs ! ? % § ..&..@ 3 # ^^ ! ....@+.
Edité par Roland Le 26/12/2012 à 13h42
____________________
Roro
Roro
Y'a moyen d'ajouter un afficheur 3 digit et une mollette, en poussant les sliders sur la droite, et en agrandissant un chouia la fenêtre.
Je le tente dans un module séparé, car je n'ai pas l'abilitation pour toucher à: [displayValue] ( il faut disposer des droits:administrateur "extraterrestre".)
Je le tente dans un module séparé, car je n'ai pas l'abilitation pour toucher à: [displayValue] ( il faut disposer des droits:
____________________
Roro
Roro
____________________
Roro
Roro
Deux problèmes:
1)- JB, s'il donne l'heure, n'indique pas le nord !
Si tu veux afficher le "cap"; il faudra poser un dipole sur le Soum, et tester la position de poles. (si les sprites, chez moi, n'étaient des insoumis je tenterais la chose.)
2)- La vitesse minimale du Soum est soumise au Timer.
En effet, quelque coeff que l'on puisse appliquer, à quelque endroit que ce soit, la valeur finale du déplacement ne peut etre inférieure à: 1.
1 pxl toutes les 20ms =50 pxls/sec... 50pxls/8 = 6,25 Km/sec...
Ce qui fait beaucoup pour un Sous-marin.
J'ai donc réduit le déplacement à 1pxl tous les 10 cycles.
Démo: Enfer de Trigo.zip
La bête tourne gentiment, mais ne maintiens pas le cap quand la barre est remise à zéro. Y'a encore du boulot.
M'est avis que tu nous a levé un sacré lièvre avec ton DSRV.
Edité par Roland Le 28/12/2012 à 00h42
1)- JB, s'il donne l'heure, n'indique pas le nord !
Si tu veux afficher le "cap"; il faudra poser un dipole sur le Soum, et tester la position de poles. (si les sprites, chez moi, n'étaient des insoumis je tenterais la chose.)
2)- La vitesse minimale du Soum est soumise au Timer.
En effet, quelque coeff que l'on puisse appliquer, à quelque endroit que ce soit, la valeur finale du déplacement ne peut etre inférieure à: 1.
1 pxl toutes les 20ms =50 pxls/sec... 50pxls/8 = 6,25 Km/sec...
Ce qui fait beaucoup pour un Sous-marin.
J'ai donc réduit le déplacement à 1pxl tous les 10 cycles.
Démo: Enfer de Trigo.zip
La bête tourne gentiment, mais ne maintiens pas le cap quand la barre est remise à zéro. Y'a encore du boulot.
M'est avis que tu nous a levé un sacré lièvre avec ton DSRV.
Edité par Roland Le 28/12/2012 à 00h42
____________________
Roro
Roro
Pas besoin d'aller chercher de la 3D... Ta carte, elle est trés bien, et facile à exploiter.
Il faut juste changer l'echelle, et éventuellement l'agrandir ( si elle peut etre affichée dans une fenetre à ascenceurs).
Edité par Roland Le 28/12/2012 à 16h08
Il faut juste changer l'echelle, et éventuellement l'agrandir ( si elle peut etre affichée dans une fenetre à ascenceurs).
Edité par Roland Le 28/12/2012 à 16h08
____________________
Roro
Roro
Bonjour! Encore une tempête de neige et 50cm de plus...
Dur, dur le temps des fêtes!
Après lecture de " submarine_simulator" et vu ta base de données, je pense avoir compris sur quoi vous vous cassez les dents.
Sur le sonar tu veux voir le profil de ce qu'il y a devant pour une direction et une profondeur donnée. Doit-on aussi tenir compte de son inclinaison actuelle??? (là ce serait plus coton!!!) Faudrait probablement aussi définir un "angle de vision" pour le radar devant soi.
J'ai un peu mal aux cheveux mais je vais méditer ça ces jours-ci.
En tout cas pour le code...chapeau. Ya des passages où pour moi c'est du latin.
Bonne Année à tous
ChRiS
Dur, dur le temps des fêtes!
Après lecture de " submarine_simulator" et vu ta base de données, je pense avoir compris sur quoi vous vous cassez les dents.
Sur le sonar tu veux voir le profil de ce qu'il y a devant pour une direction et une profondeur donnée. Doit-on aussi tenir compte de son inclinaison actuelle??? (là ce serait plus coton!!!) Faudrait probablement aussi définir un "angle de vision" pour le radar devant soi.
J'ai un peu mal aux cheveux mais je vais méditer ça ces jours-ci.
En tout cas pour le code...chapeau. Ya des passages où pour moi c'est du latin.
Bonne Année à tous
ChRiS
Re bonjour!
Je me suis plongé dans le problème que je pige maintenant parfaitement. Je comprend maintenant votre histoire de conversion polaire/cartésien. Je pense que c'est relativement facile à réaliser...je vais plancher la dessus au cours de la semaine si ma copine me laisse du répit.
J'aurais une question histoire de m'éclaircir les idées... Bon j'ai compris la base de données (matrice à 2 dimensions x et y). La profondeur est donnée pour une adresse en X de 0 à 100 et en Y de 0 à 50. L'origine (0,0) est donc en haut à gauche sur le graphique (la carte).
Maintenant pour le référentiel de direction (azimut), je voudrais savoir si vous avez choisi votre 0 degrés en haut comme je l'ai noté sur ma map ou autrement???
Tant qu'à travailler, aussi bien que j'aille dans la bonne direction.
Pour ce qui est du radar, est-ce que je travaille avec un rayon de 8Km autour du soum comme je l'ai lû quelque part?
Si c'est le cas, il faudrait séparer le balayage de 360 degrés du radar en 50 steps de 7,162 degrés chacun de façon ce que chaque pas couvre un arc de 1 km (qui est notre résolution) à la limite de la portée du radar. À chaque pas il faudra comparer le niveau des 8 cellules (portée de 8 km) constituant la pointe de tarte avec la profondeur du sous marin et afficher le résultat sur l'écran radar. Donc un total de 400 calculs par balayage.... Un beau problème, mais pas insurmontable.
Je met mes neurones là dessus et je vous reviens plus tard..
Je me suis plongé dans le problème que je pige maintenant parfaitement. Je comprend maintenant votre histoire de conversion polaire/cartésien. Je pense que c'est relativement facile à réaliser...je vais plancher la dessus au cours de la semaine si ma copine me laisse du répit.
J'aurais une question histoire de m'éclaircir les idées... Bon j'ai compris la base de données (matrice à 2 dimensions x et y). La profondeur est donnée pour une adresse en X de 0 à 100 et en Y de 0 à 50. L'origine (0,0) est donc en haut à gauche sur le graphique (la carte).
Maintenant pour le référentiel de direction (azimut), je voudrais savoir si vous avez choisi votre 0 degrés en haut comme je l'ai noté sur ma map ou autrement???
Tant qu'à travailler, aussi bien que j'aille dans la bonne direction.
Pour ce qui est du radar, est-ce que je travaille avec un rayon de 8Km autour du soum comme je l'ai lû quelque part?
Si c'est le cas, il faudrait séparer le balayage de 360 degrés du radar en 50 steps de 7,162 degrés chacun de façon ce que chaque pas couvre un arc de 1 km (qui est notre résolution) à la limite de la portée du radar. À chaque pas il faudra comparer le niveau des 8 cellules (portée de 8 km) constituant la pointe de tarte avec la profondeur du sous marin et afficher le résultat sur l'écran radar. Donc un total de 400 calculs par balayage.... Un beau problème, mais pas insurmontable.
Je met mes neurones là dessus et je vous reviens plus tard..
• Index
1 Utilisateur en ligne : 0 Administrateur, 0 Modérateur, 0 Membre et 1 Visiteur
Utilisateur en ligne : Aucun membre connecté
Utilisateur en ligne : Aucun membre connecté
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie