Tutorials für Fortgeschrittene? Engine-Design? Was-Muss-Drin-Sein?
-
0x00000001 schrieb:
Sgt. Nukem schrieb:
TGGC schrieb:
Dann dürfte aber auch daraus nicht mehr D3 entwickelt werden.
Weil Doom3 basiert auf Quake3 basiert auf Quake2 basiert auf Quake1... ich mach jetzt mal nicht weiter weil das käme mir schon heftig vor
Nee, das ist im Prinzip 'ne komplette Neuentwicklung. Das kleine Funktionen ggf. sogar noch von Q2 mitgeschleppt werden, ist klar.
-
Sgt. Nukem schrieb:
Nee, das ist im Prinzip 'ne komplette Neuentwicklung. Das kleine Funktionen ggf. sogar noch von Q2 mitgeschleppt werden, ist klar.
Ja, das sagst du. Und warum ist dann quasi alles gleich? So wie Q3 mit Shadern und StencilShadows?
Bye, TGGC Deine Unterstützung wird gebraucht!
-
weil man gute dinge an einer architektur übernimmt, und die teile die du als "quasi gleich" bezeichnest wurden nunmal von JC genau so eingecodet, wie er es seit jeher macht (obwohl es natürlich bessere wege gibt und er diesmal sogar die shaderoptimierungen die eh in Q3 waren für D3 aus irgendeinem grund wegließ... gut das NVidia zufällig genau diese nötigen optimierungen im treiber nachgebildet hat)
Selbst wenn man sie komplett neu codet, heutzutage sind engines evulutionär und nicht revolutionär und wenn sie aus einer hand stammen, erkennt man schon an der architektur, wer das war.rapso->greets();
-
rapso schrieb:
die shaderoptimierungen die eh in Q3 waren
Wo waren in Quake 3 Shader ? Die primitven Software Shader die eigentlich nicht mehr gemacht haben als paat Texture Eigenschaften in Software zu bestimmen ?
rapso schrieb:
erkennt man schon an der architektur, wer das war.
Wobei das wohl bei der Q3 und D3 Engine absolut nicht stimmt.
-
Ahvolon[F-Bytes] schrieb:
Wo waren in Quake 3 Shader ?
|
\/Ahvolon[F-Bytes] schrieb:
Die primitven Software Shader ...
q.e.d.
btw linkAhvolon[F-Bytes] schrieb:
Wobei das wohl bei der Q3 und D3 Engine absolut nicht stimmt.
da ich nur den resourcenaufbau sehe, kann ich auch nur darüber sprechen und der ist klar auf JC-style. in den D3-source konnte ich bischer leider keinen einblick werfern, insofern weis ich nicht wie die engine intern aufgebaut ist.
wobei ich hier klar von der softwarearchitektur spreche, nicht vom renderingsystem.
rapso->greets();
-
[quote="rapso"]link
Wie gesagt, dabei von Shader zu sprechen und dann zu sagen dass NV die Opts in den Treiber hat is bissel Ironie. Das ist einfach nur nen Wrapper für GL Blending States / Texture States etc. Da is mit Shading nich viel.
rapso schrieb:
softwarearchitektur spreche
Jap, und die ist bei D3 grundlegend anders als bei Q3.
-
Ahvolon[F-Bytes] schrieb:
Wie gesagt, dabei von Shader zu sprechen
diese benennung stammt von JC bei der Q3 engine, du mußt aber natürlich nicht seiner meinung sein, und der meinung vieler anderer enginemacher die die gleichen benennungen dafür haben.
Ahvolon[F-Bytes] schrieb:
und dann zu sagen dass NV die Opts in den Treiber hat is bissel Ironie. Das ist einfach nur nen Wrapper für GL Blending States / Texture States etc. Da is mit Shading nich viel.
du hast dich einfach verlesen.
wenn du genau gelesen hättest, würdest du entnehmen, dass ich sagte, dass für Q3 die optimierungen in der engine selbst waren. für D3-shader (insbesondere pixelshader-code) gab es einen teil der optimierungen im treiber von NV, nicht in der engine selbst, und wenn du den Q3 source gesehen hättest, wüstest du, das es mit einem blossen statemanager für oGL nicht getan wurde.rapso schrieb:
softwarearchitektur spreche
Jap, und die ist bei D3 grundlegend anders als bei Q3.[/quote]
wie gesagt, ich hab den source von D3 nicht und kann deswegen nicht sagen ob er jetzt anders codet als früher, zwischen Q1 Q2 und Q3 konnte man seinen still beim aufbau der engine architektur jedenfalls gut sehen.rapso->greets();
-
rapso schrieb:
und der meinung vieler anderer enginemacher die die gleichen benennungen dafür haben.
Weil es das auch in so vielen anderen Engines gibt
rapso schrieb:
wenn du genau gelesen hättest, würdest du entnehmen, dass ich sagte, dass für Q3 die optimierungen in der engine selbst waren.
Was natürlich oben nicht steht ^^
rapso schrieb:
das es mit einem blossen statemanager für oGL nicht getan wurde.
Jo, waren noch paar andere primitive Software Spielereien. Wie gesagt, hat mit Shadern aber nix zu tun. Und das OGL State Management war ein großer Teil davon.
-
rapso schrieb:
weil man gute dinge an einer architektur übernimmt, und die teile die du als "quasi gleich" bezeichnest wurden nunmal von JC genau so eingecodet
Macht es also 'nen Unterschied, ob genau so gecodet oder den Code wiederverwandt? Wenn ja, machen IMHO Rechte an Code gar keinen Sinn. Man könnte den Unterschied ja nicht beweisen. Kennt jemand 3DTT bzw. Peter Dobrovka?
Bye, TGGC (Der Held lebt!)
-
TGGC schrieb:
Sgt. Nukem schrieb:
Nee, das ist im Prinzip 'ne komplette Neuentwicklung. Das kleine Funktionen ggf. sogar noch von Q2 mitgeschleppt werden, ist klar.
Ja, das sagst du. Und warum ist dann quasi alles gleich? So wie Q3 mit Shadern und StencilShadows?
Stimmt, hat nur "extern "C" {" davor geschrieben, schon hatter aus'ner C- 'ne C++-Engine gemacht.
-
TGGC schrieb:
Kennt jemand 3DTT bzw. Peter Dobrovka?
^^
Wie ist das eigentlich ausgegangen ? Hab das am Ende nimmer verfolgt.
-
Ausgegangen ist garnichts. Ein Gutachter überprüft jetz eben genau das, wurde der 3DTT Source geklaut oder nicht?
Bye, TGGC (Der Held lebt!)
-
TGGC schrieb:
Ausgegangen ist garnichts. Ein Gutachter überprüft jetz eben genau das, wurde der 3DTT Source geklaut oder nicht?
Aha??
Naja, auf jeden Fall geht das bürokratentypisch mal wieder schnell wie Schmidt's Katze... http://www.pcgames.de/index.cfm?article_id=31934
-
Ahvolon[F-Bytes] schrieb:
rapso schrieb:
und der meinung vieler anderer enginemacher die die gleichen benennungen dafür haben.
Weil es das auch in so vielen anderen Engines gibt
jap, klingt aber fast so, als hättest du da ein informationsdefizit. eine der bekanntesten unter gpl dürfte fly 3d sein.
Ahvolon[F-Bytes] schrieb:
rapso schrieb:
das es mit einem blossen statemanager für oGL nicht getan wurde.
Jo, waren noch paar andere primitive Software Spielereien. Wie gesagt, hat mit Shadern aber nix zu tun. Und das OGL State Management war ein großer Teil davon.
ich hoffe du bezeichnest (vertex-/)fragment-programms nicht als einzige definition von shadern, denn das ist nur der marketingname von MS (und ATI mit ihren 'smartshadern') dafür. shader an sich sind beschriebungen wie ein pixel bearbeitet wird, damit man ihn nicht fullbright bzw mit albedo textur sieht, dabei ist es egal ob dies in software gemacht wird (wie z.b. renderman), register combinern (texturestages bzw pixelshader 0.5 laut MS) oder fragmentprogramms (>=pixelshader 1.0 laut MS)
rapso->greets();
-
Aber wenn ICH oder TGGC (jaja, der Esel) mal auf so Dünnschiss-Problemen korinthenkackiere, heisst's direkt: CLOSED !!
*schildhochhalt* *demonstrier* *kaffeetrink*
-
Sgt. Nukem schrieb:
Aber wenn ICH oder TGGC (jaja, der Esel) mal auf so Dünnschiss-Problemen korinthenkackiere
schön das du das schuldeingeständniss für dich und deinen companion so unterschreiben kannst, da bekomm ich gleich ein gutes gewissen eure flames doch zurecht geschlossen zu haben *haha*
zudem ist das in diesem fall keinDünnschiss-Problemen korinthenkackiere
sodern lediglich die aufklärung, das es shader schon seit langem gibt und das diese nun bei DX "Effects" heißen und pixelshader beinhalten, nichts viel an dem schon lange existenten begriff "Shader" ändert.
flame wäre sowas wie:
zum glück hat MS die fragmentprogramme nicht PixelKuh bezeichnet, sonst wären nun plötzlich kühe obsolet?rapso->greets();
-
rapso schrieb:
flame wäre sowas wie:
Um Flames ging's doch gar nicht...
Meine Posts dienen auch nur der Aufklärung, das kommt ab sofort in meine Sig.
SOA!
Darfst also nichts mehr löschen... hehe
