SVN repository

J'ai ajouté un repository subversion pour SPARK sur sourceforge.
Voila le lien : https://sparkengine.svn.sourceforge.net/svnroot/sparkengine/
Tout le monde peut contribuer (vous avez seulement besoin d'un compte sur sourceforge et de m'envoyer votre username par mp)

Bonne idée !

Faudrait peut etre un readme à coté des dossiers principaux pour quelques infos importantes, comme la licence, l'auteur, les contributeurs, l'organisation du svn, etc...

Sinon, c'est sur Sourceforge, est-ce qu'il y a des trackers ?

tout le monde, je trouve ça un peu dangereux, ça risque de devenir un sacré bazar si chacun fait sa modif dans son coin sans pouvoir le contacter en cas de problème

ps: ha bah non, on peut pas envoyer sur le serveur sans authentification.

oui tout le monde, mais il faut que vous ayez un compte sourceforge avant et que je vous ajoute pour pouvoir commiter sur le svn

Sinon Darktib quand tu parles de trackers, un bug tracker ? Je pense que tout cela est activé par défaut sur sourceforge mais je comptais a la base me servir de source forge uniquement pour le repository.

il faut que je te donne quoi pour que tu puisses m'ajouter?

ton identifiant sur sourceforge

en message privé

Je peux te donner le mien aussi ?

je t'ai envoyé un mp Darktib mais t'as pas du le voir

Dsl
C'est fait.

J'ai un script permettant de générer automatiquement la doc (html et chm) avec doxygen, puis-je le poster sur le svn ? En passant, je peut aussi rajouter les lignes en plus pour mingw.

moi aussi j'ai un fichier pour doxygen qui me genere la doc mais comme les chemins sont en absolu, il est pas vraiment utilisable sur un autre pc. Mais si toi tu as des chemins relatifs, vas y pose le.

Pour les lignes, c'est marrant moi mon mingw me fait pas de warning. Normalement je rajoute toujours une ligne vide en fin de fichier. Mais vas y rajoute une ligne la ou il en manque si tu as des warnings.

Plusieurs choses:
1/ GCC me conseille de rajouter des parenthèses autour des éléments arithmétiques dans les lignes du type (ds SPK_AABox.h):

Code:

firstAxis = firstAxis & 0xF0 | axis & 0x0F

Je précise qu'avec Qt 4.6, c'est gcc 4.4.0 qui est utilisé (et plus le 3.4.5 de Code::Blocks ou des précédentes versions de Qt)

2/J'aimerais bien avoir des retours sur le script de génération de l'aide (mon tout premier commit de ma vie^^)...

3/ l'éditeur avance, mais les modèles ne seront pas prets ce week-end

edit: j'ai mis à jour et j'ai vu que tu as déplacé les dossiers de l'aide, et que tu avais enlevé la possibilité de compiler le chm. Au minimum, il faudrait laisser activé cette option, ca permettrait de générer les fichiers projets et index, sans forcément générer le *.chm si hhc.exe n'est pas trouvé. Le chm est très pratique dans beaucoup de cas, et générer tous les fichiers de projet et d'index à la main est infaisable.

dernier edit: il manque des fonctions aux interpolateurs:

• removeEntry( float X ) // pour supprimer une entrée
  
• changeEntry( float X, float y0, float y1 ) // pour modifier une entrée
  

Il est possible d'effectuer ces opérations actuellement, mais ca oblige à nettoyer l'interpolateur puis à le re-remplir avec des entrées préalablement sauvegardées - autrement, une sacrée perte de temps...

Salut. Désolé je n'avais pas accès a internet ces derniers jours :

Pour te répondre :

1. Oui c'est juste un warning pour la lisibilité concernant la priorité des opérateurs
   
2. Oui j'ai modifié le script de génération d'aide en passant a la derniere version de doxygen et pour que l'aide générée ressemnle a celle d'avant. La génération du chm a été supprimé sans faire expres, tu peux la rajouter
   
3. Pour les interpolateurs, je vais rajouter ces fonctions. Dans le cadre d'un éditeur c'est en effet très utile.
   

Ok, je vais faire un commit avec des opérateurs comme ceci:

Code:

firstAxis = (firstAxis & 0xF0) | (axis & 0x0F)

Sinon je déconseille d'enlever les commentaires du fichier cfg de doxygen : c'est pas pratique pour les nouveaux qui ne connaissent pas doxygen, et pour des raisons d'encodage tout coller peut mener à des comportements bizarres (par exemple il refusait de générer le chm car il n'arrivait pas à lire le chemin du compilo chm, juste à cause d'un retour à la ligne bizzaroïde... c'est reglé maintenant.

Merci pour les fonctions des interpolateurs.

Pour le fichier de config doxygen, en fait je suis repartie de ma version d avant directement généré par le wizard doxygen, du coup non commenté. Mais c'est vrai que j'aurais du gardé la version commentée.

Pour les méthodes des interpolateurs. En fait tu as la possibilité de récupérer le set d'interpolatorEntry en non constant (getGraph()). Donc tu peux faire toutes les opérations que tu veux dessus. C'est un peu plus lourd mais en même temps ce sont des méthodes pas forcément très utiles. Donc autant ne pas trop alourdir l'interface pour l'instant et passer par la.

Je ne pense pas que deux fonctions en plus alourdiraient beaucoup l'interface^^

Enfin merci pour le tip, je fais ça dès que j'aurais réglé le bug que je corrige actuellement.

oui c'est sur c'est pas 2 méthodes qui vont alourdir l interface. Mais je parlais plus dans le cas général : je préfère conserver des méthodes pour réaliser les actions usuels et rajouter une méthode pour accéder a la structure plus bas niveau (getGraph) pour permettre les actions qui sortent plus de l'ordinaire plutot que de rajouter pleins de méthodes pour réaliser ces actions inhabituelles.

Hop, j'ajoute deux zones pratiques : l'union et l'intersection de zones. Les méthodes comme computeNormal et moveToBorder sont un peu foireuses...

Il manque encore une zone: soustraction (A \ B).

Salut,

le probleme c'est que ca ne va pas marcher pour tous les tests (genre l'intersection ou le calcul de la normal). Par contre ca va bien marcher pour la génération ou la contenance. Enfin je regarderai ca quand j'aurai le temps.

En effet - c'est un problème qui est d'ailleurs indiqué dans les headers.

A ce propos, comment SPARK utilise t-il les tests?

Il me semble que la version 1 n'est plus supportée, donc j'ajoute une fonctionnalité qui me manquait beaucoup : le changement de modèle dans un groupe.

Au niveau des changements, il n'y a que la fonction setModel qui apparait dans l'interface des groupes, avec la doc. Le changement de modèle 'vide' le groupe; de plus l'opération n'est pas super rapide (il faut tout remettre proprement), donc a ne pas faire toutes les frames^^
La fonction ne change pas de modèle si on lui file le même modèle que celui du groupe. Si on lui passe 0, le modèle par défaut est utilisé.

J'ai fait un petit exemple (qui ne compilera qu'avec la dernière svn, càd la 136, trunk - mais les binaires sont inclus dans le pack), deux modèles différents switchent toutes les 9.4 secondes (le chiffre dans le code est au pif...), c'est pour voir ce que ca donne (au passage j'ai fait mumuse avec les modifiers^^):
ici: http://www.mediafire.com/?tzwi0imzyll

Au niveau de l'exemple, il n'est pas très clean, il y a deux fuites mémoire que je n'ai pas corrigées (les modèles ne sont pas supprimés à la fin de l'exemple).

Dites moi ce que vous en pensez.

Ok. J'ai juste corrigé un petit bug : il n'y avait pas d'update du compteur de références des modeles. Sinon il y a une partie du code qui est sans doute pas utile et qui peut être remplacé par un pool.clear je pense. Enfin j'ai laissé tel quel pour l'instant.

Pour la version 1, elle est toujours maintenue mais je ne rajoute pas de fonctionalité, juste des bug fix.

A part ca, l'exemple qui utilise le vortex est très joli !

Juff wrote:

J'ai juste corrigé un petit bug : il n'y avait pas d'update du compteur de références des modeles.

Merci, j'avais oublié ca.

Pour l'appel à pool.clear(), en effet j'ai testé et ca fonctionne aussi, je met les modifs sur le svn. C'est beaucoup plus rapide maintenant.

Juff wrote:

A part ca, l'exemple qui utilise le vortex est très joli !

Merci!
Je pense qu'en mixant les deux (couleurs + tailles) ca le serait encore plus... mais ca sera pour une prochaine fois^^

Concernant tes modifs sur le svn Darktib :

• Pour le vortex je valide, ta méthode est plus élégante. J'ai fait une passe dessus pour optimiser (normalisations/tests pas nécessaire, création de vecteurs...). D'ailleurs ca m'a permis de me rendre compte que le sens de rotation était à l'envers.
  
• Pour la fraction de l'emetteur, tu as raison pour le bug mais ta méthode a des effets de bords (regarde ce qu'il se passe avec un flow très petit...). Du coup j'ai reverté et juste mis un test pour fixer le bug sans effets de bords
  

Merci pour tes contributions en tout cas