hi,
ich hatte da schon vor längerem eine idee die ich gerne mal umsetzen möchte.
nämlich dachte ich mir das eine interpreter-einheit für material-definitionen
in form eines skripts vielleicht nicht die schnellste lösung ist.
also so was hier:
|
Quellcode
|
1
2
3
4
5
6
|
material "M1"{
ALPHA_BLEND 0;
COLOROP1 ADD;
COLORARG1 TEXTURE;
COLORARG2 DIFFUSE;
}
|
das is jetzt nur ein willkürliches beispiel wie sowas theoretisch aussieht.
meine idee war das ich eine art jit-compiler entwickle, der solche script-files
zu einer kleinen funktion compiliert also aus obrigen praktisch
eine compilierte function der art hier macht:
|
C-/C++-Quelltext
|
1
2
3
4
5
|
void renderstateswitch1(){
meinDevice->SetRenderState(....);
meinDevice->SetTextureStageState(...);
//usw.
}
|
natl. könnte das auch communication mit einem shader beinhalten
also SetShaderConstant-Aufrufe is ja egal.
die grundidee war, das der compiler zur laufzeit wenn ein neues script geladen
wird, die adresse des devices bekommt und dann maschinencode
entsprechend einer obrigen c-function generiert.
was mich im prinzip davon abhält so was zu implementieren,
ist mein fehlendes wissen über compiler-bau.
vor allem dies hier:
wie ruf ich in asm eine member-funktion einer klasse auf?
und: könnte es problematisch werden, da IDirect3D-Objekte alles
COM-Interface sind?
ist hier etwas besonderes zu beachten?
fragen über fragen.
ich hoffe ich konnte meine idee einigermaßen gut rüberbringen
und eine produktive diskussion anregen.
ich hoffe natl. das solche renderstate-switches schneller sind
als sachen der form
|
Quellcode
|
1
|
if (...)then else;
|
aber selbst wenn kein signifikanter performance-gewinn daraus
resultiert, es wär auf jeden fall interessant es zu implementieren.
greetz 23h