Discussion :

[Antoine_935]

Salut à tous

Nouveau dans le monde de la programmation de jeux, je me heurte à une difficulté.

J'ai besoin d'associer un point de l'écran (par exemple, x = 36 et y = 57) à un objet. En d'autres termes, je dois savoir sur quel objet l'utilisateur a cliqué.

Je développe dans un environnement un peu spécial, puisqu'il s'agit de la nintendo DS. Ca signifie que j'ai à la fois des plus petits écrans (256 * 192), mais aussi seulement 4Mo de RAM exploitable pour la logique. Il me faut donc quelque chose d'économe en mémoire.

La solution la plus immédiate, mais inefficace, a été de créer un tableau de 256 * 192 entrée, chacune contenant soit un pointeur, soit NULL. Evidemment, efficacité zero niveau processeur et mémoire... Le calcul est vite fait: 256 * 192 * 4 = 192Ko. Tout cela pour un seul écran bien sur

Je cherche donc un algorithme efficace pour retrouver un objet selon des coordonnées. Quelqu'un peut-il m'aider ?

[Mat.M]

Salut Antoine c'est assez basique ce que tu veux faire : est-ce qu'on peut déclarer des structures dans le système Nintendo Ds ?
Sinon il faut faire une structure qui associe X et Y à chaque objet puis quand l'utilisateur clique sur l'écran il parcourt la liste et regarde si les coordonnées de la souris sont proches des X et Y de chaque objet

[Frifron]

Salut, peux tu nous en dire un peu plus ? Que veux tu faire exactement ? detecter le clic sur un sprite ?

Dans ce cas le plus simple est de tester si la position du stylet est dans le sprite (un rectangle).

Une fois cette phase passée tu peux faire de la collision pixel perfect. C est a dire regarder si le pixel de l image cliqué est transparent ou non. Si oui, le sprite n est pas touché, sinon oui.

[Antoine_935]

C'est affolant que je n'y aie même pas pensé Merci pour cette réponse rapide.

Pour réponse à ta question, Mat, oui, on peut. Elle se programme en C/C++, donc compilée avec gcc et l'aide d'autres librairies (DevKitARM et libnds, pour les curieux qui n'ont pas accès à la sdk officielle nintendo).

Friffon: c'est pour détecter un click sur une sprite tout comme un bouton ou autre (bouton qui ne sera peut-être pas une sprite donc)

Edit: mais... n'y aurait-il pas un moyen qui m'évite de parcourir tous les objets existants ? Une sorte de tri amélioré, un arbre peut-être ?

[kremvax]

Si tu peux partitionner les objets à l'écran dans un arbre, oui en effet tu peux optimiser la recherche du bouton cliqué, mais d'un autre côté, est-ce vraiment utile? Je suppose que tu n'as pas 200 boutons affichés à la fois, le coût d'une recherche linéaire me parait négligeable.

[Frifron]

Le partionnement peut eventuellement etre utile pour culler ton univers non visible a l ecran.

Mais un partitionnement pour la recherche de la zone cliquée risque de faire plus de mal que de bien. Surtout pour un evenement ponctuel comme le check d un clic, ce n est sans doute pas necessaire. Teste deja sans et s il y a un probleme de performance, tu regardera ce qu il faut optimiser.

[IrmatDen]

Salut,

Pas besoin de tout tester ; la majorité des objets ne sont probablement pas cliquables, si ? Auquel ca, il te faut juste garder un tableau d'entités cliquables de côté (que tu initialises au chargement) ; ne te reste plus qu'à tester contre les BB de ces objets.

Edit: pense aussi à ne pas tester les invisibles

[comtois]

Le partionnement peut eventuellement etre utile pour culler ton univers non visible a l ecran.

Mais un partitionnement pour la recherche de la zone cliquée risque de faire plus de mal que de bien. Surtout pour un evenement ponctuel comme le check d un clic, ce n est sans doute pas necessaire. Teste deja sans et s il y a un probleme de performance, tu regardera ce qu il faut optimiser.

Entièrement d'accord avec ça.

Maintenant si tu tiens absolument à partitionner tes données , regarde peut-être le quadtree ?

ou ce tutoriel, je ne l'ai pas encore lu, mais j'y vais de ce pas.

[Antoine_935]

Merci à tous pour ces réponses.

Je vais faire comme vous dites, un simple tableau contenant les coordonnées. Après tout, c'est vrai que ça ne demande pas énormément de travail vu le peu de zones cliquables...

Je regarderai ce quadtree plus en détail demain, il a l'air intéressant tout de même