MOUSE_xxx_DOWN non reconnu dans SCENE2D

J'ai un problème de reconnaissance de MOUSE_LEFT_DOWN et MOUSE_RIGHT_DOWN dans un SCENE2D, dès la présence d'au moins un sprite dans le scene2d.

Sur ma scene2d, je peux intercepter le click de la souris dans n'importe quelle position, tant qu'il n'y a pas de sprite. Dès que le place un seul sprite (le fichier BMP chargé dans le sprite fait 45x45 pixels), je ne peux plus intercepter un click dans le carré (0,0) à (60,60), même si je place le sprite ailleurs, par SPRITE_POSITION. Cette zone reste non réactive au click de souris, quoi que je fasse.

Voici un petit programme pour le mettre en évidence. Il faut taper Echap pour en sortir:

Code:

width 0,700 : height 0,700

scene2d 10 : top 10,10 : left 10,10
width 10,500 : height 10,500
sprite_target_is 10

picture 30 : top 30,10 : left 30,530
width 30,45 : height 30,45
2d_target_is 30
2d_clear
2d_pen_color 255,0,0
2d_fill_color 255,0,0
2d_circle 22,22,18
2d_flood 1,1,0,0,0
file_save 30,"cercle.bmp"

sprite 1 : sprite_file_load 1,"cercle.bmp"  : ' image de 45x45 pixels
sprite_position 1,300,400

alpha 20 : top 20,550 : left 20,10

repeat
    if mouse_left_down(10)=1
        caption 20,str$(mouse_y_position(10))+","+str$(mouse_x_position(10))
        repeat : until mouse_left_down(10)=0
    end_if

until scancode=27
terminate

end

Le programme fabrique sa propre image du sprite (un rond rouge). Les coordonnées d'un clic de souris sont affichées dans un alpha en bas à gauche. On voit que ça marche partout, y compris sur le sprite, sauf dans la petite zone de 60x60 en haut à gauche de la scene2d. Si par contre, un met les lignes 18 et 19 en commentaire, on intercepte le clic parfaitement dans cette zone. C'est donc l'apparition du sprite qu perturbe cela, et je ne vois pas non plus plourquoi une zone de 60x60 alors que mon sprite fait 45x45...

j'ai bien un cercle rouge en bas un peu vers la droite dans le grand carré, et quand je clique sur le cercle rouge avec LMB
j'ai la position du curseur tout en bas de la fenêtre. ???

Si mes souvenirs sont exact on a toujours eu une zone morte en haut a gauche avec une scene2d.

@659_minifly:
Mon problème n'est pas le cercle rouge. Là, je récupère bien le clic. Non, c'est le coin en haut à gauche, de 60 sur 60 pixels. Dans cette zone, on ne peut pas récupérer le clic. Si par contre, in désactive les lignes 18 et 18, on ne charge donc pas de sprite, alors cette zone est bien active. C'est bien la preuve que le problème est lié à l'apparition du premier sprite. Il apparaît systématiquement en haut à gauche. Et lorsqu'on déplace le sprite, cette zone reste inactive. Pire, car même en cliquant sur un sprite (et dans le jeu, que je développe, il y en a quelques dizaines), on récupère le clic et on peut ainsi désigner un sprite par un clic, en comparant à ses coordonnées, SAUF s'il est dans cette zone de 60x60 en haut à gauche. Je pense qu'il y a un bug généré par un effet secondaire lors de l'apparition d'un sprite dans la scene2d. D'ailleurs, la documentation de donne pas la dimension initiale d'un sprite, comme c'est le cas des objets standards. Serait-ce 60x60 ? La notion de taille initiale est peut-être un non-sens, sachant que le sprite adopte automatiquement la taille du BMP qu'on charge dedans ?

Et si l'on avait toujours une zone morte dans un scene2d, pourquoi cela n'a-t-il pas été reconnu comme bug ? La documentation ne dit rien sur une zone réagissant différemment du reste de la surface !

Non je n'ai pas déclaré comme bug.La zone de 60x60 est aussi là depuis que je programme avec Panoramic.

Alors, si ça dure depuis si longtemps, ça vaudra peut-être le coup que JAck jette un coup d'oeil, même si c'est juste pour me dire que je me plante et que j'ai mal compris quelque chose.

Je regarde s'il y a un problème.

Salut Klaus.
Je vois ceci:

Citation :

et dans le jeu, que je développe, il y en a quelques dizaines

Pour connaitre les positions souris par rapport aux autres, je m'excuse de poser cette question: tu fais comment?

Eh bien, je récupère la position horizontale et verticale du clic de la souris de la manière suivante:
Je fais une boucle d'attente, car je dois gérer en même temps la frappe de touches, simultanément avec les clics sur des endroits précis de la scene2d. Pas question de faire des on_click ou on_key_down - cela bloque, et on perd les trois quarts des évènements.
Sachant que mon scene2d a le numéro d'objet o_plan%:

Code:

repeat
    if mouse_left_down(o_plan%)=1
        i% = mouse_x_position(o_plan%)
        j% = mouse_y_position(o_plan%)
        repeat : until mouse_left_down(o_plan%)=0
        lig% = int((j%-5)/50) + 1
        col% = int((i%-5)/50) + 1
        sprite_position n_sprite%,(col%-1)*50+5,(lig%-1)*50+5
        goto sauter
    end_if
    if mouse_right_down(o_plan%)=1
        repeat : until mouse_right_down(o_plan%)=0
        goto jeter
    end_if
    i% = scancode
    if i%>0
        while scancode>0 : end_while
        select i%
...etc...

Tu vois que je commence par tester si la touche gauche de la souris est enfoncée, puis la touche droite, puis la présence d'une touche de clavier quelconque. Pour éviter les doublons, j'attends impérativement que la touche en question soit relevée, avant de poursuivre le traitement.
Dans le cas du clic gauche, j'utilise MOUSE_X_POSITION() et MOUSE_Y_POSITION pour récupérer les coordonnées en pixels, relatives au coin en haut à gauche de mon plan de jeu. J'effectue ensuite un calcul pour déterminer la cellule visée, sachant que mon plan de jeu est divisé en 8 lignes de 9 cellules, chacune mesurant 45x45 pixels, avec une séparation de 5 pixels horizontalement et verticalement, également sur le pourtour. J'identifie donc facilement ma cellule, et j'ai un tableau dans lequel je mémorise, pour chaque cellule, le ou les numéros de sprite qui s'y trouvent. Et si j'avais un plan continu sans séparation en cellules, il suffirait d'avoir un tableau contenant, pour tous les sprites définis, les coordonnées de leur coin en haut à gauche (celles qui ont servi à la commande SPRITE_POSITION), ainsi que leur largeur et hauteur (dimensions du BMP chargé dedans), et je peux ainsi, par une boucle, déterminer dans quel sprite le clic a eu lieu.

Merci Klaus.
Ma question n'était pas innocente. J'ai trouvé ces jours ci une autre méthode, et j'ai pensé que je pouvais t'en faire profiter.

J'ai d'abord vérifié un point, concernant le on_change. Savoir si en mettant le même texte dans un edit, il y avait branchement:

Code:

label teste ,bouton

edit 1
on_change 1,teste
button 2:left 2,200 :on_click 2,bouton
end
teste:
message "couic"
return
bouton:
text 1,"bien"
return

et le résultat qu'il n'y a pas de branchement. Cela ma permis d'essayer quelque chose:

Code:

label picture1,picture2,picture3,picture4,blanc,teste :font_size 0,12

picture 1:left 1,10  :top 1, 10 :width 1,100:height 1,100 : color 1,255,255,0
edit  10:left 10,120:top 10,10 :text 10,"0,0"            : on_change 10,picture1

picture 2:left 2,10  :top 2, 120:width 2,100:height 2,100 : color 2,0,255,0
edit  20:left 20,120:top 20,120:text 20,"0,0"            : on_change 20,picture2

picture 3:left 3,10  :top 3, 230:width 3,100:height 3,100 : color 3,255,0,0
edit  30:left 30,120:top 30,230:text 30,"0,0"            : on_change 30,picture3

picture 4:left 4,10  :top 4, 340:width 4,100:height 4,100 : color 4,0,0,255
edit  40:left 40,120:top 40,340:text 40,"0,0"  :font_color 40,255,255,255
                                                          : on_change 40,picture4
timer  5:timer_interval 5,150:on_timer 5,teste
end
' ============================================
teste:
  timer_off 5
  text 10,str$(mouse_x_position(1))+","+ str$(mouse_y_position(1))
  text 20,str$(mouse_x_position(2))+","+ str$(mouse_y_position(2))
  text 30,str$(mouse_x_position(3))+","+ str$(mouse_y_position(3))
  text 40,str$(mouse_x_position(4))+","+ str$(mouse_y_position(4))
  timer_on 5                                :return
' ============================================
blanc:
 color 10,255,255,255 : color 20,255,255,255
 color 30,255,255,255 : color 40,255,255,255  :return
picture1:
  gosub blanc:color 10,255,255,0            :return
picture2:
  gosub blanc:color 20,0,255,0              :return
picture3:
  gosub blanc:color 30,255,0,0              :return
picture4:
  gosub blanc:color 40,0,0,255              :return

Salutation

Merci, je vais regarder cela.

bonsoir Klaus,
Ton attente du relachement de la touche est bloquante et donc ton prog est figé tant que le bouton de la souris est actionné.
Pourquoi tu n'utiliserais pas des flags ?

Code:

[pseudo code]
boucle_de_traitement:
 si bouton_droit alors flag_droit =vrai
 si bouton_gauche alors flag_gauche=vrai
 ...
 ... etc..
 si pas bouton_droit et flag_droit = vrai
    traitement_droit
 finsi
 ...
fin_boucle[/pseudocode]

Pourquoi ? Parce que de toutes façons, tant que le bouton gauche n'est pas relâché, je ne peux pas traiter un click droit, ni la frappe d'un caractère, et vice-versa. Dans mon programme, ces évènements sont par conception mutuellement exclusifs, et je n'ai que ces 3 évènements à gérer. Même si je faisais ce que tu montres (et qui marche, bien sûr), je ne gagnerais rien car de toutes façons, je devrais attendre l'arrivée du flag...

Je publierai prochainement le jeu que je suis en train d'écrire (il est presque prêt) - il ne manque que la solution du problème de l'inactivité du rectangle de 60x60 de la scene2d.

@Cosmos70: jolie application du timer ! Parfait pour un color picker, par exemple.

Je ne connais pas la structure de ton prog, mais l'utilisation du flag te permettrait de faire bouger des sprites même si les touches de la souris sont actionné...
Comme je te le dis, je ne connais pas la structure de ce que tu as fait.
Mais intuitivement, je me dis que si tu fais un jeu avec des sprites qui se baladent,
tant que le bouton de la souris est actionné, les sprites sont "gelés"...
Je me trompe ?

Pas tout à fait. J'utilise la souris pour sélectionner une cellule dans laquelle un sprite devra se positionner, ou pour sélectionner un sprite déjà dans une cellule. Mes petits sprite ne se déplacent pas tous seuls. En fait, j'écris un clone du jeu Alchemy de PopCap Games (jeu payant). Je suis fan absolu de ce jeu, et cela me permet d'avoir une version parfaitement gratuite et open source. Les graphismes sont certes simplissimes, pour le moment, mais les règles de jeu seront exactement les mêmes. Il s'agit de placer des pions qui apparaissent un à un, dès qu'un pion a été placé, de sorte qu'il touche horizontalement et/ou verticalement au moins un autre pion, mais en respectant à chaque contact, soit la même forme, soit la même couleur. Une ligne ou une colonne complète se vide automatiquement, en laissant une marque montrant que ces cases ont déjà été occupées, et le but final est d'occuper chaque case au moins une fois pour compléter un niveau. La difficulté réside dans le fait qu'on arrive des fois à l'impossibilité de placer le pion proposé. On peut alors le jeter "à la poubelle" par un clic droit (ou la touche BS), mais on a droit seulement à 4 échecs successifs. Au 5ème, on a perdu la partie. Si le niveau est gagné, le plateau se vide et un passe au niveau suivant, avec plus de couleurs et plus de pions différents pour compliquer. Le programme sera fourni avec un petit programme créant automatiquement le dessin du plan de jeu et tous les BMP des sprites. Voilà mon projet.

Vu sous cet angle, les flags n'apportent rien en effet...
Ca à l'air cool ton jeu !

Pour ceux que cela intéresse: un petit coup de Google sur un émulateur de jeux d'arcade : MAME32
cet émulateur a été réalisé au départ par une équipe de fondus qui récupéraient le contenu des PROM qui se trouvaient dans les bornes d'arcade. Je ne suit plus les mises à jour depuis un petit moment mais il y a des milliers de jeux émulés.

Juste une remarque par rapport au programme de démonstration.
Le timer relance effectivement les contrôles, mais ce qui dans ce cas est intéressant, est le contrôles automatiques liés aux objets EDIT associés aux pictures (ici).
Il n'y a pas besoin de faire de boucle pour tester chaque objet et regarder si la souris est là, et la position. Cela se fait automatiquement par la fonction ON_CHANGE d'un EDIT. Dès que la souris navigue dans un picture, automatiquement il y a réaction sur ce picture, en délaissant les autres objets.
Je trouve que cela simplifie le concept dans la programmation, pour le suivi d'une souris dans un objet.

Pour un programme futur, je fais l'essai d'un menu plus complet que celui de Panoramic, celui-ci ne permettant pas d'avoir un coche pour un sub-menu ou inactive.
Les essais me permettent ceci:


L’utilisation d'un edit (évidemment à HIDE) pour chaque objet qui intervient dans le menu, simplifie de beaucoup la programmation. Les branchements d'un objet parcouru par la souris étant automatiques.

Je rajoute que pour le cas d'un menu, il ne peut avoir de problème, vu que les traitements sont instantanés. On clique, et le menu se ferme.
Par contre si les traitements sont longs, il ne faut pas que le ON_CHANGE d'un autre EDIT intervienne pendant le traitement. Il sera nécessaire dans ce cas d'utiliser OFF_CHANGE pour que la procédure aille au terme de son code. (ou changer de méthode et laisser les edits de côtés)

Lors de la création d'un SPRITE, il y avait effectivement une zone de 60 pixels sur 60 pixels en haut à gauche du SCENE2D qui rendait le SCENE2D insensible aux clics avec la souris.

Ce bug est maintenant corrigé.

Super ! J'attends doc la mise en ligne de cette version - le lien vers la version instantanée du 4 Mars ne contient pas encore cette correction. Il n'y a pas d'urgence particulière.

Quand je disais "le bug est corrigé", je voulais dire qu'il a été compris, corrigé et que la correction a été testée, mais pas que la correction était disponible.

D'ici la fin de la semaine, je mettrai à disposition une nouvelle version instantanée qui contient cette correction. Je vais essayer en outre de corriger d'autres bugs, pour que cette version soit la plus propre possible pour les SPRITES.