Du bist nicht angemeldet.
Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!
15.06.2015, 13:55
Vor allem weil Deine Beschreibung deiner Systeme und Data Oriented Design
nicht so ganz zusammen passen. [...] Jedenfalls hat Dein Beispiel eher weniger mit DOD zu tun.
15.06.2015, 16:38
Wie gesagt, anhand der dürftigen Beschreibung kann man es nur vermuten. Aber wenn ich schon pushEvent lese, dann kann das nicht passen.
DOD bedeutet doch im Grunde, dass man genau die Daten direkt im Speicher beieinander hat, die man gerade genau für die Berechnung braucht.
Alleine die Signatur Deiner Methode läßt da Zweifel aufkommen. Wenn das noch Events in Spiel kommen und du eventuell dann wahllos dadurch
im Code umher springst, dann ist eh alles verloren.
Aber wie gesagt, man kann es nur vermuten. Oder Deine Beispiele sind einfach unglücklich gewählt.
Die Daten sind in der Tat cache-freundlich angeordnet und die internen/privaten Methoden enthalten die Logik die auf den Daten ausgeführt wird... Und die übergeordnete Logik (z.B. vor einer Bewegung wird ein Kollisionstest ausgeführt) steckt in der update()-Methode.
|
C-/C++-Quelltext |
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 |
struct PhysicsData { unsigned int id; unsigned int x, y; // pos bool collideable; int move_x, move_y; // movement vector }; struct PhysicsEvent { unsigned int id; int move_x, move_y; }; class PhysicsSystem { private: std::vector<PhysicsData> components; std::vector<PhysicsEvent> incomming; // liefert true falls objekt auf (x,y) kollidieren würde (mit terrain oder anderem objekt) bool doesCollide(PhysicsData const & data, unsigned int x, unsigned int y) const { // ... } // führt Bewegungsinterpolation aus void interpolate(PhysicsData& data, int elapsed_time) { // ... } public: void push(PhysicsEvent const & event) { incomming.push_back(event); } void update(int elapsed_time) { // handle events for (auto const & ev: incomming) { auto& obj = components.at(ev.id); // Zuordnung via ID in echt anders ^^ if (!doesCollide(obj, ev.move_x, ev.move_y) { // apply event obj.move_x = ev.move_x; obj.move_y = ev.move_y; } } incomming.clear(); // interpolate object components for (auto& obj: components) { if (obj.move_x == 0 && obj.move_y == 0) { continue; } interpolate(obj, elapsed_time); } } }; |
|
|
C-/C++-Quelltext |
1 2 3 4 5 6 7 8 9 10 |
PhysicsEvent ev; ev.id = 13; ev.move_x = 1; ev.move_y = -1; my_physics_system.push(ev); my_physics_system.update(50); // z.B. 50ms // und dann über die (hier weggelassene restliche API) auto& data = my_physics_system.query(13); // prüfen ob sich data.x, data.y richtig geändert haben etc. |
|
|
C-/C++-Quelltext |
1 2 3 4 5 6 7 |
namespace impl { void interpolate(PhysicsData& data, Scene& scene, int elapsed_time) { // ... } } |
|
|
C-/C++-Quelltext |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
namespace priv { struct PhysicsImpl { PhysicsImpl(/* ... */) { // ähnliche Konstruktion wie PhysicsSystem, so dass es die Scene(n) bereits kennt } void interpolate(PhysicsData& data, int elapsed_time) { // ... } }; } // ::priv class PhysicsSystem: private priv::PhysicsImpl { // ähnlich oben, nur ohne die Unterroutinen }; |
|
|
C-/C++-Quelltext |
1 2 3 4 5 |
PhysicsData data; // setup object priv::PhysicsImpl impl(/* setup up */); impl.interpolate(data, 50); // check data |
Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von »Glocke« (15.06.2015, 17:37)
16.06.2015, 09:13
|
|
C-/C++-Quelltext |
1 2 3 4 5 6 7 8 9 |
struct PhysicsData { ... }; class PhysicsSystem { ... } namespace physics { void interpolate(std::vector<PhysicsData>& data,int elapsed); } |
|
|
C-/C++-Quelltext |
1 2 3 4 5 6 7 8 |
struct PhysicsData { std::vector<unsigned> id; std::vector<int> x; std::vector<int> y; std::vector<int> moveX; std::vector<int> moveY; std::vector<bool> collidable; } |
16.06.2015, 09:34
C-/C++-Quelltext
Ich persönlich finde es wichtig, diese Methoden in einen passenden Namespace zu setzen. Aber das muss nicht.
Brauchst Du alle Attribute von dem Struct an dieser Stelle?
Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »Glocke« (16.06.2015, 09:42)
02.09.2015, 12:48
ich denke darüber nach das PhysicsSystem aufzuteilen: CollisionSystem, MovementSystem, FocusingSystem und diese über Events miteinander reden zu lassen (CollisionSystem leitet InputEvent (Bewegung) an MovementSystem weiter - ohne propagiert ein CollisionEvent; MovementSystem interpoliert und leitet an Input FocusingSystem weiter; letzteres aktualisiert den Fokus jedes Objekts).
02.09.2015, 15:17
Private/Protected Methoden und Member kannst du im Grunde nur BlackBox testen.
Sowas wie #ifdef UNITTEST ... ist echt unschön. Man sollte (imo) die Tests nicht im Produktivcode sehen.
Zum testen kannst du dafür evt. Mocks verwenden, um z.B. protected Member herausreichen zu können (ableitende Klasse bekommt getter für protected member der Elternklasse).
Programmierung und Informatik »
Verwaltung von Listen mit Managern?
(19.01.2015, 21:05)
Programmierung und Informatik » Memory-Managar und Speicherverwaltung
(03.06.2009, 11:17)
Programmierung und Informatik » Objek Manager
(28.11.2004, 13:06)
13.05.2024, 17:44
Zum Seitenanfang
