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
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
| typedef int Object;
struct Game {
struct Data {
std::unordered_map<Object, vec2> positions;
std::unordered_map<Object, vec2> velocities;
std::unordered_map<Object, vec2> accelerations;
std::unordered_map<Object, mat3> transformations;
};
Data data;
Physics p;
RandomIA ia;
Graphics g;
Game(): p(data), ia(data), g(data) { }
void update() {
ia.update();
p.update();
}
void draw() {
g.update();
}
};
struct Physics {
Game::Data& data
std::vector<Object> objs;
explicit Physics(Game::Data& data): data(data) { }
void update() { // prendre en compte le temps entre chaque call à update s'il n'est pas fixé (mais il est préférable qu'il le soit)
for(Object o: objs) {
velocities[o] += accelerations[o];
positions[o] += velocities[o];
}
}
};
struct RandomIA {
Game::Data& data
std::vector<Object> objs;
explicit RandomIA(Game::Data& data): data(data) { }
void update() {
for(Object o: objs) {
accelerations[o] = vec2(rand() - RAND_MAX / 2, rand() - RAND_MAX / 2); // rand c'est mal -> std::random
}
}
};
struct Graphics {
Game::Data& data
Renderer& renderer; // permet d'abstraire la phase de rendering
QuadTree<Object> objs; // ou n'importe quel conteneur adapté, on veut itérer
// à travers les objets dans un certain ordre pour faciliter les calculs
explicit Graphics(Game::Data& data): data(data) { }
void update() {
for(Object o: objs) { // on va dire que c'est une façon valide d'itérer sur un quadtree
// culling relativement simple grace au quadtree
renderer.draw(o); // ça peut être une simple préparation (mise à jour de vertex buffers par exemple)
}
renderer.present(); // maintenant que les données sont prêtes -> un ou plusieurs glDraw, mais le renderer "se démerde"
}
};
// Renderer::draw utilisera "transformations" (pas forcément besoin de positions), mais même s'il en à besoin, ça reste utilisable.
// Il faut bien sur faire gaffe dans un contexte multi threads si plusieurs systèmes travaillent sur les mêmes données.
// Tu auras aussi probablement un graphe de scène qui te permettra de maintenir tes "transformations" à jour. |
Je pense que tu te méprends sur weak_ptr. Lorsque tu fais un lock, tu obtiens un shared_ptr. Si ce shared_ptr est valide, cela veut dire que le premier shared_ptr (le propriétaire) n'a pas encore détruit l'objet. Et s'il souhaite ensuite le détruire, tu as un shared_ptr dessus, tu as donc la garantie que l'objet ne sera pas détruit tant que tu conserves ce shared_ptr.