Salut tout le monde

Ok j'ai laissé le loup garou de côté mais le problème d'entrée/sortie non bloquante qui nécessite d'apprendre les threads m'a un peu refroidi donc j'y reviendrai plus tard

J'ai commencé à penser à un nouveau projet. Sauf que cette fois-ci je compte bien finir de le modéliser avant de le coder. Ça m'évitera de perdre du temps inutilement par la suite. Cependant, le gros problème c'est que je n'ai pas un assez bon esprit critique sur ma modélisation. Je sais qu'il y a plein de diagrammes UML mais le seul que j'ai réellement compris est le diagramme de classe (bien qu'il me pose problème car je ne vois pas où mettre les fonctions qui ne font pas partie d'une classe ).

Bref, il est loin d'être terminé mais j'aimerai juste avoir un avis genre :

• Pour le moment, il n'y a pas de gros problèmes. Il faut que tu continues de travailler dessus ;
• Attention, tu n'as rien compris et tu fonces droit dans le mur.

Bon, ce ne sera sans doute pas aussi tranché que ça . Je compte mettre à jour ce poste pour expliquer plus en profondeur mon projet comme j'ai commencé à le faire sur mon blog.

Pour le moment, voici mon diagramme de classe :

-
Edité par Alexandre Gérault 18 janvier 2018 à 0:07:52

C'est du top-down ou du down-top ?

Parce que moi, je vois juste 2/3 trucs qui se battent en duel avec si peu d'interaction qu'il ne peut avoir de problème.

addProperty/changeProperty avec un typage faible bien pourri.

Commencez par découper les fonctionnalités en Module : Rendering | Physique | Network | etc...

Pour un moteur de jeu, renseignez-vous sur le concept d'ECS, puis utilisez un moteur de jeu avant de réinventer une roue carrée.

Je ne cherche pas du tout à faire un moteur de jeu...

J'ai imaginé le logiciel découpé en plusieurs modules :

• Module IHM ;
• Module de rendering ;
• Module physique.

Pas besoin de module de réseau.

Pour les propriétés, il s'agit d'un simulateur de mécanique (du point) donc je vois ça comme une map <string, double>. Le typage est donc bien défini.

Pour le moment, on me pose tellement de questions sur les calculs que j'effectue que je me suis penché plus en détails dessus. En effet, j'ai un écart entre la solution analytique et la solution numérique qui est assez frappant ainsi que aberration intrigante. Je l'ai remarqué en réalisant un exemple simple de simulation sous Python...

Bref, pour en revenir à la conception de ce logiciel, c'était de savoir si ce n'était pas déjà une erreur de conception d'avoir un module "métier" (physique), un module de rendu et un module d'interface homme/machine. Également, est-ce qu'un point n'est pas mieux représenter par une structure que par un point etc

Généralement l'IHM et le "rendering" sont très liés et donc dans le même module.

>Le typage est donc bien défini.

Ok, alors votre typage est "défini" mais extrêmement "lâche", cela ne simplifie pas la conception et l'utilisation du code car vous ne disposerez plus du typage fort qu'offre le C++.

Si vous voulez un typage dynamique, le C++ n'est pas vraiment le choix le plus optimal.

>j'ai un écart entre la solution analytique et la solution numérique qui est assez frappant

Rien de très étonnant, dans un ordinateur, les erreurs d'approximation sont systématiques avec les nombres à virgules flottantes.

Il faut faire attention et utiliser les bons algorithmes pour les évaluer et les minimiser.

> c'était de savoir si ce n'était pas déjà une erreur de conception d'avoir un...

Non. Mais j'ai du mal à voir la frontière entre IHM et rendu.

>Également, est-ce qu'un point n'est pas mieux représenter par une structure que par un point etc

C'est quoi un "point" pour vous ? Un objet avec 2 champs ?

En C++, structure et classe, c'est quasiment la même chose.

Utilisez les outils les plus adaptés à l'usage que vous voulez en faire, quitte à en changer après.

La modularité permet de changer des trucs s'en avoir à tout changer.

Pour moi, l'interface homme machine est un module qui permet à l'utilisateur d'entrer des commandes afin d’interagir avec le contenu du programme. Par exemple create body <name> to <experience_name> ou bien set <body_name> mass <double_value>. Il devrait également permettre d'automatiser tout ça en chargeant un fichier (format indéterminé) dans lequel ces lignes sont déjà enregistrées.

Ensuite, pour mon typage, je ne vois pas où il est "lâche" car comme je l'ai dit, à chaque propriété est associé un std::string servant de clé et une variable numérique de type double servant d'élément.

Ensuite, oui, je sais bien qu'il y a des erreurs dûes à l'approximation mais l'aberration vient sans doute d'une erreur de calcul car, croyez-moi, elle n'a aucun sens physique. Sinon, pour un lancer simple sans frottements, la courbe est très fidèle à la solution analytique.

Je vous remercie pour votre attention.

-
Edité par Alexandre Gérault 23 janvier 2018 à 20:31:30

> l'interface homme machine est un module qui permet à l'utilisateur d'entrer des commandes afin d’interagir avec le contenu du programme.

C'est un peu restreint comme définition. Des fenêtres avec des menus déroulants, des menus contextuels, des boutons, des raccourcis claviers etc... sont très souvent des IHM, et le "rendering" n'est que l'affichage actuel du model interne via une simple fenêtre dans l'IHM.

Les commandes, c'est pas de l'IHM, faire une interface console où l'on peut y mettre ces commandes, c'est une IHM.

Ne confondez pas les commandes et l'IHM. Il est facile de faire une interface graphique qui génère ces commandes, aussi bien qu'une console.

L'exemple du fichier montre bien que les commandes n'ont rien à voir avec l'IHM. Les fichiers, c'est dans une couche de persistance/Data, pas de l'IHM et pourtant les commandes y sont utilisées.

Ces commandes sont en fait les services offerts par votre module "model".

Vous aurez un module qui lit un fichier et qui convertit les lignes du fichier en commandes au module "model".

Vous aurez un module qui lit les entrés clavier sur la console et qui les convertira en commandes au module "model".

Vous aurez un module de GUI qui génèrera des commandes en fonction des actions de l'utilisateur dans l'IHM.

etc...

>pour mon typage, je ne vois pas où il est "lâche"

Vous allez modéliser comment les degrés de liberté de certain type de jonction/lien physique juste avec cette map ?

Comment vous allez simuler un champs de gravité VECTORIEL avec juste des doubles ?

etc...

C'est pas infaisable, c'est juste méga-galère.

>elle n'a aucun sens physique

C'est des erreurs d'arrondie et d'optimisation, il n'y a absolument rien de "physique" ni même de "logique" dans ces erreurs.

Vous devez utiliser correctement les algorithmes pour borner leurs effets.

>Sinon, pour un lancer simple sans frottements, la courbe est très fidèle à la solution analytique.

Si vous utilisez une approche itérative, c'est tout à fait normale, car les erreurs s'accumulent très très vite.