|
2 registered members (Quad, TipmyPip),
6,316
guests, and 3
spiders. |
|
Key:
Admin,
Global Mod,
Mod
|
|
|
Re: Grafix vs. Gameplay
[Re: Wicht]
#186062
02/27/08 15:50
02/27/08 15:50
|
Joined: Nov 2004
Posts: 7,121 Potsdam, Brandenburg, Germany
Machinery_Frank
Senior Expert
|
Senior Expert
Joined: Nov 2004
Posts: 7,121
Potsdam, Brandenburg, Germany
|
Das hängt einfach davon ab, was wir als "Entwickler" definieren. Wenn einer ein Tools-Entwickler ist, dann ist das voll okay, wenn wir aber Spiele machen wollen, sieht es anders aus.
Es ist ja wirklich so, dass einige Projekte alle Tools selbst entwickeln, aber diese Projekte sind eher bei Ogre zu finden (siehe Deck13). Da nutzt man einfach den besten ("bezahlbaren") Renderer und entwickelt dann die Tools. Deck 13 hätte ja auch A6 nutzen können. Aber aus guter Quelle weiß ich, dass die z.B. über das 2. UV-Set der Modelle Lightmaps rendern und dass die Shader einsetzen, sieht jeder selbst an "Ankh" oder "Jack Keane".
Da kommen wir also zu einem anderen Punkt: Warum sind die meisten hier? Warum nicht bei Ogre? Ganz klar, wegen der Tools. Es heißt ja auch GameSTUDIO. Diese Tools machen das Konzept aus. Wenn ihr jetzt sagt, wir coden die alle selber, treibt ihr die Leute mit offenen Armen zu Irrlicht, Ogre, TrueVision und co.
Models, Textures and Games from Dexsoft
|
|
|
Re: Grafix vs. Gameplay
[Re: Machinery_Frank]
#186063
02/27/08 15:52
02/27/08 15:52
|
Joined: Apr 2005
Posts: 4,506 Germany
fogman
OP
Expert
|
OP
Expert
Joined: Apr 2005
Posts: 4,506
Germany
|
Nein, weil ich da wesentlich mehr Low Level Kram habe, wenn ich einen Editor entwickeln will, der zu meinen Ansprüchen passt. GS ist für mich der goldene Mittelweg sozusagen. Ich nehme dankbar jede Hilfe an, die zum GS Paket gehört. Aber wenn etwas nicht dabei ist, mache ich es selbst. Ich warte nicht ein Jahr darauf und wende mich dann enttäuscht ab.
no science involved
|
|
|
Re: Grafix vs. Gameplay
[Re: mk_1]
#186067
02/27/08 16:11
02/27/08 16:11
|
Joined: Nov 2004
Posts: 7,121 Potsdam, Brandenburg, Germany
Machinery_Frank
Senior Expert
|
Senior Expert
Joined: Nov 2004
Posts: 7,121
Potsdam, Brandenburg, Germany
|
Naja, Irr-Edit ist so schlecht auch nicht. Er rendert tolle Schatten auf statische Meshes sogar mit Radiosity. Das kann der WED noch nicht.
MED und SED Alternativen gibt es nicht, aber dafür gibt es kostenlose C++ Compiler und sogar die Projekt-Dateien dafür mit super einfachen Tutorials. Ich habe die auf Anhieb als C++ Anfänger verstanden, liegt aber auch daran, dass die API von Irrlicht "irre" einfach und logisch ist.
Aber das führt vom Thema weg. MED und WED sind doch heute gar nicht mehr so wichtig. Viele erstellen die Level als Modelle in externen Editoren. Die Tools die fehlen, sind gute Material-Editoren und in-Game real-time Editoren. Das alles gilt allerdings nur, wenn wir von 3d-Projekten reden. Bei einem 2d-Puzzle ist das nicht so wichtig.
Models, Textures and Games from Dexsoft
|
|
|
Re: Grafix vs. Gameplay
[Re: mk_1]
#186068
02/27/08 17:18
02/27/08 17:18
|
Joined: Sep 2003
Posts: 5,900 Bielefeld, Germany
Pappenheimer
Senior Expert
|
Senior Expert
Joined: Sep 2003
Posts: 5,900
Bielefeld, Germany
|
Quote:
Wenn du Lite-C als Lowlevel bezeichnest... Mit Irrlicht habe ich ne API, die nahezu genauso einfach ist, mir aber hundert mal mehr Möglichkeiten bietet. Stimmt wohl, dass da einige Dinge fehlen, aber dazu gibt's ja die netten Leute aus dem Forum. Ich hab inzwischen (gameplaytechnisch) schon mehr erreicht als ich mit Acknex je bei einem solchen Spiel hätte schaffen können.
Mich würde ja interessieren, welche Dinge bei der Irrlicht fehlen und welche Sachen Du erreichen konntest, die Du mit Acknex nie erreicht hättest. (Bitte nicht als Polemik verstehen, interessiert mich wirklich! Aber bitte mehr für einen Laien formulieren, der nichts von C++ versteht! )
|
|
|
Re: Grafix vs. Gameplay
[Re: Pappenheimer]
#186070
02/27/08 17:45
02/27/08 17:45
|
Joined: Dec 2000
Posts: 4,608
mk_1

Expert
|

Expert
Joined: Dec 2000
Posts: 4,608
|
Quote:
Quote:
Wenn du Lite-C als Lowlevel bezeichnest... Mit Irrlicht habe ich ne API, die nahezu genauso einfach ist, mir aber hundert mal mehr Möglichkeiten bietet. Stimmt wohl, dass da einige Dinge fehlen, aber dazu gibt's ja die netten Leute aus dem Forum. Ich hab inzwischen (gameplaytechnisch) schon mehr erreicht als ich mit Acknex je bei einem solchen Spiel hätte schaffen können.
Mich würde ja interessieren, welche Dinge bei der Irrlicht fehlen und welche Sachen Du erreichen konntest, die Du mit Acknex nie erreicht hättest. (Bitte nicht als Polemik verstehen, interessiert mich wirklich! Aber bitte mehr für einen Laien formulieren, der nichts von C++ versteht! )
Aber gerne. Was mir fehlt, ist eine ordentliches Grafikmanagement. Dadurch, dass Irrlicht crossplatform entwickelt wird (win32/64, Linux, MaxOS), ergeben sich gewisse Komplikationen. Nach Möglichkeit sollte nämlich alles sowohl mit DirectX als auch mit OpenGL laufen. Tut es aber nicht immer, ist ja auch logisch. Wenn in oGL also etwas nicht funktioniert, dann wird es auch für DX erstmal nicht eingebaut. Besonders was Shader angeht, ist da noch eine Menge zu tun. Das wird zwar in den nächsten Versionen behoben, aber da die nunmal nur als Hobby dran arbeiten, dauert das was länger. Andererseits gibt es natürlich die Möglichkeit, die Engine selber zu erweitern, weil der Sourcecode offenliegt.
Vorteil ist ganz klar C++. C-Script war zum Kotzen, weil es nicht mal Strukturen gab. Mit Lite-C sieht das alles schon anders aus, aber wie du schon gehört hast, dauern die Compile-Zeiten ewig lange. Gelobt sei ein Linker und den gab's bei C(++) schon immer. Kurz: ich kann schnell arbeiten, bin flexibel und was vor allem wichtig ist: ich kann meine Komponenten selber aussuchen. Ich muss mir keine Gedanken machen, ob EAX unterstützt wird oder nicht, ich suche mir einfach eine Library im Netz und baue sie ein.
2. Sache: Acknex ist flexibel, aber da ist auch ein Nachteil. Mein Programm ist überladen mit unnützem Zeug, das nicht benötigt wird. In der eigenen Engine sind nur Sachen, die ich wirklich brauche => Speedup
3. Ich kann meine eigenen Meshes zur Laufzeit erstellen. Beispiel: Worms3D oder Red Faction. Das ist mit Acknex nicht möglich, weil ich dort gezwungen bin, alles auf Modellen aufzubauen.
|
|
|
Re: Grafix vs. Gameplay
[Re: mk_1]
#186071
02/27/08 18:34
02/27/08 18:34
|
Joined: Jul 2001
Posts: 6,904
HeelX
Senior Expert
|
Senior Expert
Joined: Jul 2001
Posts: 6,904
|
Das ist jetzt nicht persönlich - aber bis auf das "einfache" selber-erzeugen von Meshes sehe ich keinen Vorteil, zumal einige Punkte falsch dargelegt sind. C++ kannste mit Gamestudio auch übers SDK benutzen. Ich meine, wo ist der Punkt? Hohe Compilerzeiten? Soweit ich weiß gibt es nur 2 oder 3 aktuelle Projekte die daran leiden und afaik sind dies stumpfe C-Script "Portierungen" ohne Ausnutzen der Features, die C bietet. Zu den Komponenten.. ich meine.. kannste dir doch alles auch in Gamestudio einfügen, wenns nicht ANSI C ist, dann eben als DLL kompilieren und wrapper functions schreiben. Aber ich will Irrlicht nicht verteufeln, ich finde diese engine nämlich auch symphatisch. Die Sache ist ja auch die, dass du damit klar kommst und etwas "produzieren" kannst und das ist die Hauptsache.
A7 ist übrigens keine Grafikengine, sondern eine gameengine. Das ist ein signifikanter Unterschied, denn es ist alles darauf getrimmt, den Code für das Initialisieren der engine und den diversen Verwaltungsgeschichten zu minimieren und den Code, den man fürs Spiel schreibt, zu maximieren. Es ist erstaunlich, dass du selbst mit 3 Zeilen Code schon was auf den Bildschirm zaubern kannst. Ähnliches Prinzip verfolgt ja auch XNA, wobei dort für meinen Geschmack immer noch zu viel engine-Gedöns drin ist.
Was ist eigentlich Ziel dieses Threads? Also.. geht es hier darum nur Infos einzuholen was Leute denken, ein Proposal (mal wieder) an Conitec oder bestimmte Dinge herausarbeiten, die man mal programmieren sollte (allerdings wäre dies dann ja ein Workflow-Thread), oder wie oder was.
|
|
|
|