Ton but c'est d'obtenir la bouding box d'un sprite c'est ca ? Cet algorithme est trivial et ne necessite aucunement de la recursion (j'arrive meme pas trop a voir comment tu l'as casee dans l'histoire d'ailleurs cette affaire de recursion.

Pourrais-tu un peu nous expliquer qu'est-ce que tu cherches a faire et quelles sont les contraintes qui te sont imposees ?

Je pense que ce qu'il fait est similaire a de la detection de contour semi automatique. La fonction inBounds() te permet de savoir si un pixel est dans l'image ou non.

Apres, en fonction de ce qu'il cherche VRAIMENT a faire, il peut y avoir plus simple.

Bah je cherche a trouver une "bounding box" comme tu dis, d'un sprite sur une image

L'image n'est pas assez explicite pour vous ?

J'ai aucunes contraintes, et tu dis que c'est trivial et que ça peux se faire sans récursion, alors ok je veux bien ton algo trivial

Au départ je suis partis sur le fait que le seul moyen de voir ce qui délimite un sprite sur une image c'est le transparent, donc j'ai tout simplement fait une liste de tous les pixels qui sont contigus et qui sont pas transparents... ça marche très bien, j'étais très fier, jusqu'au moment ou sur les sprites beaucoup plus grands ça fait un StackOverflow

Mon but : passer ce StackOverflow

Je suis en train d'essayer d'optimiser mon algo, mais rien n'y fait, je n'y arrive pas trop
Mais noproblem j'ai trouver un autre truc que je testerais plus tard

Si quelqu'un a un algo "trivial" je le veux bien, ça m'apprendra des choses au moins

Non l'image n'est pas assez explicite et même tes explication ne le sont toujours pas. Tout comme ta motivation. Donc si tu pouvais nous dire ce que tu cherches à faire, pourquoi tu cherches à le faire et quelles sont les contraintes et l'espace de complexité sur lesquels se basent ta recherche de bounding box (plusieurs sprites sur une meme page ? un seul sprite en particulier ? dans une region approximative ?).

Oui trouver la bouding box d'un sprite c'est trivial et rien que la description de ton algorithme actuelle montre que tu vas vraiment chercher. Rien que la première étape est certainement plus couteuse qu'un algorithme trivial... Mais encore une fois tout dépend du sujet et de la complexité du problème en entier... Donc si tu pouvais donner ces détails ça serait super pour nous

• tu vas vraiment chercher loin

"Oui trouver la bouding box d'un sprite c'est trivial"

Attendez, je vous suis pas.

Vous me dites que vous savez pas ce que je veux, mais d'un autre cote vous me dites qu'un tel algorithme est trivial...

Donnez le moi alors, je vous dirais si c'est ça...

Je vais chercher loin ?
Bah je suis partis du fait que de toute façon pour savoir où est l'image, faut regarder ses pixels... peut être que je ne connais pas un truc qui permet de faire ça en 2sec mais je vois pas en quoi c'est "chercher loin"

Y'a pas de sujet, c'est pas un TP ou jenesaisquoi, c'est pour mon programme.

Je sais que j'ai beaucoup de mal a m'exprimer/expliquer quelque chose par écrit, donc je vous ai fournis une image de ce que fait mon algorithme. Mais si même avec ça vous voyez pas, cherchez même pas à comprendre ce que j'écris c'est pire
Donc au pire laissez tomber j'essaierai mon dernier truc tout à l'heure.

l'algorithme est si trivial que justement, tout le monde imagine que tu cherches à faire autre chose que simplement chercher la bounding box d'un sprite...

non car pour faire ça, il suffit simplement de parcourir les pixels de son image, retenir l'ordonnée du premier pixel et du dernier pixel rencontrés dans le sens descendant, retenir l'abcisse du pixel le plus à gauche et le plus à droite rencontrés dans le sens transversal, et tu as ta bounding box \ /

Bon ben si en plus de t'entêter à ne pas vouloir donner ni le sujet, ni les éventuelles contraintes, ni l'espace de complexité de ton exercice et tout cela à cause d'un stupide égo bien facilement irritable à travers l'écran...
... Et bien - en tout bien tout honneur - tu peux aller te foutre un pixel mort dans ta bounding sphere de ma part.

Non mais.

Okayyyy je me suis mal exprimé...

C'est pas la bounding box d'une image que je cherche, mais d'une PARTIE d'une image (Comme sur l'image que j'ai posté quoi )

Après, je sais pas si tu l'avais compris, mais avec ton algo, je ne comprends pas c'est quoi ton "premier pixel"

Et sinon tbop c'est pas un exercice, y'a pas de sujet, y'a pas de contraintes, y'a pas de complexité et y'a pas d'égo non plus...

C'est toi qui est parano et qui pense que n'importe qui qui "gueule" à l'écrit possède forcément "un égo facilement irritable à travers l'écran"

D'ailleurs je gueulais pas, et mon post n'était en aucunnement négatif...

J'insulte personne mais toi tu m'insulte, j'en conclus que c'est toi le "facilement irritable"

"C'est pas la bounding box d'une image que je cherche, mais d'une PARTIE d'une image (Comme sur l'image que j'ai posté quoi ) "

la bounding box d'un sous-sprite d'une fiche de sprites? en théorie, pour exploiter cette image en jeu, tu es supposé connaître la manière de la découper pour en extraire chacune des images, il serait facile de faire un parcours d'image à partir de là...

Oui mais justement, je pars du principe que je prends des sprites sur internet, et du coup je ne connais absolument pas comment c'est découpé.

Mais surtout j'aimerais pouvoir les personnaliser au maximum, donc même si je savais comment c'était découpé...

Comme définis-tu la partie de l'image pour laquelle tu veux définir la bouding-box ?

Personnellement face à ton problème, voilà une solution que je propose :

1ère étape :
- On part d'un pixel appartenant à la partie de l'image pour laquelle on veut trouver la bounding-box
- On met dans une liste ce pixel, puis on place dans une pile les quatre pixels autour de ce pixel à condition qu'ils n'appartiennent pas à la liste et qu'il ne soient pas de la couleur qui sépare deux objets de l'image
- Tant que la pile n'est pas vide, on réapplique cette opération sur l'élément au sommet de la pile (c'est un parcours de type depth-first)

2ème étape (une fois que tu as isolé les pixels appartenant à l'objet en question) :
- Tu parcours l'ensemble des pixels de la liste, tu récupères les pixels les plus à gauche, à droite, en haut et en bas et tu as ta bounding-box.

Après, tu peux (voire dois) aussi optimiser cet algorithme en fusionnant ces deux étapes, c'est-à-dire en mettant à jour les pixels extremums en même temps que tu construit la liste des pixels de l'objet.
Ici je sépare les deux étapes pour que ça paraisse plus clair.

Ensuite il y a encore pas mal d'optimisations qu'on pourrait apporter à l'algorithme que je présente, mais comme on dit, "premature optimization is the root of all evil". Essaye d'abord d'implémenter cet algo et ensuite on verra pour l'optimisation.

1. VisionElf Voir le profil de VisionElf
2. Posté le 22 mars 2012 à 20:52:52 Avertir un administrateur
3. Oui mais justement, je pars du principe que je prends des sprites sur internet, et du coup je ne connais absolument pas comment c'est découpé.

et si chaque image d'une animation a une bounding box de forme différente?

non mais sérieux, fais le découpage toi-même au lieu de passer un temps considérable à programmer un truc qui le fera (forcément mal) à ta place, là, ça devient presque ridicule.

Et si tes sprites ont la malheureusement chanc d'être "creux" ou en deux parties ça n'a juste plus aucun sens et de toute façon je peine toujours à voir une finalité exploitable dans un jeu.

Donc la réponse est : n'essaye même pas à moins que tu veuilles te lancer dans du traitement du signal de niveau Licence voire Master. On a ansi comme je le pressentais bien tous perdus notre temps à vouloir aider quelqu'un pour un problème sans sa raison.
Or un problème sans raison n'a pas de raison.

Alors omme je veux avoir le dernier mot et que je suis très content de pouvoir le prononcer :
ça t'apprendra à faire le plus mauvaise-foi que les autres la prochaine fois et à clairement expliquer ton problème dès le début afin d'éviter à tout le monde de :

1) perdre son temps.
2) ses précieux neuronnes.
3) son calme.

Car petite leçon d'humilité n°2 de la journée : l'irritabilité ne nait pas forcément avec l'énervement (humoristique de mon côté dans tous les cas).
Médite ça la prochaine fois avant de jeter aux requins sans aucune raison ceux qui passent du temps à lire tes lignes et à essayer d'y répondre.

Non mais (le retour)

• ont la malheureuse chance

Sinon il me semblait avoir donner un code (probablement non fonctionnel) pour faire exactement ce dont OP parlait.

Ca gérait le cas de motifs en deux parties aussi ?

Evidement que non, ca fait exactement la meme chose que le code d'OP, mais sans stack overflow. C'est basiquement la meme chose que le pot de peinture de MSpaint.

Ah d'accord ok tu parlais de son code original, au temps pour moi.

Aldebran J'ai exactement cet algo.
Seulement, lorsque les "PARTIES" de l'images sont trop grandes, j'ai un StackOverflow.

"Et si tes sprites ont la malheureusement chanc d'être "creux" ou en deux parties ça n'a juste plus aucun sens et de toute façon je peine toujours à voir une finalité exploitable dans un jeu."

Voilà ce que j'en fait : http://img825.imageshack.us/img825/8452/supersmash2.png

Bien sur, comme c'est une image on voit pas les sprites animés, mais en fait ils sont animés grâce à mon logiciel (qui permet entre autres de faire des sprites avec ce fameux algo...)

Mais bon apparemment toi t'es pas chaud pour m'aider, alors m'aide pas

"notre temps"
Es-tu sûr que tout le monde est de tout avis ?

"1) perdre son temps.
2) ses précieux neuronnes.
3) son calme."

Mais lol, cite moi UNE SEULE AUTRE PERSONNE sur ce topic qui a fait ça...

A part toi, y'a personne.
Conclusion : Tu n'aurais pas du poster, et tu n'aurais pas :
1) perdu ton temps
2) tes précieux neuronnes
3) ton calmes

Non mais, c'est n'importe quoi tu rejette tous sur les autres alors que c'est clairement toi qui a perdu ton calme...