Irix > Programmieren, Kompilieren

Eine harte Nuss für C++ Gurus

<< < (3/6) > >>

majix:
@Jasper:
Für so unelegant halte ich meine Methode nicht - ich habe natürlich eine kleine Wrapper-Methode, die man aufruft, um weiterhin die Implementierung zu verbergen. D.h. die Programme werden sowieso nicht direkt die Funktion f aufrufen, sondern eine andere Funktion, die eben testet, ob der Aufruf von f überhaupt notwendig ist. Und ja, für höchstmöglichste Performance sollte man etwas tricksen, und vor allem redundante OpenGL Aufrufe eliminieren. Ich denke gerade im Grafikbereich kann sowas durchaus entscheidend sein.

@Tilman:
Wow, ein ganzer Haufen Code. Danke :)
Ist auf jeden Fall eine Überlegung wert - es stört mich halt nur, dass jetzt die beiden Funktionen (aktivieren, deaktivieren) in getrennte Klassen wandern, wobei diese ja eigentlich sehr eng miteinander verwandt sind.

Ich sehe schon, meine einfache Idee ist leider so nicht ohne weiteres machbar... naja, ich werde heute abend nochmal ein wenig rumspielen, vielleicht finde ich ja doch noch eine unkomplizierte Lösung.

Grüße,
Kaya

Brombaer:

--- Zitat ---
Und ja, für höchstmöglichste Performance sollte man etwas tricksen, und vor allem redundante OpenGL Aufrufe eliminieren. Ich denke gerade im Grafikbereich kann sowas durchaus entscheidend sein.

--- Ende Zitat ---


Hallo Kaya,

definitiv ;-) Kannst ja mal in den Code vom OpenSG (http://www.opensg.org) reinschauen, der ist selbst auf SGIs mittlerweile sehr performant und stellt das ein oder andere kommerzielle Produkt in den Schatten.

Gruß

atthias

sgt_barnes:
Noch 'n Link, der in eine ähnliche Kerbe haut (wobei auf die ID-Software-eigene Definition von "shader" geachtet werden muss):

http://home.planet.nl/~monstrous/tutshader.html

MfG, Tilmann

Jasper:
Hallo Kaya,

unelegant ist das sicher nicht, was Du vorhast, aber eben problematisch.  M.E. ist Tilmans Ansatz sicher eine gute Idee, denn er kapselt den Zugriff auf den Shader auf definierte Weise und kommt ohne Mehrfachvererbung und RTTI aus. Ob das von der Laufzeit besser ist? Ausprobieren.

Andere Vorschläge:
-> und oder == überladen, und statt einer Funktion f() ein Funktionsobjekt herzunehmen (nur 'ne Idee, keine Ahnung, ob man das so machen kann...)
Templateklassen verwenden, und auf virtual verzichten: So verzweifelt bist Du nicht
Du könntest natürlich auch für jede Shaderklasse eine virtuelle Methode f_overrides_baseclass einführen und das abfragen...

Und nein, die Funktionen activate und deactivate sind für dein Problem eben nicht eng miteinander verwandt...

Gruss

Jasper

majix:
@Matthias:
Bis heute habe ich mir OpenSG noch nicht angesehen, aber das werd ich demnächst mal nachholen. Gerüchteweise ist der Code aber derart komplex, dass es kaum jemanden mehr gibt, der ihn noch vollständig durchschaut.

@Tilman:
Danke für den Link, werd mir das mal etwas genauer ansehen. Allerdings sind die dortigen Struktuen bei mir eher Materialen, Shader sind für mich wirklich aktive Programme, die durch die Materialen parametrisiert werden. Das scheint so am meisten Sinn zu machen, was Flexibilität anbetrifft.

@Jasper:
Es kommt auf die Sichtweise an, ob die beiden Funktionen verwandt sind oder nicht. Aus Sicht des Shaders sind sie definitiv verwandt, und genau deshalb will ich sie nicht auseinanderreißen. Denn die "deactivate" Funktion muss immer einige OpenGL States ausschalten, die von der "activate" Funktion eingeschaltet worden sind. Sonst gibt es hässliche Resultate auf dem Monitor. Durch Auseinanderreißen von logisch eng zusammenhängenden Dingen scheint mir eine potentielle Fehlerquelle zu sein, deshalb sträube ich mich da ein wenig.

Aber ein gutes Buch über Design Pattern in C++ könnte mir nicht schaden... Kennt jemand eines?

Grüße,
Kaya

Navigation

[0] Themen-Index

[#] Nächste Seite

[*] Vorherige Sete