Lowlevel
OffZone => Offtopic => Thema gestartet von: Roshl am 30. June 2005, 16:17
-
Ein Vorweg, es braucht keiner sagen "Nimm OpenGL, das ist besser weil kostenlos etc"
Ich progge nur für Win, und da kann ich mir sparen auf Multiplattformzeug zu schauen, ausserdem hab ich mich mit OGL eh schon beschäftigt, jetzt ist DX dran.
Ich hoffe irgendjemand hat sich mal mit DX befasst hier.
Problem: Ãusserst seltsame Arbeitsvergeigerung bei den Matrizen (D3DX-Funktionen)
Code: void InitMatrices()
{
D3DXMATRIXA16 matWorld;
D3DXMatrixRotationY(&matWorld,(timeGetTime()%400)/400.f);
D3DDevice->SetTransform(D3DTS_WORLD,&matWorld);
}
Wenn ich D3DXMatrixRotationY... auskommentiere erscheint zumindest ein Fenster (leer) so wie es sein soll, nicht auskommentiert passiert genau garnichts. Das seltsame dabei ist, ich rufe die Funktion noch nichtmal auf...
Ich benutze Dev-C++ 4.9.9.0 mit MingW, wenn ich die Fehlersuchenfunktionen nutze zeigt er mir was von Segementation Fault an, hab nur keine Ahnung wieso.
Vielleicht hat ja jemand nen Schimmer, danke im Vorraus.
-
Was meinst du denn damit es passiert "garnichts"?
Kein Fenster oder wie?
-
Genau, weder Fenster noch Fehlermeldung, gar nichts eben.
-
Hab zwar keine große Ahnung von D3D, aber musst du nicht erst die Einheitsmatrix laden?
Gut, wird wohl kaum was mit nem Segfault zutun haben,aber naja :)
Gruß GhostCoder
-
Ich dachte eigentlich, dass diese Rotationsfunktion eine Rotationsmatrix erstellt, mit der dann alle Vertices Multipliziert werden um den Transformierten Vertex zu erhalten.
Aber selbst wenn...ich muss die InitMatrices-Funktion ja nichtmal aufrufen damit er "abstürzt" also dürfte das doch egal sein.
-
Also ich habs jetzt zum Funktionieren gebracht. Statt D3DXMATRIX16A vervwende ich jetzt D3DXMATRIX, da macht er keine Probleme mehr, weiss der Teufel warum.
-
http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/directx9_c_dec_2004/directx/graphics/reference/d3dx/structures/d3dxmatrixa16.asp
probier's mal damit, da stehen eine menge probleme warum es bei dir nicht funktionieren könnte. auch wenn ich microsoft nicht besonders mag, aber die msdn ist was tolles =D...
-
Nimm OpenGL, das ist besser.
-
Dingsi, schau dir mal die Erste Zeile von Roshl's erstem Posting dieser Thread an, ich glaube da steht
Ein Vorweg, es braucht keiner sagen "Nimm OpenGL, das ist besser weil kostenlos etc"
-
Nimm OpenGL, das ist besser.
Ganz abgesehen davon, das das eine sehr relative Aussage ist.
Wenn man nur unter Windows programmieren (wie es oben auch Stand) will, ist es schnell gar nicht mehr besser. (Meiner Meinung nach)
-
Die Frage ist ob du nur weil du Windows benutzt es den anderen schwer machen willst es für Linux-User zugänglich zu machen :D
Wenn das Programm nur für dich ist ist es wohl geschmackssache ob DX oder OGL 8)
-
Mein Post sollte übrigens ganz doll witzig sein, aber das haben wohl ein paar Leute verplant..
-
Warum zum Teufel muss eigentlich JEDER scheiß Post mit OT zugespammt werden? Man sollte Foren abschaffen. Ich finds ganz ehrlich zum kotzen, das man sich durch Posts immer durch zig tausend zeilen nutzlosen Spam wühlen muss, um an die vernünftigen Posts ranzukommen.....
Kann man das denn nicht einfach mal abstellen?
-
Doch, Profil und dann das Häckchen bei "Spamming" weg. ;)
Ich finde, man sollte hier nicht jedes Nutzen von nicht-Linux-kompatiblem gleich als "Angriff" gegen die Linuxgemeinde sehen. DirectX ist für Windows konzepiert und von Microsoft gebaut. Die werden Ihr Betriebssystem wohl am besten kennen, weshalb ich mal so sagen würde, dass DirectX das beste für Windows ist von der Performance her.
-
Und genau wie bei TJ mit seiner Bomberman-Geschichte, dient bei mir das ganze dem Erlernen der Windows-Programmierung und der von DX. Also meiner Meinung nach ost OGL sinnlos um die DX Programmierung zu erlernen...
-
1. Jeder soll benutzen, was er braucht und was er will.
2. Linuxuser sind um nichts besser als Windowsuser (ich bin selbst 3/4 Linuxuser, 1/4 BSDler) denn für die gibt es nur "Windows = Schlecht, Linux = Gut" für Appler gilt in der Regel das Selbe...hey, es ist immer noch die inviduelle Entscheidung eines jeden was er benutzt...Linux ist ein Kernel der nicht mal schlecht ist, aber SuSE finde ich z.B. grottenschlecht. es gibt auch noch sehr viele andere brauchbare systeme -_-
Tut mir leid, dass auch ich jetzt spammte aber Topic is ja wohl geklärt oder? ansonsten könnt ihr den Post löschen.
-
wobei ich auch sagen muss, das dx wesentlich weniger kompliziert als ogl ist. klar, wunderschön unter c++ ist es nicht damit zu proggen, aber in meinen augen bei weitem nicht so schlimm wie in ogl.
ich bin für dx unter linux, aber das wird wohl ein traum bleiben ;)...
-
Ich find OGL übersichtlicher, man kann direkt Dreiecke Zeichnen ohne erst alles in Arrays sammeln zu müssen etc, geht bei OGL auch mit Displaylists, sieht dort aber einfacher aus. DX bietet allerdings bessere Hardwarebeschleunigung, bei OGL hab ich das nie hinbekommen da liefs immer Software.
-
Es stellt sich mir die Frage, wie gut Displaylisten noch beschleunigt werden.
Sinnvoll anwenden kann man die ja sowieso nur fuer statische Sachen, im Gegensatz zu den Arrays, die man auch fuer dynamische Sachen schnell halten kann. Aber auch fuer statische Geometrie stellt sich die Frage wo die hingepackt werden (GPU RAM, AGP RAM, System Memory?)
Und "neuere Techniken" wie Point Sprites sind wohl auch so eine Sache.
Ich habe das Gefuehl auch mit Display Listen kann man nicht mehr ganz die richtige Effizienz ueber die immediate Funktionen erreichen.
Weiss dazu jemand was genaues?
Vertex Arrays unter OpenGL sind leider grausig geworden, soviele Extensions die miteinander agieren ...
-
Meiner Meinung nach ist dieser Rendermethode eh überholt.
Raytracing wird kommen, auch mit Hardwareunterstützung, ein Deutscher hat dafür schon eine gebaut die Realtime-Raytracing hinbekommen hat. Hab da Screenies gesehen, echt top wenn das wirklich Realtime war.
-
Raytracing ist wirklich cool. Aber wegen dem Realtime-Raytracing: Ich glaub du meinst Daniel Pohl. Der hat auf einen Rechnerverbund an der Uni eine Realtime-Raytracing-Engine erstellt. Ich weiß nicht mehr die genaue Hardware aber das war richtig weit von normalen Pcs entfernt.
Ansonsten gibts noch sowas: http://www.openrt.de/
EDIT:
Hier ist der Link zu Daniel Pohls Projekt "Quake 3: Raytraced)":
http://graphics.cs.uni-sb.de/~sidapohl/egoshooter/
Die Schatten, Lichtbrechungen, Reflktionen usw. sind alle physikalisch richtig berechnet. Aber ich find die Texturen könnten noch höher aufgelöst sein.
-
Tja, irgendwie sind da schon Gegensaetze.
Rendering ist im simpelsten Fall extrem schnell umzusetzen, und sieht dafuer auch sehr schlecht aus. Raytracing im simpelsten Falle sieht dagegen schon eigentlich gut aus, ist aber sehr langsam. Na ja, gut das nun mittlerweile ein paar Techniken gibt um Raytracing zu beschleunigen.
-
Ich denke mal, dass die nächsten Grafikkartengenerationen noch genau wie bisher das normale Rendern unterstützen und weiter verbessern. Aber im Moment sind Dual-Core Prozessoren im kommen, die auch Raytracing beschleunigen könnten. Ansonsten gibt es ja noch die Raytracing-Karten. Sobald die wirklich erhältlich sind, sollte es nicht mehr lange dauern bis Spiele auf Raytracing-Basis erscheinen.
Zitat von der Quake 3: Raytraced Seite:
This is realtime speed for a virtual intel CPU with about 36 GHz (to be more precise: a cluster with 20 AMD XP1800 was used). Alternativly one slow PC (1 GHz) with a hardware raytrace GPU that is 3 times more powerful then an actual prototpye could be used.
Ein anderer Vorteil von Raytracing ist, dass man mit relativ wenig Code einen kompletten Renderer erstellen kann. Mit nur einer Hand voll weiteren Zeilen baut man dann realistische Spiegelungen usw. ein.
-
Nein ich meine keinen Rechnerverbund, ein einzelner Rechner mit einer RaytraceKarte.
Spiegelungen sind ja einfach zu machen, den ankommenden Ray um Normal um 90° drehen und den Algoryhtmus rekursiv aufrufen.
Brechung auch, wieder anhand des normals mit dem Brechungsfaktor machen und rekursiv.
Hab das alles schonmal programmiert, eigentlich ziemlich simpel. Man muss halt nur sehr viel von Vektorgeometrie verstehen und ein sehr gutes Vorstellungvermögen haben
-
Ja, ist wirklich halbwegs einfach. Aber wer von 3D-Mathe keine Ahnung hat (so wie ich) bekommt schnell Probleme. Die meisten Effekte basieren ja auf relativ simplem physikalischen Gesetzen, die man nach und nach einbauen kann.
Es gibt viele Tuts die sich damit beschäftigen. Einige sind auch über Realtime Raytracing auf aktuellen PCs.
Ein Tut über normales Raytracing: http://www.flipcode.com/articles/article_raytrace01.shtml
EDIT:
Noch ein Tut über Realtime R. Die Qualität ist zwar schlechter, als bei normalem Raytracing aber es ist trotzdem mal ganz interessant zu sehen.
http://homepages.paradise.net.nz/nickamy/raytracer/raytracer.htm