Discussion :

[koala01]

Pour ce qui est de la SFML, elle génère automatiquement le script findSFML pour cmake (et l'installe normalement au bon endroit ) lorsque tu le compile depuis les sources

De plus, je viens de vérifier une des archives déjà compilée : dans le dossier lib, tu as un sous dossier nommé cmake qui contient un autre dossier nommé SFML. Ce dossier SFML contient l'ensemble des scripts de configuration utilisés par find_package.

Tu devrais, a priori, devoir te contenter de copier ces fichiers dans un dossier cmake et ajouter ce sous dossier à la variable CMAKE_MODULE_PATH

Après, histoire de remettre les choses dans leur contexte, une fois que l'on a mis les mains dedans, est-ce vraiment indispensable de passer par CMake ? Enfin, je veux dire, à l'utilisation, y gagne t-on vraiment en terme de convivialité de gestion des projets par rapport au projet standard configuré depuis l'IDE ? Les dev en mode projet passent vraiment 2 semaines à faire leurs CMake à chaque fois comme moi (et encore, il me reste pas mal de boulot à ce niveau là ^^) ?

On y gagne, pas forcément, en convivialité, mais on y gagne très certainement en "liberté de mouvement".

Car tous les EDI gèrent leurs projets à "leur propre sauce" : les fichiers de description de projet de VisualStudio n'ont rien à voir avec ceux de Code::Blocks, de eclipse ou de QtCreator

Or, si tu veux essayer de compiler ton projet avec plusieurs compilateurs, sur plusieurs systèmes ou avec différents EDI, il deviendra rapidement très difficile de garder l'ensemble des projets à jour, lorsque tu décidera de rajouter un fichier ou un autre.

Pour avoir travaillé sur un projet qu était développé à la fois avec VisualStudio et avec QtCretaor (sans utiliser CMake), je peux te garantir que rien que cela devient rapidement l'horreur

Avoir un outil qui puisse "transcender" l'utilisation des EDI pour te laisser choisir celui que tu veux, tout en évitant d'avoir à "refaire le travail" trente-six fois, cela peut représenter un avantage certain, non

Je continue à faire mes *.txt au lieu du c++. Je dois arriver à mettre en place mon architecture projet.

Il n'y a rien à faire : dés le moment où tu dépasse le stade d'un projet composé d'un seul fichier, il est temps de décider de l'organisation de ton projet, et de mettre en place "ce qu'il faut" pour qu'elle puisse prendre du sens

Le premier projet est toujours le plus difficile à mettre en place, que ce soit en terme d'arborescence, ou en termes d'utilisation des outils que tu décides d'utiliser. Mais ne t'en fais pas : on s'y fait très rapidement ;-)

[BioKore]

Bon... Je me fais petit à petit à utiliser CMake. Encore pas mal de temps avant de pouvoir dire que je suis à l'aise avec ça mais bon.

Par contre, pour SFML, effectivement, il n'y a plus de fichier FindSFML mais un SFMLConfig dont je n'arrive toujours pas à trouver les leviers (comme quoi les composants que je demande n'existent pas alors que je fais tout ce qui est écrit dans la doc). Bref... Je ne m'y suis pas plus penché dessus que ça non plus je trouverais bien quand ça me deviendra indispensable. bientôt je l'espère, mais je peux faire encore pas mal de trucs sans ça.

Bref, pour en revenir au sujet, je n'en suis pas encore aux 5M particules non plus. Et je dois mettre en place un système d’événements...
En ce qui concerne le système de Signaux / slots, je vais voir la méthode proposée dans ton implémentation, mais je tiens à faire ma propre implémentation (même si elle doit finalement ressembler à ce que tu as fait).


Petit aparté lié à une simple curiosité personnelle, je me suis aperçu d'un fait "étrange", c'est que la fonction std::swap est plus rapide qu'une fonction du type :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
template<typename T>
void swap(T & src, T & dst) {
	T tmp{src};
	src = dst;
	dst = tmp;
}

Si le code avait été plus complexe, je dirais pas, mais là... Je ne comprends pas. Une idée de la manière dont opère std::swap ? J'imagine que c'est T tmp{src}; qui plombe tout dans la fonction proposée, mais je ne vois pas trop comment faire autrement... J'ai bien entendu essayé de faire la même chose en employant directement des pointeurs, mais, comme attendu, le résultat est similaire.

[Bousk]

std::swap peut avoir des optimisations pour certains types, utiliser des intrinsecs, ...
Ton truc fait 3 copies
Quitte à vouloir refaire un swap, autant au moins utiliser des move...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
template<class T>
void swap(T& l, T& r)
{
  T tmp{std::move(r)};
  r = std::move(l);
  l = std::move(tmp);
}

[BioKore]

Ok ! Merci pour cette explication.
Jusqu'à présent, je n'ai jamais utilisé std::move ; je vais voir comment ça fonctionne.

Merci !

[BioKore]

Ok ! J'ai enfin réussi à tout faire fonctionner avec CMake un peu comme je le veux.
J'ai pu tout refactoriser et faire fonctionner le tout incluant SFML... Ça, c'est fait !
Je vais mettre à jour le Git avec ça.

Niveau performances, j'ai réussi à faire un peu mieux aussi. Je fais tourner 3'000'000 de particules à 60 FPS (61 FPS pour être précis). Cependant, pour y arriver, j'ai dû concaténer deux composants : les vertex et les données de vitesse. Cependant, bien que cela marche plutôt bien dans mon cas, ce n'est pas viable si je souhaite faire quelque chose de plus complet (avec gestion des collisions par exemple ? ou simplement donner un objectif à mes particules...) car si je souhaite plus tard faire d'autres types d'entités je vais devoir séparer les données de mes composants et c'est là où je perds énormément en performances. Par exemple, si je sépare le sf::vertex du composant de vitesses, je retombe à moins de 60 FPS pour 1'500'000 particules !!
En fait, il faudrait pouvoir concaténer les composants dynamiquement en un seul à chaque fois que l'on en enlève ou ajoute, et donner cet agglomérat aux systèmes plutôt que de lui dire d'aller les chercher un par un. Je ne sais pas trop si mon idée est viable, mais là, à froid, c'est la première qui me vient... Mais je dois trouver quelque chose permettant de conserver les systèmes modulaires...

Bref... A suivre.

GIT Modifié : ici --> ne contient que l'ECS et non la partie "particules". Je l'ajouterais dès que j'aurais trouvé le moyen d'éviter d’inonder mes dossiers de développement avec des fichiers tiers (CMake + CLion m'ajoutent déjà pas mal de dossiers et de fichiers un peu comme ils veulent en plus des lists alors bon...)

[r0d]

Salut,

je n'ai pas tout lu, alors ce que je vais dire a peut-être déjà été dit.
Mais il n'y a pas de secret sur un ECS : si tu veux avoir de bonnes performances, il te faut utiliser les threads au maximum, ce qui signifie une architecture qui s'y prête. C'est à dire que les données soient stockées dans des tableau indépendants (pour faciliter la parallélisation) c'est à dire qu'il faut oublier la POO là. Et puis il faut que tes jobs qui traitent tes tableaux puissent optimiser la cache proc (travailler sur une page idéalement, avec un minimum de swap), donc utiliser des types petits dans tes tableaux. Par exemple, il faut mieux 3 tableaux de int que un tableau de int[3].

Après tu peux aller chercher les derniers fps au cure-dent, mais avec une bonne structure "data oriented" et surtout, une bonne gestion des jobs, c'est avec une pelleteuse que tu vas travailler.

[BioKore]

Merci r0d pour ces quelques précisions. Effectivement, je ne me suis pas encore lancé dans l'exercice du theading, mon but étant, dans un premier temps, d'avoir une base solide.
Ce que tu dis est intéressant concernant la taille des objets (composants). Aussi j'ai bien compris que, pour minimiser les cache miss au maximum, il est nécessaire de remplir les cache line d'autant de composants que nécessaire (dans mon cas, une cache line = 64Kb, a savoir maintenant si dans mon cas, 1 byte = 1 octet, je n'en suis pas certain à 100%) . Cependant, minimiser la taille des composants veux dire augmenter le nombre d'interfaces entre eux. Ce que je veux dire par là, c'est que, de ce que j'observe, dans mon cas précis :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
// CAS 1 
 
struct Position {
	float x{.0f},
		 y{.0f};
};
 
ComponentPool<Position> positions;
 
struct Color {
	uint8_t r{0},
		g{0},
		b{0},
		a{255};
};
 
ComponentPool<Color> colors;
 
 
void update() {
	for(auto & a:positions) {
		if(colors.exit(a.id)) {
			// do something
		}
	}
}
 
 
// CAS 2 
struct Vertex {
	namespace position {
		float x{.0f},
		       y{.0f};
	}
 
	namespace color {
		uint8_t r{0},
			g{0},
			b{0},
			a{255};
	}
};
 
ComponentPool<Vertex> vertices;
 
void update() {
	for(auto & a:vertices) {
		// do something
	}
}

Dans le cas 2, j'optimise de facilement 100% les performances par rapport au cas 1 ; et cela se comprends facilement. Toutes fois, quelques soient nos intentions, nous serons toujours confrontés à un moment ou à un autre, au cas 1 pour le fonctionnement de certains systèmes. Et c'est ce point que je cherche à optimiser pour le moment. J'ai encore pas mal de choses à apprendre et je ne suis pas certain que l'utilisation de threads soit la solution la plus appropriée pour répondre au cas présenté ci-dessus... Mais ça, c'est moi qui le dit. Peut-être est-ce dès maintenant que je doive m'intéresser aux threads ? Si tel est le cas, mes vacances n'en seront plus vraiment

Merci encore.