Projets

Fil des billets - Fil des commentaires

vendredi, janvier 16 2004

BLDocs online : ca avance ...

Par -Alexandre LEGOUT aka LAlex- le vendredi, janvier 16 2004, 12:31

Le parseur de documentation ActionScript 2 que je mène actuellement avec Kalysto, et en collaboration avec Samuel R. Neff, avance. Pas trop vite mais il avance ! :D Pour rappel, il s'agit d'un moyen de générer une documentation (au format HTML ou autre) en analysant les commentaires et signatures d'une ou plusieurs classes AS2. :)

Le processus fonctionnel se déroule en deux étapes : d'abord on parcoure la totalité du code pour en extraire les déclarations de classes, de propriétés et de méthodes, ainsi que les commentaires qui sont a priori des commentaires BLDocs (en gros, ceux qui commencent par /**) ... Ensuite, on peut parser ces parties du code pour générer un fichier XML contenant les informations récupérées, qu'on aura plus qu'à mettre en page grâce à une feuille de style XSLT ... 8)

On peut considérer qu'un commentaire est associé à une classe/propriété/méthode à partir du moment où il n'y a que des espaces et/ou des retours à la ligne entre la fin du commentaire et la déclaration elle-même. Cette première partie est a priori achevée, excepté un debugage éventuel. Donc, si certains d'entre vous ont des classes commentées "à la JavaDoc", ce serait super sympa de vous rendre sur ce parseur pour voir s'il n'oublie rien, ou ne fait pas quelques bêtises !!! :P

Ce parseur a été entièrement recodé par rapport au précédent. En effet, je me suis rendu compte que gérer les imbrications de commentaires, de chaines de caractères et de blocs d'instructions était quasi-impossible avec les expressions régulières uniquement. J'ai donc adopté un système de fonctionnoment séquentiel, toujours au moyen des expressions régulières, qui progresse dans le code, et sait en permanence s'il est dans un commentaire ou dans une chaîne de caractères, et à quel niveau il se trouve (racine, dans la classe, dans un méthode, etc ...) ... :)

L'étape suivante, une fois les commentaires associés aux bonnes déclarations, consiste à parser tout ca, pour en extraire les "tags" du type @param, @return, etc... pour ensuite générer un fichier XML contenant les informations dont on a besoin. Il sera a priori possible de parser un ensemble de classes (plusieurs fichier .as) en les uplodant dasn un fichier .zip contenant l'arborescence des répertoires et des fichiers ! 8)

6 commentaires

mardi, janvier 6 2004

Documentation de code ActionScript 2

Par -Alexandre LEGOUT aka LAlex- le mardi, janvier 6 2004, 10:00

Lorsque j'ai présenté mon parseur AS2, kalysto a lancé l'idée de créer un format de documentation du code, sur la base de JavaDoc. L'idée n'est pas forcément neuve, et Grant Skinner dans son application gModeler (application de diagrammes UML en Flash) à déjà initié ce type de commentaires. :)

Seulement, le format FlashDoc a pour inconvénient de ne pas être libre de droits, et qui plus est dédié à l'AS1. :? Commenter des classes AS1 nécessite de préciser dans la documentation les types de variables, noms de classe, etc... Ce qui n'est plus nécessaire avec l'A2, étant donné que le typage fort, la déclaration de classes et la répartition du code par fichier donnent déjà un grand nombre d'informations.

Nous travaillons donc ensemble à l'élaboration d'un tel format de commentaires, trés proche de JavaDoc, ainsi qu'un parseur qui pourra générer un document XML a partir du code AS, qui lui-même pourra ensuite être mis en page par une feuille de style XSL ... Pour la peine, je suis en train de redévelopper complètement mon parseur AS2, avec deux aspects : un aspect analyse du code (classe, dépendances, méthodes, propriétés) et un autre aspect servant à la colorisation et à la mise en forme du code (blocs d'instructions, chaine de caractères, commentaires, etc...)

J'ai ensuite l'intention de créer un outil basé sur le parseur, qui permettra d'aider à la documentation du code ... Le format XML aidant, cet outil pourra être en PHP et en Flash ! 8)

Les premiers résultats de ces travaux devraient être disponibles dans pas trop longtemps ... :)

6 commentaires

mardi, décembre 2 2003

Tilegame et mouvements : model or not model ?

Par -Alexandre LEGOUT aka LAlex- le mardi, décembre 2 2003, 17:59

Je continue à avancer sur mon moteur de tilegame, et je viens de rajouter les déplacements "en douceur". Ca consiste tout simplement à ne pas téléporter un élément d'une case à une autre, mais de le déplacer progressivement.

C'est en implémentant cette fonctionnalité que je me suis rendu compte d'une erreur que je pense avoir fait lors de ma précédente version : le modèle n'a pas à gérer le déplacement, mais uniquement le position actuelle de l'objet, et ses prochaines positions.





En fait, précédemment, le modèle s'occupait de faire passer les éléments d'une étape à une autre au moyen d'un setInterval. Aprés réflexion, je pense que c'est la vue qui doit demander au modèle la prochaine position de l'objet et l'afficher. Et encore plus quand le déplacement est progressif : en effet, un objet en position (1.2, 3.5) ne veut absolument rien dire pour le modèle. Cela à un sens uniquement pour la vue. :)

Du coup, c'est la vue qui stoque une liste des objets en mouvement. Maintenant, le setInterval s'est déplacé sur la vue. Le modèle dit "Tel élément doit aller à tel position". La vue déplace cet élément, et une fois que l'objet est à destination, la vue dit au controleur "Je suis arrivé". Le controleur demande alors au modèle d'informer la vue de la prochaine position de cet objet, etc... 8| Je sais pas si c'est exactement comme ca que dois fonctionner le MVC, alors si des experts de ce modèle de programmation passent dans le coin, manifestez vous ! :=)

J'ai également un peu modifié la gestion du chemin. Auparavant je parcourais un tableau de positions en incrémentant l'index de la position courante. Maintenant, je fais un shift du tableau, et je récupère la position à l'index 0 à chaque fois ... C'est bien suffisant, et en cas de changement de direction, c'est plus logique ... 8)

15 commentaires

lundi, décembre 1 2003

Tilegame : interactions à la souris et déplacement

Par -Alexandre LEGOUT aka LAlex- le lundi, décembre 1 2003, 14:48

Mon petit moteur de tilegame continue à avancer comme il peut, toujours en MVC "fait-maison" ... :) J'en arrive maintenant à une iteraction à la souris, et au déplacement d'un élément suivant un chemin (accessoirement trouvé avec mon pathfinder A*) ...






Tout d'abord, je me rend compte que mon pathfinder "mis en situation" semble bien fonctionner. Même si c'est vrai que l'espace de recherche est plutôt réduit dans cet exemple, vous remarquerez qu'il n'y a pas de temps de latence (notable) entre le clic sur une case et le départ du l'objet. Et ca, j'en suis assez content ! 8)

J'ai passé un petit moment à réfléchir sur la manière de faire suivre un chemin à un objet, et également à avoir la possibilité de faire se déplacer plusieurs objets en même temps, en ayant des performances correctes. J'en suis arrivé à créer des propriétés _path et _pathPos pour chaque élément. La première contient un tableau renvoyé par le pathfinder, dont chaque élément est un objet ayant les propriétés x et y. Là deuxième est l'indice de la position actuelle.

Les éléments possèdent également une méthode next ... Qui déplace l'objet a la position suivante, et renvoie un booleen qui spécifie s'il reste encore du chemin à faire. S'il est faux, on est au bout du chemin. J'utilise également un système équivalent à la gestion des évenements par Flash. C'est un tableau contenant tous les objets en mouvement. Si un objet arrive au bout de son chemin, il est retiré du tableau. Pour faire bouger un objet, il suffit de lui attribuer un chemin, et de l'ajouter au tableau.

Ainsi, le modèle contient les méthode addMoving, removeMoving, et moveForward, cette dernière faisant avancer tous les objets en mouvement d'une étape. C'est également moveForward qui est appelé dans un intervalle (setInterval) pour simuler le mouvement.

Un aspect pratique est de créer une méthode findPath à laquelle on passe un élément, et des coordonnées d'arrivée. Cela permet de choisir une autre destination pendant le déplacement de celui-ci. Il suffit alors juste de changer le chemin à parcourir pour l'objet, et il continue de se déplacer sur son nouveau chemin. :D

8 commentaires

mercredi, novembre 19 2003

Tilegame : première étape

Par -Alexandre LEGOUT aka LAlex- le mercredi, novembre 19 2003, 11:54

Voici une toute première étape de mon moteur de tilegame ... :) Il s'agit donc pour l'instant d'un affichage en 2D avec vue du dessus. Je compte en fait finaliser le moteur de cette manière avant de faire un affichage en 3D iso.

En effet, de par sa programmation en MVC, la vue (l'affichage) se contente de réagir aux évenements du model (les données). Le plus gros du travail consiste donc a structurer correctement le modele pour qu'il stocke les données de manière optimale, et de lui faire envoyer les bons évenements. La partie affichage ne devient en fait qu'un "détail" ... :)






Pour ce qui est du stockage des données, étant donné que j'ai trouvé peu de ressources sur la programmation d'un tel moteur en POO (beaucoup d'exemples en C, mais c'est pas vraiment pareil), je suis donc parti de rien. Juste le fait de savoir qu'il faut que la carte ai plusieurs niveaux, dans l'optique de la 3D iso.

Le modele contient donc un tableau des différentes couches, qui sont elle-mêmes des tableaux à deux dimensions contenant uniquement des nombres. Pour l'instant je n'ai que deux couches : la couche du sol (les cases blanches), et la couche du décor (les murs, symbolisés par les cases noires).

Le modèle contient également un tableau "d'éléments". Je nomme élément tout ce qui peut recevoir le focus durant un jeu. Certains pouront se déplacer (héro, NPC, etc..), et d'autres non. Une classe Element leur est dédiée. Chaque élément est situé sur une couche de la carte.

Comme il faut le faire en MVC, le contrôleur est la classe qui va spécifier au modèle les actions à effectuer. C'est donc cette classe qui se charge également d'écouter le clavier (pour l'instant, ensuite les déplacements pouront se faire à la souris).

Lors d'une instruction de déplacement d'un élément recue du contrôleur, le modèle vérifie si cet élément peut se déplacer sur la case de destination, et applique ces modifications si c'est le cas. Ensuite, il emet un évenement qui va être reçu par la vue, qui va déplacer le clip correspondant.

Le chargement des données se fait bien évidemment via un fichier XML qui contiendra toutes les infos. Je pense aussi rajouter une balise qui permettra d'affecter une action à une case. Voici la structure du fichier XML :<?xml encoding="UTF-8"?>
<map width="10" height="10">
<layers>
<layer depth="0">
0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0
</layer>
<layer depth="1">
0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0,10, 0, 0, 0, 0, 0, 0, 0, 0,
0,10, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0,10, 0, 0, 0, 0, 0, 0,
0, 0, 0,10, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0, 0, 0, 0, 0, 0, 0, 0
</layer>
</layers>
<elements>
<element type="CHARACTER" layer="1" focus="true">LAlex</element>
</elements>
</map>

En fait, ce moyen de programmer est assez excellent ! :D Je le mets en pratique "à ma manière", étant donné que je n'ai pas vraiment de référence la dessus, mais j'essaie d'appliquer le concept de la manière dont je le comprends, et je trouve ca passionant ! 8)

21 commentaires

mardi, octobre 7 2003

Courbes de Bézier : première approche

Par -Alexandre LEGOUT aka LAlex- le mardi, octobre 7 2003, 15:56

Aprés avoir téléchargé le fichier split-bezier de André Michelle, j'ai aperçu dans le code une fonction du nom de casteljau ... c'est suffisant pour que je recherche à quoi correspond ce nom. :)

L'algorithme de Casteljeau permet de trouver un point faisant partie d'une courbe de Bezier en fonction de ses point de controles, à un pourcentage donné. Il s'agit d'utiliser ce ratio pour obtenir un point situé sur le segment entre un point de contrôle et le point suivant, pour obtenir une série de points de longueur égale au nombre de points de contrôles moins un. La recursivité est utilisée jusqu'à ce que l'on obtienne un seul et unique point. Le point obtenu est situé sur la courbe.

Je me suis donc empressé d'implémenter cet algorithme en Flash, et ca donne un début de classe Bezier, avec pour l'instant une méthode statique casteljau, qui prend en paramètre un ratio, et une liste de coordonnées et retourne un objet avec des coordonnées, et une methode listCasteljau qui retourne un tableau des différentes étapes (dont je me sert pour le SWF ci-dessous). Au fur et à mesure de mes trouvailles, je compléterai cette classe ... ;)

Et en plus d'être interessant, je trouve ca joli ! :P






Mais trouver les points successifs n'est pas suffisant pour pouvoir dessiner la courbe ... Je suis alors tombé sur l'article de Thimothee Groleau sur la tranformation d'un courbe cubique (quatre points de contrôle) en une courbe quadatrique (trois points de contrôle) : http://www.timotheegroleau.com/Flash/articles/cubic_bezier/cubic_bezier_in_flash.htm. Je ne l'ai pas encore étudié a fond, mais je vais voir s'il est possible de le généraliser à un nombre n de points de contrôles ...

::Télécharger Bezier.zip::

19 commentaires

lundi, septembre 29 2003

PathFinding et Arbres binaires ... pas mieux !

Par -Alexandre LEGOUT aka LAlex- le lundi, septembre 29 2003, 18:53

Comme le préconise Patrick Lester dans son article Using Binary Heaps in A* Pathfinding, j'ai implémenté le gestion de la liste ouverte sous forme d'arbre binaire (binary heap) que l'on conserve trié en permanence pour ne pas avoir à chercher la case ayant le cout minimum en bouclant sur la liste ouverte. Et bien dans l'état actuel des choses, ce n'est pas plus performant !!! :(

Pourtant, de ce que j'en ai compris, cela devrait aller beaucoup plus vite ! 8O Mais une petite surveillance su temps pris par chaque étape de la recherche indique que cette boucle sur la liste ouverte n'est pas ce qu'il y a de plus lent ... et en plus, chaque fonction indépendemment prend moins de 1ms., donc impossible de tracer le temps ... :?

Voila donc un exemple qui fait la comparation des deux méthodes sur chaque fois le même trajet. La carte est de dimensiosn 30x30 pour tester sur un peu plus grand que précédemment. Vous pouvez aussi télécharger le fichier source de la classe PathFinder.as ... si vous découvrez une explication, n'hésitez pas à me faire signe ! ;) L'activation des arbres binaires se fait avec la variable statique BINARY_HEAPS qui est un booléen.

::Télécharger pathfinder.zip::

9 commentaires

vendredi, septembre 26 2003

Sources du moteur 3D ActionScript 2 beta

Par -Alexandre LEGOUT aka LAlex- le vendredi, septembre 26 2003, 16:33

Voici la version beta téléchargeable sous forme d'API du moteur 3D AS2 que je vous ai montré récemment (qui était une version alpha). Pourquoi une version beta ? Petit rappel : une version alpha ne possède pas toutes les fonctionnalités, alors qu'une version beta possède toutes les fonctionnalités, mais elles peuvent être buguées (ce qui est le cas ici :P)...

L'API possède donc maintenant les fonctionnalités de remplissage des faces et leur éclairage. Dans l'interface graphique, vous pouvez maintenant déplacer la lumière ... 8)

Le bug porte en fait sur sur le tri des facettes de la plus éloignée à la plus proche de la caméra, tri qui n'est pas foncièrement bon, mais pas forcément mauvais, c'est à dire qu'il fonctionne une fois sur deux, car si dans la même position je fais deux fois le rendu, une fois le tri est bon, une fois il ne l'est pas ... :(. Je n'arrive d'ailleurs pas à comprendre pourquoi ... alors si un cador de la programmation 3D pouvait se pencher sur ce code, ce serait super sympa ... :D J'utilise l'algorithme du peintre, qui consiste simplement à trier les profondeurs moyennes de chaque face et de s'en servir pour le tri ...

Les packages nécessaires sont inclus dans l'archive. La classe "de base" est la classe Shape, qui est la classe représentant un objet 3D, avec ses vertex, arrêtes et faces.

Les fonctionnalités à venir :

  • Gestion de la distance par rapport ) la lumière
  • Gestion de l'intensité et de la distance des lumières
  • Utilisation des BSP Trees
  • Test de remplissage avec des dégradés (simulation du remplissage de Gouraud)
  • Debugage ... :?






::Télécharger api3d.zip::

17 commentaires

mardi, septembre 23 2003

Premier apercu de moteur 3D en AS2

Par -Alexandre LEGOUT aka LAlex- le mardi, septembre 23 2003, 12:35

Voici un premier apercu de mon moteur 3D recodé (et non pas traduit) en ActionScript 2. Le moteur en lui-même est pratiquement fini : il ne manque plus que la gestion de faces et de la lumière. Je n'ai pas non plus implémenté le "non-affichage" des arretes et points situés en dehors de la zone d'affichage ou derrière la caméra, d'ou quelque bugs graphiques quand l'objet ne devrait pas être visible ...

Des questions se posent sur les performances d'un tel moteur : l'implémentation objet d'un moteur 3D peut-elle être une solution viable pour Flash ? Ou faut-il obligatoirement passer par du spécifique ou du flasm pour avoir des perfomrances honorables ? L'optimisation du bytecode dans le Flash Player 7 est encourageante, mais est-ce suffisant pour ce type d'applications ? La question se pose, et si vous avez la réponse, je suis preneur !!! :D

L'interface de l'éditeur est loin d'être finie, autant en terme de fonctionnalités qu'en terme d'ergonomie et de visuel ... mais je vous montre ici ses fonctionnalités de base :







9 commentaires

vendredi, septembre 19 2003

PathFinder an ActionScript 2 : les sources

Par -Alexandre LEGOUT aka LAlex- le vendredi, septembre 19 2003, 13:01







Comme promis voici les sources de mon pathfinder. Il a été adapté pour être a peu prés correct avec l'interactivité que je voulais, mais il s'inscrit dans un cadre plus grand de moteur de jeu, donc tout seul, il perd un peu de sa rigueur ... :?

Vous pouvez donc maintenant cliquer sur la carte pour tester votre propre chemin, et choisir de ne pas faire de diagonales, ou de pouvoir faire une diagonale lorsque vous êtes au coin d'un mur (ce qui est déconseillé dans le cadre d'un moteur de jeu) ...

Vous trouverez dans l'archive une fichier flp (Projets Flash) qui vous donnera accés à tout le reste. Le pathfinder en lui-même se situe dans la classe map.Map et j'ai essayé de le commenter assez correctement, mais il restera assez flou si vous n'avez pas integré les notions du pathfinding A* ...

En ce qui concerne la 3D iso, je commence a peine à apréhender, donc tout n'est peut-être pas correct dans la manière d'organiser mon affichage. En fait, je voudrais bien savoir comment font les gens qui utilisent un moteur 3D iso pour leur affichage. Passent-ils pas des clips exportés de la librairie, ou utilisent-ils un autre moyen ? :roll:

Voila, amusez vous bien avec ce code !!! 8)

::Télécharger LAlexPath.zip::

petepx a également fait un pathfinder, qui est le portage de celui d'André Michelle en AS2. Plus d'infos sur son blog

14 commentaires

vendredi, septembre 12 2003

Pathfinding : mise en pratique avec ActionScript 2

Par -Alexandre LEGOUT aka LAlex- le vendredi, septembre 12 2003, 18:17

Voici ma première implémentation faite avec Flash MX 2004. Il s'agit de l'algorithme de pathfinding dont je vous ai parlé précédemment. Maintenant entièrement en AS2, il se contente pour l'instant de générer un carte aléatoire.

Je compte rejouter de l'interactivité bientôt (pouvoir choisir un chemin), ainsi qu'un éditeur de carte (ca c'est peut-être pas pour tout de suite). Pour information, les cases "normales" ont un cout de 10, le cases en orange (sableà ont un cout de 12. C'est pourquoi selon que cela vaille le coût de contourner ou pas, le chamin peut passer ou ne pas passer par des cases oranges. Lorsqu'il sera un peu plus complet, je mettrai les sources à disposition.

10 commentaires

vendredi, août 29 2003

Pathfinding : ca avance, et en 3D isométrique !

Par -Alexandre LEGOUT aka LAlex- le vendredi, août 29 2003, 12:43


J'avance bien sur mon algo de pathfinding. En fait, j'avais fait un peu n'importe quoi dans ma première implémentation (mal compris l'explication de l'algo en anglais), et là j'ai tout repris en me basant sur l'implémentation de zeh (voir lien plus bas). Sans reprendre son algo, cela m'a permi de mieux le cerner, et de pouvoir l'implementer correctement. En fait, ce qui change par rapport au sien, ce que mon implémentation est faite en POO, alors que la sienne est une "simple" fonction, qui prend un tableau à deux dimensions en paramètre.

La structure de mes classes est en fait assez simple : une classe 'Map', qui contient la méthodes findPath, et qui prend en paramètre les coordonnées de départ et d'arrivée. Une classe 'Tile', qui constitue la base de chaque élément de la carte, et qui est étendue par des classes 'Wall', 'Floor', 'Sand', etc... qui vont représenter les différents type de terrain.

Apparemment, il est assez optimisé (j'en ai d'ailleurs profité pour suggérer quelques mini-optimisations à l'auteur du pathfinding précédemment cité), et j'arrive à obtenir des performances trés légerement meilleures, alors que tout est codé en objet : je n'en revient pas moi-même !!! En fait, de par l'implémentation objet et l'utilisation des "pointeurs" de Flash (utilisation des références et non pas des valeurs), j'arrive à éviter certaines boucles... Par contre, le temps que vous voyez affiché sur l'image est pour le Flash Player 7 (beta v7.0.2.0), qui est bien plus rapide que le 6 ...
J'en ai profité pour créer une méthode d'affichage en 3D isométrique, parce que je trouve ca plus joli ... ;-)

Dés la sortie de Flash MX 2004, je le refait en ActionScript 2, et je mettrai les sources à disposition ici-même !
Je pense également faire prochainement une explication en français de l'algorithme A* pour le pathfinding, basé sur ce que j'en ai compris, et axé sur la pédagogie pour le mettre à la portée du plus grand nombre.

15 commentaires

lundi, août 25 2003

Implémentation du pathfinding en Flash

Par -Alexandre LEGOUT aka LAlex- le lundi, août 25 2003, 11:46

J'ai essayé d'implémenter l'algorithme de pathfinding A* dans Flash, à l'aide du lien donné dans un post précédent.

Pour optimiser un peu, au lieu de créer des "listes" pour les 'open list' et 'close list', j'ai créé des tableaux à deux dimensions de même taille que la carte, ainsi accessibles directement par les coordonnées correspondantes au point de la carte que l'on utilise.Par contre, je n'ai pas implémenté le contour des murs, ce qui fait qu'on peut passer en diagonale de la case [ 2 ] à la [ 3 ], et de la [ 3 ] à la [ 4 ]. Vous voyez ici le visuel qui en résulte.

Mais le problème n'est pas la : j'ai fait en sorte que les déplacements en diagonale soient plus couteux que ceux en ligne droite (multipliés par 1.4), et j'ai intégré une notion de cout selon la nature du terrain (les cases vertes ont un coût de 10, et la case jaune un coût de 15). Vous constatez donc que le chemin emprunté n'est pas le bon ... mais pourquoi ?
En fait, l'algorithme A* fait une recherche dans les cases autour de la case en cours, et garde celle qui a le cout "total" le plus petit ("cout total" = "cout de parcour" + "cout restant à parcourir" : voir le lien avec l'algo). Or, dans ce cas précis, la case [ 2 ] et la case [ 2' ] ont le même coût, et le choix dépend donc de la comparaison faite lors du choix du minimum : soit un utilise '<' (strictement inférieur), soit on utilise '<=' (inférieur ou égal). Bref, dans les deux cas, il faut en choisir une, sans savoir s'il s'agit de la bonne ou pas.

Donc, je pense qu'il faut garder dans l'algorithme toutes les cases qui ont un coût minimum pour effectuer la recherche, et donc éliminer moins de cases, ce qui va évidemment se ressentir dans les performances ... :'(

6 commentaires

vendredi, août 8 2003

Une autre GUI en Flash

Par -Alexandre LEGOUT aka LAlex- le vendredi, août 8 2003, 12:09

Voici une GUI Flash nommée flui : http://clearsoftware.net. Ca a l'air bien fait, mais je suis un peu décu par le manque d'informations techniques pour les développeurs... Elle reste toutefois OpenSource et gratuite pour une utilisation à but non lucratif.

aucun commentaire

Une source d'inspiration pour la GUI

Par -Alexandre LEGOUT aka LAlex- le vendredi, août 8 2003, 10:28

Ce schema de classes est celui utilidé par gskinner pour son FlashOS.
Il représente une bonne source d'inspiration pour la création de ma GUI. Je compte aussi m'inspirer des classes SWING de Java, des MFC de Microsoft et du DOM Javascript.
Attention ! Le schema complet est grand (1440 x 1081) et pèse prés de 160 Ko ...

[ Voir le schema ]

un commentaire

mardi, août 5 2003

Schema de la GUI

Par -Alexandre LEGOUT aka LAlex- le mardi, août 5 2003, 00:00

Voici le schema que j'ai fait pour la constitution de mes classes. Bon, j'ai oublié les menus, mais faites preuve d'imagination un peu !!! :-D

Ma méthode de développement est basée sur la programmation évenementielle.
Elle consiste à concevoir mon modéle de classes, puis a savoir pour chacune d'elle quels sont les évenements qu'elles vont émettre.

  • En fonction de cela, je crée les méthodes qui vont émettre ces évenements.
  • Ensuite, je crée les méthodes "privées"
  • Pour "finir" je crée les méthodes d'entrée/sortie (get/set)

aucun commentaire

Packages et classes

Par -Alexandre LEGOUT aka LAlex- le mardi, août 5 2003, 00:00

[ lalex.gui ]
Window
WindowManager
[ lalex.gui.win ]
$Element
TitleBar :: $Element
StatusBar :: $Element
ContextBar :: $Element
[ lalex.gui.scroll ]
$ScrollBar :: $Element
VScrollBar :: $ScrollBar
HScrollBar :: $ScrollBar
[ lalex.gui.menu ]
MenuBar :: $Element
MenuItem
[ lalex.gui.content ]
$Container
SwfContainer :: $Container
TextContainer :: $Container
TextFileContainer :: TextContainer
ListContainer :: $Container
XMLListContainer :: ListContainer
TreeContainer :: ListContainer
XMLTreeContainer :: TreeContainer
[ lalex.gui.dialog ]
$DialogBox
MessageBox :: $DialogBox
PromptBox :: $DialogBox

Légende : Les classes en italique précédées d'un '$' ne sont pas destinées à être instanciées (Interfaces ou classes virtuelles)

aucun commentaire