Welche API für Stonequest?

[Zudomon]

Wie der Titel schon sagt. Da ich noch ziemlich an Anfang stehe, wäre es vielleicht gar nicht schlecht sich mal ein wenig über die zu verwendete API Gedanken zu machen.

Zur Auswahl stehen:
* DX 9
* DX 10
* DX 11
* OpenGL

Wobei es bei 9 und 10 kein Problem für mich währe die zu verwenden... bei 11 wäre das riesige Problem, dass ich die Header dafür bräuchte ( mache ja unter Delphi und nein, ich werde auch nicht zu ner anderen Sprache wechseln ).
OpenGL habe ich damals verwendet ( 2000 - 2003 ) aber bin da nie über die fixed Funktion hinaus gekommen. Da waren Extensions und ähnliches für mich noch reine Magie.

Soweit ich weiß ist das neue OpenGL auch sehr mächtig und eventuell kann ich das auch in vollem Umfang in Delphi nutzen.

Also was meint ihr?

[Krishty]

Wer ist denn die Zielgruppe?

Die Frage hängt, falls ich mich recht irre, unmittelbar mit der Leistungsfähigkeit deiner Geometrieerzeugungsalgorithmen zusammen, weil die der Flaschenhals waren. Falls du wieder eine Quad-Core-CPU brauchen wirst, um den Bildschirm flüssig mit Weltdaten zu füttern, wirst du D3D9-Systeme und XP eh knicken können. Außerdem ist D3D9 heute Altlast und wird durch D3D11 emuliert (und Vögel zwitschern, dass die GPU-Hersteller auch bald ihre Treiberentwicklung dafür einstellen). Wenn du hingegen garantiert auch auf Netbooks mit 1,5 GiB RAM lauffähige Leistung erzielen wirst und die auch nutzen wollen wirst – und das nicht nur Wunschtraum sondern einigermaßen sicher einschätzbar ist – und die Kundenschicht keinesfalls verlieren wollen wirst, wähl D3D9.

D3D10 & 11 sind sich äußerst ähnlich, und benutzen afaik auch denselben Pfad im Betriebssystem. Ich persönlich würde mit D3D10 loslegen und dann irgendwann, sobald die 11er-Header rauskommen, einen Tag investieren um die einzubinden und jede 10 in meinen Bezeichnern durch 11 zu ersetzen. Sobald das Ding in der Alpha-Version wäre und D3D9 noch mehr als 5 % Marktanteil hätte, würde ich per Direct3D 11 Feature Level 9 einen 9er-Pfad für meine zurückgebliebenen Kunden dranzimmern.

OpenGL lasse ich außen vor, weil ich davon keine Ahnung habe.

Gruß, Ky

[waigie]

Bin leider im Moment etwas raus aus der Materie, da ich im Moment jedoch vor der selben Frage stehe hier mal das was ich im Moment für mich herausgefunden habe. Ich hab nur nicht vor mit Delphi zu arbeiten, daher sind DX11 Header für mich kein größeres Problem.

So fang ich mal bei OpenGL an. OGL hat den großen Vorteil, das man sich nicht unbedingt sorgen darum machen muss welches Betriebssystem die User einsetzen. Die volle Funktionalität von OGL ist immer dann einsetzbar sobald der Treiber und die Hardware sie unterstützen. Also gedanken ob da noch wer Windows XP (also nur DX9) kann gibt es da nicht. Andererseits haben die Standart Windows Treiber häufig einen grottigen OGL Support. Lässt sich zwar meist mit Treibern vom Hersteller beheben, aber da ist wieder die Frage wie viel man den Spielern zumuten möchte und kann. Dazu kommt das es mMn für Windows immernoch einer 1.X OGL Lib Standart ist und man auf die Erweiterungen nur mittels Extensions zugreifen kann. Das ist unter C++ mit GLEW recht einfach gestaltet, wenn es etwas vergleichbares für Delphi gibt okay ansonsten wird das echt unschön.
Ansonsten würde ich zur Zeit noch auf OpenGL 3.3 setzen. Die Version 4.X wird ja erst von Karten ab der Geforce 400er oder ATI 5000er Serie unterstützt. Ich hab jetzt zwar nicht so den Überblick, jedoch denke ich das die Verbreitung dieser Karten noch nicht so weit ist. In meinem Bekanntenkreis arbeiten viele noch mit Geforce 9800ern oder GTX280, welche beide OpenGL 3.3 unterstützen was der 4er Version sehr ähnlich ist.

Bei DirectX kann ich Krishty eigentlich nur zustimmen. Zumal er sich da besser auskennt.

Da du mit Delphi eh Windows als Zielsystem hast würde ich an deiner Stelle wohl auf DX10/11 zurück greifen. Die Verbreitung von Win7 nimmt stätig zu, sodass man sich um DX10+ Support keine allzu großen gedanken machen muss. Dazu kommt das man für die neuen DX SDKs einiges an Informationen im Web findet. Bei OpenGL ist das irgendwie anders. Ich zumindest finde kaum Informationen darüber wie man sinnvoll mit neueren OGL Versionen umgeht. Man findet einfach nur massenhaft Artikel über Fixed Function Pipeline OpenGL aber das ist seit 3.2 ja endlich Geschichte.

[Top-OR]

Wenn ich hier auch noch was mit reinrufen darf - ohne meinen Vorrednern zu wiedersprechen:

Was OGL angeht, so kann ich dir aus Erfahrung sagen, dass das auch keine Atomphysik ist. Die klassische (FF) Pipeline und die neue Welt gehen (relativ) fließend ineinander über und du kannst auch kleine Schritte in die Zukunft machen.
Nun gut, Geschichten wie z.B. Tesselation hab ich bisher auch noch nicht gemacht und weiß nicht, wie es da aussieht, aber ich denke, da kann man sich reinfuchsen und seinen vorhandenen Code ergänzen, ohne "alles wegschmeißen" zu müssen.

Um mal die Shaderbibel, das Orangebook zu zitieren: "This isnt your fathers OpenGL!". Musst halt wissen, ob dir der Stil von OpenGL liegt.

Nimm das, was dir am Leichtesten fällt. Falls DX10 kein großes Prob ist (für dich und für Delphi), nimm das.

Ich glaub, das ist wichtiger als manche technische Hintergründe, denn es ist wichtig, dass du einer von denen bist, die ihren Kram mal fertig bekommt, als das 1000te Feature einzubauen oder die Engine zu wechseln, um dann auf halbem Weg hängen zu bleiben. Es gibt sooo viele coole Projekte, welche leider nur "halbfertig" geworden sind ... *UnauffälligNachUntenSchauend*

Beste Grüße

[dot]

Ich würde sagen das ist eine Frage deiner Zielplattformen. Wenn du nur auf Windows laufen willst dann nimm Direct3D, sonst OpenGL oder beides. Direct3D ist die imo bei weitem bessere API. Ich würde D3D10 allerdings nichtmehr anfassen, aber wenn du für 11 keine Header hast bleibt dir wohl nichts übrig. Und wenn du XP supporten willst dann wirst du D3D9 verwenden müssen. Oder OpenGL.

[pUnkOuter]

Moment, warum willst du jetzt plötzlich vorgefertigtes Zeug verwenden. Schreib gefälligst deinen eigenen GPU-Treiber.

Aber im Ernst, ich würde dir raten, OpenGL zu verwenden. Gibt doch schon genug Windows-only Games. Und wenn du schon DX nehmen musst, dann bitte 9, sonst kann ich das Game dann nicht spielen :(.

[waigie]

Ich habe gesehen, dass du im Vorstellungsbereich erste Bilder gepostet hast. Kannst du kurz sagen für welche API deine Entscheidung gefallen ist und vielleicht sogar warum?

[Zudomon]

Ich habe gesehen, dass du im Vorstellungsbereich erste Bilder gepostet hast. Kannst du kurz sagen für welche API deine Entscheidung gefallen ist und vielleicht sogar warum?

Achso, klar... also ich hatte ja schon, als ich den ersten Post zum neuen Stonequest geschrieben hatte, direkt angefangen. Das ganze ist dann DX9... ich habe mir gedacht, falls ich dann wirklich mich umentscheiden sollte, was die API angeht, werde ich das auch im Laufe des Projektes noch ändern können... wobei natürlich umso eher umso besser.

Für DX11 habe ich nun eventuell auch die Header, habe die aber noch nicht getestet ( werde das auch nicht tun, solange ich es nicht verwenden will. So sehr steh ich ebend nicht aufs Programmieren, dass ich das dann nur aus Spass mal probiere ). :D

Ich mag DX9 sehr, weil ich da gut eingearbeitet bin und das Gefühl habe, so mehr oder weniger vollständig die API zu überblicken. Bei DX10 und 11 würde ich mir erstmal wieder sehr verloren vorkommen. Außerdem kenn ich mich ja, würde schnell dazu übergehen, Effekte zu machen und das Spiel bliebe dann auf der Strecke... da muss ich mich unbedingt von abhalten!!!
Außerdem finde ich es irgendwie geil, mal abgesehen davon, dass es alle verwenden können, dass ein wenig tricksen muss und kann um da noch richtig was raus zu holen. Siehe Pathtracer. Auch TGGC zeigt ja mit seinem Raytracing, was man noch alles für schöne Sachen auch mit DX9 machen kann.

Die Konturen in dem neuen Stonequest ( und ich hoffe, dass wird so bleiben ) sind auch nicht mehr über Parallax Occlusion gemacht, sondern echtes Displacementmapping :D

Fazit: Also danke erstmal für eure Ratschläge. Auch wenn ich nicht direkt drauf eingehe, trägt es aber doch dazu bei, mir zu überlegen, was ich nehme. Vorerst bleibe ich wohl, solange es nicht exorbitanten Aufwand bedeutet, bei dem alten DX9. DX11 würde ich gerne machen, aber ich würde erstmal gerne das Spiel hinbekommen und das sollte auch mit DX9 zu schaffen sein. 10 würde ich dann direkt überspringen, da sehe ich nämlich dann keinen Sinn drin. Bei OpenGL hatte ich gehört, dass selbst der Carmack, der ja bisher all seine Engines mit OpenGL umgesetzt hat wohl auch eher DX nehmen würde. Von daher würde ich sagen ist 9 und 11 schon die beste Wahl ( Irrtümer vorbehalten! :D ).

Ich hoffe du bist mit meiner Stellungsnahme zufrieden, ansonsten frag nochmal :)

[joggel]

Du könntest Dir ja auch noch mehrere Möglichkeiten freihalten.
Also unterschiedlliche Renderer schreiben.
Und in deinem Code, immer wenn du Renderanweisungen gibst, dich auf eine abstrakte Basisklasse beziehen.
Die konkreten Renderer erben dann eben von dieser Basisklasse.
Wenn Du dich dann eben mal entschliest OpenGL zu benutzen kannst Du dann deinen Renderer auf OpenGL "umstellen".

Okay, ist halt doppelte Arbeit weil du alles 2mal programmieren müsstest. Aber wäre ein tolles Feature.
Bzw:
Da hältst Du dir die unterschiedlichen Optionen noch offen, und brauchst dann nicht an zig Stellen im Code was zu ändern.

[Krishty]

Okay, ist halt doppelte Arbeit weil du alles 2mal programmieren müsstest. Aber wäre ein tolles Feature.

Nö, wäre es nicht. Es wäre halbe Qualität bei nicht ansatzweise aufwiegenden Vorteilen. Und doppelte Arbeit bei etwas, wo er sowieso schon lange mit dem Fertigwerden hadert. Features sind nicht toll – sie sind entweder notwendig oder scheiße.

[Schrompf]

Wahre Worte. Was gewinnst Du durch die Unterstützung mehrerer APIs? 3cm E-Penis in manchen Foren und zusätzliche Arbeit für Wochen und Monate. Entscheide weise.

[waigie]

Ich hoffe du bist mit meiner Stellungsnahme zufrieden, ansonsten frag nochmal :)

Auf jeden Fall und an deiner Stelle hätte ich wahrscheinlich sogar die selbe Entscheidung getroffen.

Ganz zufrieden bin ich mit der Antwort aber auch nicht. Was nichts mit deiner Entscheidung zu tun hat, sondern mit meinen heimlichen Erwartungen. Wie schon geschrieben bin ich im Moment selbst auch auf der Suche nach der richtigen API für mich, da ich in den Grafikvorlesungen der letzten Semester mal wieder Lust bekommen habe etwas in richtig Grafik/Spiel zu machen. Bei mir verhält es sich leider so, das ich seit DirectX 7/8 und OpenGL 1 keine weiteren Kenntnisse mehr gesammelt habe und daher ohne Vorkenntnisse neu anfangen muss. Daher hatte ich gehofft hier jemand zu finden der aus einer anderen Sicht das für und wieder der API beleuchtet und mir so einen weiteren Blickwinkel eröffnet.

So nun aber genug gemauelt. Die Screenshots in der Projektvorstellung zeigen ganz klar das deine Entscheidung richtig war. Du kannst nach kurzer Zeit was zeigen und es sieht verdammt gut aus.

[Zudomon]

@Krishty und Schrompf
Ihr habt so recht... vor vielen Jahren, da wollte ich auch mal gerne alle API's drin haben, so wie das Unreal 1 hatte. Die hatten sogar nen Software Renderer mit bilinearen Filter... sehr krass.
Aber irgendwie kann man dann nicht so optimiert programmieren, weil man immer für Gewährleisten muss, dass es mit jeder API geht. Ist ja genauso wie Web-Entwicklung... ich glaube, jeder Web-Entwickler würde auf die Knie fallen, wenn er nur noch für einen einzigen Browser proggen müsste.
Der Mehraufwand rechtfertigt nicht die Zeitkosten. Zumal man hinterher eh nur noch auf einer API programmieren würde und die anderen nur noch auf biegen und brechen durchschleift.

Das gleiche ist ja eigentlich auch bei Shaderprogrammierung. Oder was mir gerade noch einfällt, damals, als es noch keine Shader gab, da konnte man abfallendes Licht generieren, indem man aus einer 3D-Textur den Lichtmultiplikator las. Für die älteren Grafikkarten, die das noch nicht konnten, musste man um den gleichen Effekt zu erzielen, eine 2D Textur und eine 1D Textur zusammenrechnen und hatte so das gleiche... allerdings war das langsamer. So wird dann das, was man auf biegen und brechen auf älterer Hardware emulieren will, im Endeffekt noch langsamer.
Oder die Entscheidung, dass die Doom 3 Engine nur Stencil Schatten kann. Ich wette, dass es um einiges einfacher ging und man daraufhin alles besser optimieren konnte, als wenn jeglicher Schattentyp möglich gewesen wäre. Zumal das die Renderpipeline sehr komplex machen kann.

@waigie
Die API's kann ich dir leider nicht ausleuchten... dafür hab ich da zu wenig überblick. Da gibt es hier ne Menge Leute, die dazu kompetent was sagen können. Ich tue mich mit sowas auch schwer, also technisch korrekt auf alles zu antworten. Bin in dem Fall dann zu oberflächlich, weil es mir zu Zeitaufwendig ist, alles zu recherchieren. Da deute ich das dann alles nur immer grob an und dann bekomme ich hier haue... :evil:

[anonym]

Wahre Worte. Was gewinnst Du durch die Unterstützung mehrerer APIs? 3cm E-Penis in manchen Foren und zusätzliche Arbeit für Wochen und Monate. Entscheide weise.

Macht das nicht jeder irgendwann mal durch? Hat man das dann ein, zwei oder vielleicht noch drei mal angetan und verstanden und sind Zauber und Reiz des Unbekannten auf Ebene der Sprache verschwunden, verschieben sich die Prioritäten immer weiter hin zur zielgerichteten Entwicklung der Software.

[Krishty]

Sicher, gebe ich auch gern zu. Meine letzte Engine liegt hier immernoch mit diesem Konzept rum; irgendwann mache ich daran auch mal weiter.

[Chromanoid]

Irgendwann ist Flash & Co. so weit, dass man sich den Stress sowieso nicht mehr geben muss.

[Krishty]

Menno … ich hatte gehofft, das sei ein Smiley …

[dot]

Wahre Worte. Was gewinnst Du durch die Unterstützung mehrerer APIs?

Portabilität ;)

[waigie]

Was natürlich bei Delphi unter Verwendung der WinAPI eine sehr große Rolle spielt.

[Zudomon]

Was natürlich bei Delphi unter Verwendung der WinAPI eine sehr große Rolle spielt.

Wiso das?

[Schrompf]

Auch Portabilität ist kein Argument. Wer Multiplattform anstrebt, nimmt OpenGL. Punkt.

[dot]

Wer Multiplattform anstrebt, nimmt OpenGL. Punkt.

In einer hypothetischen idealen Welt, in der einem z.B. die Performance auf Intel on-board Grafikchips egal ist, vielleicht. Von Dingen wie Konsolen reden wir erst gar nicht...

[Tejio]

Im Hinblick auf die Portabilität würde ich sogar weitergehen als Schrompf und zu OpenGL ES raten. Das wird von iOS, Playstation 3, Android und ähnlichen unterstützt und verwendet. Ich meine gelesen zu haben, dass sogar die Xbox 360 OpenGL ES unterstützt. Den Rat gebe ich aber auch nur aus dem Lesen von verschiedenen Artikeln und nicht aus eigener Erfahrung (das kommt nach den Abschlussprüfungen...).

[Schrompf]

Wer Multiplattform anstrebt, nimmt OpenGL. Punkt.

In einer hypothetischen idealen Welt, in der einem z.B. die Performance auf Intel on-board Grafikchips egal ist, vielleicht. Von Dingen wie Konsolen reden wir erst gar nicht...

Hm, das stimmt. Intel OnBoard unter Windows mag nur mit DirectX sinnvoll zu benutzen sein, während unter Linux oder OSX an OpenGL kein Weg vorbeiführt. Ist jetzt die Frage, ob man die 6% (laut Steam) Kunden wirklich braucht, wenn man dafür die 5 bis 10% Mac/Linux-Käufer dazu bekommt. Bei den Humble Bundles sind es ja sogar noch mehr. Ist am Ende alles eine Abwägung zwischen Aufwand und Nutzen.

Ich sehe das allerdings nicht ganz so pragmatisch wie Krishty, da ich dann doch regelmäßig über Dinge stolpere, bei denen ich an der reinen Implementation noch Spaß habe. Ich würde also nicht davon abraten, wenn jemand mehrere APIs unterstützen will, nur weil er es mal gemacht haben will. Man muss sich dann aber auch der Folgen bewusst sein. Und die sind numal massiv gesteigerter Pflegeaufwand bei nur geringem Gewinn.

[dot]

Jap, natürlich ist es Mehraufwand und auch nicht immer sinnvoll/notwendig. Ich hab ja auch nur gesagt wenn man mehrere APIs unterstützt, dann erhöht das stark die Portabilität. Rein prinzipiell muss man ja auch nicht von vornherein alle Pfade auch implementieren. Es reicht ja, das System so zu bauen, dass der Renderer einfach gewechselt werden kann, sollte das mal notwendig werden. Nur sollte man das eben schon beim Design des Ganzen vorsehen, weil das nachträglich einbauen wird unter Umständen sehr viel Arbeit ;)

[Lynxeye]

[...] Rein prinzipiell muss man ja auch nicht von vornherein alle Pfade auch implementieren. Es reicht ja, das System so zu bauen, dass der Renderer einfach gewechselt werden kann, sollte das mal notwendig werden. [...]

Und genau das ist der Punkt, an dem es meistens schief geht. Die verschiedenen APIs haben dann doch öfter mal verschiedene Ansichten über die Umsetzung eines bestimmten Punkts. Entweder man baut dann ein Interface, was am Ende wieder nur eine der API gut wrappt und alles andere nur mit überproportional großem Aufwand hineingepresst werden kann, oder man muss sich von vornherein mit allen APIs auseinandersetzen, welche man unterstützen will. Eine gute Abstraktion wird nur gelingen, wenn man vorher die Spezialisierungen kennt und nicht nur die Eigenheiten einer bestimmten Spezialisierung im Kopf hat.

[dot]

Wenn du mich fragst, geht's an dem Punkt schief, wo versucht wird eine API zu wrappen. Das ist nämlich genau der falsche Ansatz, wie du ja auch schon erkannt hast. Du willst keinen API-Wrapper, sondern einen abstrakten Renderer, der eben für jede API mal implementiert wird.
Eine gute Abstraktion ist nicht darauf ausgelegt, möglichst alle Implementierungsdetails aller APIs nach Außen zu transportieren. Das widerspricht doch schon dem Grundgedanken von Abstraktion.
Eine gute Abstraktion erlaubt der Anwendung, zu tun, was sie tun muss, ohne zu wissen, wie das im Hintergrund mit API XYZ genau abläuft. Das ist Problem der Implementierung und interessiert die Anwendung nicht.
Und dann gibts nicht nur keine Probleme, sondern man spart auch den ganzen unnötigen Overhead, den so ein Alles-unter-einen-Hut-zwingen-Wrapper normalerweise mit sich bringt.
Eine gute Abstraktion ist also genau dann gelungen, wenn man die Spezialisierungen vorher nicht kennen muss. Wenn man die Spezialisierungen kennen muss, dann ist man gerade dabei, auf falscher Ebene zu abstrahieren ;)

[joggel]

Also was ich meinte sieht dann in etwa so aus:

Code: Alles auswählen

RendererOGL::setSpotLight(Punkt3D position, float oefnnungswinkel, Vector3D direction)
{
 // konkrete Implementierung mit OpenGL
}

oder

Code: Alles auswählen

RendererDX9::setSpotLight(Punkt3D position, float oefnnungswinkel, Vector3D direction)
{
 // konkrete Implementierung mit DirectX9
}

oder aber auch

Code: Alles auswählen

RendererOGL::renderMesh(Punkt3D position, Mesh aMesh)
{
 // konkrete Implementierung mit OpenGL
}

u.s.w.
Vlt. ist das Wort "Engine" oder "Render-Engine" da angebrachter.
Und ich meinte ebenfalls auch, das man nicht alle Möglichkeiten implementieren muss, sondern sich so die Möglichkeit offen hält, zum späteren Zeitpunkt, wenn man merkt DX is kacke, auf OpenGL umsteigt, indem man einen neuen konkreten Renderer schreibt, der alle Funktion unter OpenGL unterstützt die bis zu diesem Zeitpunkt in der Anwendung benutzt wurden. Das setzt eben eine abstrakte Basisklasse voraus.

Gruß

[condor]

Ja, aber das obere beispiel wäre schonmal auf d3d>=10 schlecht anwendbar, da du mit setpointlight praktisch eine fixed function pipeline emulieren musst. da würde schon so ein versuch der generischen api schwer umsetzbar sein. ich denke, man sollte sich erstmal nur für eine api entscheiden, dafür ein paar klassen entwicklen, um den umgang mit der api zu vereinfachen, ohne dabei an generische api abstraktion zu denken.

[joggel]

Ja, aber das obere beispiel wäre schonmal auf d3d>=10 schlecht anwendbar, da du mit setpointlight praktisch eine fixed function pipeline emulieren musst.

Ja, genau.
Wie man das dann bei konkreter Implementierung (OGL, DX9,DX10,DX11) umsetzt ist ja erstmal egal.

Aber trotzdem sehe ich immernoch nicht wo es die Sache jetzt (viel) komplizierter machen sollte.
Ich stelle eben durch meinen "Renderer" Funktionen bereit, die ich in der Anwendung brauche.
Gestalte aber das Benutzen so, das ich mir absolut keinen Kopf machen muss was jetzt der Renderer intern macht oder gar noch unterscheiden muss beim Benutzen der unterschiedlichen konkreten "Renderer".