Workaround für virtual function templates !
-
jo dann denk mal weiter drüber nach
bin gespannt! aber ehrlich ich würd gern wissen ob es gegenüber version 2 ein performance nachteil gibt. weil, eigentlich geht es ja nur darum den code für ansatz II automatisch vom compiler generieren zu lassen!
-
lemonhead schrieb:
jo dann denk mal weiter drüber nach :)...
Jo, hab's nun durchschaut (denke ich) ... template, vtable-Polymorpiee, overloading, .... Du nutzt eigentlich alles an Techniken für generische Programmierung, die C++ hergibt ;)...
Finde es gut, sehr lehrreich und auch (typ-)sicher. Ob es aber schnell genug ist, kann ich so nicht beurteilen. Ein dynamisches Erweitern um weitere "Waffen" (zur Laufzeit) ist halt nicht mehr möglich und insgesamt ist natürlich eine "Vererbungsexplosion" bei zunehmender Waffenzahl kommt natürlich auch auf das Programm zu, aber das sind wohl ein gewollte Zugeständnisse an die Perfomance ... (bzw. eine Technik, die ein "gemäßigtes" und festes Sortiment an Waffen voraussetzt).
Ob es jetzt tatsächlich schnell genug ist, kann ich leider nicht beurteilen (da Du aber nur eine vtable-Indirektion hast statt 2, vermute ich es stark).
Gruß,
Simon2.
-
Warum abstrahierst du die Kollisionserkennung nicht aus und verwendest Kollisionsmodelle und prüfst dann einfach zwei Kollisionsmodelle auf eine mögliche Kollision. Dann hast du diese fest verdrahtete Struktur nicht (mehr).
So wird es bei allen Physik-Engines gemacht, du erstellst einfach ein Kollisionsmodell in der Physik-Engine die berechnet die Auswirkungen auf die (vereinfachte Welt) und liefert dir Transformations-Matrizen mit denen du die Auswirkungen auf die echte Welt übertragen kannst.Die Effekte kannst du dann ebenfalls auskoppeln indem du Informationen über die Modelle in den Modellen speicherst und so den richtigen Effekt lädst, wenn z.B. ein Laser auf Metall (eines Raumschiffs) trifft.
Ist jetzt recht knapp gefasst, bei sowas Komplexen aber ich hoffe du verstehst was ich meine
-
von wegen physik-engines!!!
also, vielleicht sollte ich doch etwas mehr zu meinem eigentlichen projekt sagen. Ich versuche es mal.
Also, stell dir einen endlichen Automat vor. Die Spaceships sind die Zustände, die Waffentypen sind das Alphabet. Es gibt 500 Zustände, die sich aber in 5 Typen kategorisieren lassen. Jeder dieser Zustandstypen hat einen charakteristischen Umgang mit dem Eingabealphabet.
Das Alphabet wiederum hat 6 Zeichen, und es ist zur Compilezeit bekannt welche Befehle (Zeichen) der Automat kriegt.struct StatePilotBase { template<int symbol> processSymbol()=0; }; template<int state_type> struct StatePilotT { template<int symbol> processSymbol() { StateBlock& block = ((StateMachine*)this)->state_blocks[ ((StateMachine*)this)->state_block_index ]; ... // process information from block ((StateMachine*)this)->state_pilot = ... ((StateMachine*)this)->state_block = ... } }; struct StateBlock { ... }; struct StateMachine : StatePilotT<0>, StatePilotT<1>, StatePilotT<2>, StatePilotT<3>, StatePilotT<4> { StateMachine() { ... // fill state_blocks ... // set start state } template<int symbol> void processSymbol() { state_pilot->processSymbol<symbol>(); } vector<StateBlock> state_blocks; // current state description int state_block_index; StatePilot* state_pilot; };so ich hoffe da ist jetzt kein fehler drin, ich kann ja als nicht-member nicht mehr editieren..
-
oh toll, es fehlt natürlich das wort "virtual void" in
struct StatePilotBase { template<int symbol> virtual void processSymbol()=0; };Hier ist natürlich auch klar daß dies mit normalem c++ nicht geht.
-
lemonhead schrieb:
von wegen physik-engines!!!...
Hi,
auch wenn ich das schon so verstanden hatte, dass es Dir weder um spaceships, noch um physikalische Kollisionen geht, ist der Vergleich vielleicht gar nicht so schlecht. Prinzipiell macht es ja keinen Unterschied, ob Spaceships auf Waffen oder "Zustände" auf "Befehle" reagieren müssen (was Du ja mit Deinem ursprünglichen Beispiel schon ausgenutzt hast). Ich habe wirklich keine Ahnung vo Spieleprogrammierung, aber vielleicht kannst Du da ja tatsächlich noch die eine oder andere sinnvolle Idee abgreifen und auf Dein Programm übertragen.
Wenn natürlich wirklich Dein Befehlssatz eher fix und stark beschränkt bleiben wird, wäre das wohl die "Kanonen/Spatzen-Geschichte".
lemonhead schrieb:
...ich kann ja als nicht-member nicht mehr editieren..
... was sich ja aber mit ein paar Clicks kostenlos ändern ließe
Gruß,
Simon2.
-
bin drin
Das einzige was es kostet ist meine Emailadresse. Ich könnte zwar auf trashmail zurückgreifen, aber dann kriege ich keine Benachrichtigungen.Simon2 schrieb:
Wenn natürlich wirklich Dein Befehlssatz eher fix und stark beschränkt bleiben wird, wäre das wohl die "Kanonen/Spatzen-Geschichte".
Eigentlich will ich der StateMachine ein paar template-Parameter geben, aus denen berechnet sich dann die Menge der möglichen Befehle (Alphabet). Es geht um Geometrie, die Parameter wären dann die Dimension, topologische Orientierbarkeit etc. Diese Parameter kennt man ja im allgemeinen vorher.
Das mit den Kollisionen hab ich aber noch nicht ganz kapiert. Wo bezieht sich lolz jetzt auf physikalische Begriffe, und wo auf Programmierkonstrukte?
-
lemonhead schrieb:
...aber dann kriege ich keine Benachrichtigungen....
Das ist aber kein Nachteil gegenüber dem Leben als Unregistrierter ...
lemonhead schrieb:
...Wo bezieht sich lolz jetzt auf physikalische Begriffe, und wo auf Programmierkonstrukte?
Naja, ich (Ahnungsloser) hatte unter "Kollisionsmodell" ein Programmiermodell verstanden, aber es ist genauso möglich, dass es sich dabei um ein "physikalisches Modell von Kollisionen" gemeint ist - das Dir wirklich nicht weiterhilft...
Irgendwie habe ich nicht den Eindruck, Dir wirklich weiterhelfen zu können ....
(und habe wahrscheinlich mehr von Dir gelernt als andersherum - nun: Danke).Gruß,
Simon2.
-
Ich ging davon aus, dass du wirklich ein Spiel programmieren möchtest.
Kannst mein Posting also getrost vergessen.
-
Ich habe die Idee mal in einem anderen Forum diskutiert, siehe
http://www.gamedev.net/community/forums/topic.asp?topic_id=424879Basierend auf einem Vorschlag von einem Member dort komme ich auf die folgende, noch elegantere Version.
DelegatorBase<Missile> DelegatorBase<LaserGun> \ / \ / XWing SpaceshipBase BWing | \ ______________/ / \ \_________________ / | | \ / / \ \ / | | \_________/______ / \ ___\___/ | | / \ / \ / \ | | / \ / \ / \ | DelegatorT<XWing, Missile> \ / DelegatorT<BWing, Missile> \ | \ \ / | \ | \ DelegatorT<XWing, LaserGun> | DelegatorT<BWing, LaserGun> \ / | / \ / | / SpaceshipT<XWing> SpaceshipT<BWing>// general framework //--------------------------------------------------------------------------- template<struct Weapon> struct DelegatorBase { virtual void hit_v(Weapon*)=0; }; struct SpaceshipBase : DelegatorBase<Weapon_1>, // can be achieved in code size O(1) ..., DelegatorBase<Weapon_k> { template<struct Weapon> hit() {hit_v((Weapon*)0);} }; template<struct ShipType, struct Weapon> struct DelegatorT : virtual ShipType, virtual SpaceshipBase { virtual void hit_v(Weapon*) {hit_impl<Weapon>();} }; template<struct ShipType> struct SpaceshipT : DelegatorT<ShipType, Weapon_1>, // can be achieved in code size O(1) ..., DelegatorT<ShipType, Weapon_k> { }; // specific spaceships //--------------------------------------------------------------------------- struct Type_XWing { template<struct Weapon> void hit_impl() {...} }; struct Type_StarDestroyer { template<struct Weapon> void hit_impl() {...} }; // specific weapons //--------------------------------------------------------------------------- struct Missile {...}; template<int n> struct RailgunT // Railgun type n {...}; // usage //--------------------------------------------------------------------------- void main() { SpaceshipBase* spaceship = new SpaceshipT<Type_XWing>(); spaceship->hit<Missile>(); }Vorteil: Beim Implementieren der Schiffstypen muss man sich nicht mehr mit der komplizierten Architektur herumschlagen.