3D-Grafikprogrammierung



  • Wie gehe ich das Thema 3D-Grafikprogrammierung mit einem Assembler wie MASM oder NASM am besten an? Gibt es dafuer Tutorials oder ein paar Programmbeispiele irgendwo im Internet?
    Ich habe eine pdf-Datei gefunden, aber die ist wohl nicht fuer Anfaenger gedacht. ­čś×
    http://www.weblearn.hs-bremen.de/risse/RST/WS06/Grafikkarten-Programmierung/Ausarbeitung.pdf
    Wer programmiert so etwas oder kennt Codes oder Tutorials zum Thema? ­čśĽ



  • In was bist du denn Anf├Ąnger: Programmierung, Assembler, Grafik oder 3D?

    Vorab schonmal: 3D Grafik wird ├╝blicherweise mit den Bibliotheken OpenGL oder Direct3D erstellt, wobei einiges an Vorwissen empfehlenswert ist.

    (Beispiele: [1][2])



  • Mit Assemblern habe ich schon einige Programme erstellt; nicht nur auch dem PC. Das ist fuer mich kein absolutes Neuland. Mir fehlt momentan nur etwas die Uebung, da ich in der letzten Zeit nur immer nur mal zwischendurch etwas gemacht habe.
    Aber ein Tutorial fuer die 3D-Programmierung, das Schritt fuer Schritt in die Programmiertechniken einweist, waere jetzt sehr gut. Ich habe leider bisher noch nichts derartiges finden koennen. ­čś× ­čśĽ



  • Wie Youka schon geschrieben hat, verwendet man zu 99% OpenGl oder DirectX. Wenn du das in Assembler machen willst, sollte es kein Problem sein, weil du im Endeffekt nur API Funktionen aufrufen musst. Hier bringt Assembler aber keinen Vorteil, weil es nur unendlich viel umst├Ąndlicher als in einer Hochsprache w├Ąre und sonst nichts.
    Wenn du alles von Hand machen willst, w├Ąr halt wieder die Frage, wie weit du gehen willst. Du k├Ânntest versuchen, statt OpenGl direkt den Grafikkartentreiber anzusprechen. Wird noch umst├Ąndlicher und bringt auch gar nichts. Oder du schreibst einen Software-Renderer. W├Ąr vielleicht mal ein interessantes Projekt, aber das wird nicht ansatzweise so performant wie morderne Grafikkarten.



  • Ich denke, wenn ich die fertigen Sachen, wie Direct X und Grafikkarten-Treiber benutze, busse ich schnell Rechenzeit ein und die ist kostbar! ­čś×
    Und wie kann man die Grafikkarten direkt ansprechen? Ueber Interrupte oder die Ports? Und wo kann man genaueres darueber erfahren? Gibt es da Handbuecher von den Herstellern, so wie bei Intel? ­čśĽ



  • Eric Norbert Falbe schrieb:

    Ich denke, wenn ich die fertigen Sachen, wie Direct X und Grafikkarten-Treiber benutze, busse ich schnell Rechenzeit ein und die ist kostbar! ­čś×

    Ich wei├č nicht, ob das dein Ernst ist, aber es ist ziemlich vernachl├Ąssigbar. Im Endeffekt musst du nur einen Shader an die Grafikkarte ├╝bergeben, da wirst du gegen├╝ber DirectX sehr wenig einsparen k├Ânnen, wenn ├╝berhaupt.
    Windows definiert eine Schnittstelle f├╝r Grafikapdapter, die Treiber von Grafikkarten implementieren m├╝ssen. Bei neueren Versionen hei├čt es Windows Display Driver Model. Die Doku gibts bei Microsoft.



  • Eric Norbert Falbe schrieb:

    Ich denke, wenn ich die fertigen Sachen, wie Direct X und Grafikkarten-Treiber benutze, busse ich schnell Rechenzeit ein und die ist kostbar! ­čś×

    Viel eher wird genau das Gegenteil der Fall sein. Die Grafikkarte "direkt ansprechen" ist heutzutage nichtmehr einfach so drin. Nat├╝rlich sind auch aktuelle Grafikkarten noch VGA kompatibel und das ist vielleicht eine nette ├ťbung, aber wenn du Performance willst, musst du die GPU nutzen. Und das ohne die entsprechenden System APIs zu tun, bedeutet effektiv, einen eigenen Treiber f├╝r die Hardware zu schreiben. Das allein ist f├╝r eine Einzelperson vermutlich ein Lebenswerk und selbst dann wirst du an die Performance einer normalen Anwendung, die OpenGL oder Direct3D benutzt vermutlich nichtmal ansatzweise herankommen...



  • Eric Norbert Falbe schrieb:

    Ich denke, wenn ich die fertigen Sachen, wie Direct X und Grafikkarten-Treiber benutze, busse ich schnell Rechenzeit ein und die ist kostbar! ­čś×

    Rechenzeit bu├čt du durch schlechten Code bei der Physik ein, nicht beim Aufruf der Grafik API Funktionen, welche bereits extrem low-level sind (Direct3D hei├čt nicht umsonst Direct3D und OpenGL ist die ebenso effektive Alternative).

    Eric Norbert Falbe schrieb:

    Und wie kann man die Grafikkarten direkt ansprechen?

    Wie dot bereits passend schrieb:

    dot schrieb:

    ...wenn du Performance willst, musst du die GPU nutzen. Und das ohne die entsprechenden System APIs zu tun, bedeutet effektiv, einen eigenen Treiber f├╝r die Hardware zu schreiben. Das allein ist f├╝r eine Einzelperson vermutlich ein Lebenswerk...

    Das willst du nicht, also gib's auf.
    Ich hatte dir bereits Beispiele zur Nutzung von OpenGL in Assembler geschrieben, versuch dich dran.

    Youka schrieb:

    (Beispiele: [1][2])



  • Moin, moin.

    dot schrieb:

    Eric Norbert Falbe schrieb:

    Ich denke, wenn ich die fertigen Sachen, wie Direct X und Grafikkarten-Treiber benutze, busse ich schnell Rechenzeit ein und die ist kostbar! ­čś×

    Viel eher wird genau das Gegenteil der Fall sein. Die Grafikkarte "direkt ansprechen" ist heutzutage nichtmehr einfach so drin. Nat├╝rlich sind auch aktuelle Grafikkarten noch VGA kompatibel und das ist vielleicht eine nette ├ťbung, aber wenn du Performance willst, musst du die GPU nutzen. Und das ohne die entsprechenden System APIs zu tun, bedeutet effektiv, einen eigenen Treiber f├╝r die Hardware zu schreiben. Das allein ist f├╝r eine Einzelperson vermutlich ein Lebenswerk und selbst dann wirst du an die Performance einer normalen Anwendung, die OpenGL oder Direct3D benutzt vermutlich nichtmal ansatzweise herankommen...

    Wenn ich mich nicht t├Ąusche gibt es so gut wie gar keine konkreten Informationen f├╝r die ├ľffentlichkeit ├╝ber die 3D-Hardware-Funktionen moderner GPUs.

    F├╝r die 3dfx-Voodoo-GPUs gibt es ein meterlange Liste von Portadressen, wo zwar dahinter kurze Stichw├Ârter als Erkl├Ąrung stehen, aber eine Anleitung wie man nun vorgehen muss fehlt.
    (Bitte korregieren wenn ich mich irren sollte.)

    Es gibt ja noch nicht mal Informationen dar├╝ber wie man verschiedene 2D-Videomodi selber einschalten kann, ohne die Hilfe vom Bios, oder Closed-Source-Treiber zu verwenden(ich meine nicht ModeX, sondern Modi mit hoher Aufl├Âsung wie z.B. mit 1920x1200x32). Auch suche ich immer noch nach einer M├Âglichkeit auf einem zweiten Monitor den Inhalt des zweiten LFBs anzuzeigen, w├Ąhrend auf dem ersten Monitor der Inhalt vom ersten LFB (ggf. auch in einer anderen Aufl├Âsung) angezeigt wird. In den Linux-Quellen habe ich trotz mehrfachen suchen auch nichts finden k├Ânnen. Wo soll das ganz genau zu finden sein?

    Ich vermute das es bei allen Geforce- und auch Radeon-GPUs immer die selber Vorgehensweise ist, wie man dort Videomodi einschaltet. Ich meine diese Informationen k├Ânnten die finanzst├Ąrksten Enwickler wie AMD/ATI und NVIDIA gerne einmal herausr├╝cken. Es kann mir doch keiner erz├Ąhlen, dass mit solchen Informationen ein Quereinsteiger eine bedrohliche Konkurenz werden k├Ânnte. Oder das es nicht m├Âglich w├Ąre einen einzelnen damit vertrauten Mitarbeiter damit zu beauftragen solche Dinge einmalig zu ver├Âffentlichen. Diese Geheimnisskr├Ąmerei ist doch v├Âllig ├╝bertrieben. Moderne AMD-Karten sollen jetzt bis zu 6 Monitore unterst├╝tzen k├Ânnen. Ich weiss nicht mal wie man nur zwei diplay-adapter gleichzeitig von meiner Radeon 7950 selber verwenden kann. Meine erste ET4000-Karte kannte ich damals noch besser.

    Eigentlich sollte man deren Closed-Source-Treiber und auch das GraKa-Bios einmal revers-engenieren und dann alles ver├Âffentlich was man herausgefunden hat. Ich war bisher nur nicht ehrgeizig genug daf├╝r.
    (Nach meiner eigenen Rechtsauffassung darf ich mir mit meinen eigenen Augen jederzeit alles anschauen, was es anzuschauen gibt(Naturrecht/Menschenrecht).)

    ...

    So gibt es f├╝r 3D wohl nur die M├Âglichkeit Closed-Source-Treiber zu verwenden, oder doch alles komplett selber in Software zu programmieren, womit die Geschwindigkeit so einer reinen Softwarl├Âsung im Vergleich erheblich langsamer wird.

    Dirk



  • freecrac schrieb:

    F├╝r die 3dfx-Voodoo-GPUs gibt es ein meterlange Liste von Portadressen, wo zwar dahinter kurze Stichw├Ârter als Erkl├Ąrung stehen, aber eine Anleitung wie man nun vorgehen muss fehlt.
    (Bitte korregieren wenn ich mich irren sollte.)

    Ja, gibt es.

    Guck hier:
    http://www.vogons.org/viewtopic.php?t=25606



  • Moin, moin.

    3dfx rulez! schrieb:

    freecrac schrieb:

    F├╝r die 3dfx-Voodoo-GPUs gibt es ein meterlange Liste von Portadressen, wo zwar dahinter kurze Stichw├Ârter als Erkl├Ąrung stehen, aber eine Anleitung wie man nun vorgehen muss fehlt.
    (Bitte korregieren wenn ich mich irren sollte.)

    Ja, gibt es.

    Guck hier:
    http://www.vogons.org/viewtopic.php?t=25606

    Aaah, danke sch├Ân. Leider habe ich schon seit einigen Jahren selber gar keine Voodoo-Karte mehr.

    Dirk



  • freecrac schrieb:

    Moin, moin.

    3dfx rulez! schrieb:

    freecrac schrieb:

    F├╝r die 3dfx-Voodoo-GPUs gibt es ein meterlange Liste von Portadressen, wo zwar dahinter kurze Stichw├Ârter als Erkl├Ąrung stehen, aber eine Anleitung wie man nun vorgehen muss fehlt.
    (Bitte korregieren wenn ich mich irren sollte.)

    Ja, gibt es.

    Guck hier:
    http://www.vogons.org/viewtopic.php?t=25606

    Aaah, danke sch├Ân. Leider habe ich schon seit einigen Jahren selber gar keine Voodoo-Karte mehr.

    Dirk

    Brauchst du ja auch nicht.

    Mit der DOSEMU Voodoo Emulation kannst du ja problemlos in Assembler auf diese HW Emulation der Voodoo 1 zugreifen, ganz ohne GLIDE API & CO, das ist ja der Clou.

    Insofern steht deinem Vorhaben nichts im Wege und zur Voodoo 1 findest du alle Informationen die du brauchst.



  • Das Nutzen eine Emulators widerspricht dem Wunsch, keine Performance einzubuessen. Desweitern kann heutzutage nichtmehr direkt auf Hardware im allgemeinen bzw. GPUS im speziellen aus einem Userprogramm zugegriffen werden, wenn es beispielsweise um 3D geht.



  • knivil schrieb:

    Das Nutzen eine Emulators widerspricht dem Wunsch, keine Performance einzubuessen.

    Das tut er nicht.
    Da heute 3d Grafikkarten schneller sind als eine Voodoo 1 und die Voodoo 1 HW Emulation letzten Endes auf der Host Seite sowieso OpenGL verwendet, ist
    sein Programm auf alle F├Ąlle schneller.

    Desweitern kann heutzutage nichtmehr direkt auf Hardware im allgemeinen bzw. GPUS im speziellen aus einem Userprogramm zugegriffen werden, wenn es beispielsweise um 3D geht.

    Das ist richtig, ein Grund mehr, dass er daf├╝r die DOSBOX mit der Emulation verwendet, denn DOS stellt ihm da keine H├╝rden in den Weg.



  • 3dfx rulez! schrieb:

    knivil schrieb:

    Das Nutzen eine Emulators widerspricht dem Wunsch, keine Performance einzubuessen.

    Das tut er nicht.
    Da heute 3d Grafikkarten schneller sind als eine Voodoo 1 und die Voodoo 1 HW Emulation letzten Endes auf der Host Seite sowieso OpenGL verwendet, ist
    sein Programm auf alle F├Ąlle schneller.

    Desweitern kann heutzutage nichtmehr direkt auf Hardware im allgemeinen bzw. GPUS im speziellen aus einem Userprogramm zugegriffen werden, wenn es beispielsweise um 3D geht.

    Das ist richtig, ein Grund mehr, dass er daf├╝r die DOSBOX mit der Emulation verwendet, denn DOS stellt ihm da keine H├╝rden in den Weg.

    Was f├╝r ein Schwachsinn!



  • Mitnichten.

    1. Es ist nunmal Fakt, dass eine moderne GPU schneller ist, als eine inzwischen ├╝ber 15 Jahre alte Voodoo 1.

    2. Es ist auch Fakt, dass ein modernes OS keinen direkten Zugriff auf die HW durch ein Programm zul├Ą├čt, dass im Userspace l├Ąuft.
    Damit ein Programm direkt auf die HW zugreifen darf, braucht es die entsprechenden Privilegien und die hat es in der Regel nicht, daf├╝r sind Treiber da, die haben das.



  • 3dfx rulez! schrieb:

    Es ist auch Fakt, dass ein modernes OS keinen direkten Zugriff auf die HW durch ein Programm zul├Ą├čt, dass im Userspace l├Ąuft.

    Deswegen Benutz man die entsprechende API in einer nativen Anwendung, und nicht irgend einen Emulator ­čĺí



  • Moin, moin.

    Regt euch ab M├Ądels, jeder darf es machen wie er es gerne m├Âchte und es gibt keinen ernsthaften Grund einen Glaubenskrieg dar├╝ber zu f├╝hren.

    Ich selber h├Ątte aber wenig Lust dazu ├╝berhaupt einen Treiber daf├╝r zu verwenden, wenn ich so hardwarenah wie m├Âglich programmieren m├Âchte. Die Anwendung sollte dann auch selber gebootet werden k├Ânnen und keinesfalls emuliert werden. Das ist aber nur meine eigene Meinung dar├╝ber und diese m├Âchte ich auch keinen Menschen aufzwingen wollen. Wenn es eine Nachahmung findet dann freue ich mich, wenn nicht, dann ist das auch v├Âllig in Ordnung. F├╝r mich ist es kein Wettbewerb, sondern allenfalls ein eigenes Training, um die grauen Zellen bei Laune zu halten. Nicht mehr und nicht weniger.

    Dirk



  • freecrac schrieb:

    Die Anwendung sollte dann auch selber gebootet werden k├Ânnen und keinesfalls emuliert werden.

    Quasi eine Demo die man ins CD-Laufwerk oder sonst was schiebt und den Rechner davon bootet? W├Ąr fr├╝her vielleicht interessant gewesen, w├╝rde aber heute keiner mehr benutzen. Ich starte meinen Rechner z.B. nur sehr ungern neu und w├╝rde mich ├╝ber sowas nur ├Ąrgern und es nicht tun, wenn es keinen trifftigen Grund daf├╝r gibt.



  • TrollHunter schrieb:

    3dfx rulez! schrieb:

    Es ist auch Fakt, dass ein modernes OS keinen direkten Zugriff auf die HW durch ein Programm zul├Ą├čt, dass im Userspace l├Ąuft.

    Deswegen Benutz man die entsprechende API in einer nativen Anwendung, und nicht irgend einen Emulator ­čĺí

    Dummerchen, der TS hat doch gesagt, dass er mit den Registern der GPU direkt rumspielen will und das geht eben nur durch die HW Emulation der Voodoo 1,
    denn die Voodoo 1 ist die einzige GPU, zu der ausreichend Informationen zur Verf├╝gung stehen und wenn er keine Voodoo 1 hat, dann muss er die HW Emulation nehmen.


Log in to reply