ZFX + Developia

@ downhilefor

Thx

MfG GamerZ

GamerZ hat geschrieben:@ downhilefor

Thx

MfG GamerZ

Aber stell dir das benutzen einer GUI nicht so einfach vor ^^
Ich kenne keine GUI, die nicht Objektorientiert arbeitet und um das System zusammen mit den Pointern ect zu lernen ist echt ne lange Zeit vergangen. Vor allem das mit den Pointern hat mich anfangs echt nerven gekostet, aber jetzt ist das kein Problem mehr und ich benutze sie intuitiv.

Das wichtigste ist du solltest wirklich ausprobieren und nicht nur alles abschauen und anhacken.

Also setz dich hin und mach ne kleine funktion ^^

Hi , Community bin wieder da ^^

Hab eine Frage:

Bei Algebra kann man dass schriftlich aussrechnen oder geht es nur mit dem Taschenrechner?

MfG GamerZ

Alles was der Taschenrechner kann sollte man auch irgendwie mit Stift und Papier hinbekommen ;)

alles eine Frage der Arbeit die man hinensteckt ;)
um was gehts denn genau?

Ich meine in der Game Engine entwicklung :D

wollte es nur wissen ist es aber per hand nicht kompliziert ?
Währe Per hand besser oder per Taschenrechner?

MfG GamerZ

Auch da kommt es drauf an worauf die hinauswillst

Willst du irgendwelche Zahlen berechnen ist der Taschenrechner moeglicherweise ein gutes Mittel
Willst du Gleichungen herleiten oder dir einen Algo ausdenken ist es wohl besser die Umformungen mit der Hand zu machen ;)

Weil nur was man versteht kann man auch effizient selber programmieren

Danke dir.

Mfg GamerZ :D

...

Hab eine Frage ist dass:

NVIDIA SDK
http://developer.nvidia.com/object/sdk-9.html

was ganz anderes als dass DirectX SDK
http://www.microsoft.com/downloads/deta ... 8a3ba730ba

oder sind die identisch und dass von Microsoft ist fortgeschrittener ?

Wofür dient dass NVIDIA SDK und dass Microsoft SDK ?


hoffe ihr könnt mir weiterhelfen.

MfG GamerZ

Das Microsoft SDK stellt DirectX samt Dokumentation und Tools bereit. Das Nvidia SDK enthaelt Nvidia-spezifische Tools und APIs, die groesstenteils Hacks der D3D bzw. OpenGl APIs darstellen, sprich auf diesen aufbauen.

Eigentlich brauchst du nur das MS-SDK.

Warum Eigentlich ? :oops:

MfG GamerZ

Weil die Sonderfeatures des Nvidia-SDKs nur auf NVIDIA Hardware funktionieren. Genau das gleiche mit AMD. Vielleicht schaffst du es zwar damit die Qualitaet oder Performance zu erhoehen, benoetigst (damit es Sinn macht) aber eine ausgezeichnet optimierte Direct3D/OpenGl Basis und musst dann zwei Renderpfade fuer voellig verschiedene Hardware pflegen.

Fuer Hobbyzwecke ist das IMHO zu viel Aufwand und somit ein Garant fuer das Scheitern des Projektes :-)

Achja, zu exploid (auch wenn es schon laenger her sein mag):

Der Weg endet dabei
niemals sondern windet sich fortwährend durch die Hügel des Maschinencodes, über die Pässe der eisverhangenen
Gletscherberge der C-Programmierung und wieder zurück in die düsteren Katakomben der C++ Programmierung.
Manchmal führt er über die sanften Hügellandschaften der programmiertechnischen Konzepte. Doch fortwährend hat
man das Gefühl das hier Magie am Werk ist.

J.R.R. Tolkien haette es nicht besser ausdruecken koennen.

Danke Aramis :)

MfG GamerZ

Hab nicht den gesamten Thread gelesen, aber trotzdem ein Tipp von mir: Versuch keine Engine zu bauen, sondern mach lieber zuerst Spiele. Eine Engine kristallisiert sich ganz von alleine heraus, und um ganz ehrlich zu sein:
1. hast du höchstwahrscheinlich nicht genug Erfahrung eine ordentliche Architektur auf die Beine zu stellen
2. sollte man eine Engine nicht basteln nur damit man eine Engine gebastelt hat. Wenn du eine zündende Idee hast wie entscheidende Teile einer typischen Engine viel besser gemacht werden könnten..nur zu, versuch zu verbessern. Aber bloß das zu kopieren versuchen was tausende andere machen ist etwas wenig. Das nötige Grundlagenwissen erlernst du auch in der Spieleentwicklung wenn du genügend abstrahierst.

Das stimmt zwar, aber es gibt sachen, die man selten aus dem programmieren von Spielen lernt:

Eine richtige Engine müsste in unterschiedlichsten Projekten verwendet werden können, ohne etwas am Code ändern zu müssen.
Bei sowas hätte ich schon etwas zu kämpfen, wenn ich einfach so aus dem Nichts plötzlich mit statischen und dynamischen biblioteken arbeiten müsste und ein Interface designen müsste ohne hilfestellungen zu erhalten.

Es ist zwar möglich, aber wenn man solche Grundlagen aus zweiter Hand lernt, dann verliert das Programmieren der eigenen Engine erheblich an Frustfaktor.

Hi Leute,

Ich lese manchmal in Foren von Low-Level Programmierung was bedeutet dass?
Wikipedia hilft nicht weiter.

MfG GamerZ

Wirklich nicht? http://en.wikipedia.org/wiki/Low-level

Generell meint man mit »high-level« eine höhere Abstraktionsebene und mit »low-level« eben eine tiefere, wobei die Begriffe auf viele verschiedene Teilbereiche angewandt werden können. Ein typisches Beispiel ist die Speicherverwaltung: Während du dich in C in der Regel selbst darum kümmerst, Speicher zu allozieren und wieder freizugeben, kannst du diese Arbeit auch einem Garbage Collector überlassen, und damit »more high-level« arbeiten. Auch die verwendeten Bibliotheken sind oft damit gemeint – WinAPI und DirectX sind gegenüber Qt und einer Engine low-level.

Ok habs verstanden Danke.

MfG GamerZ

Herror hat geschrieben:Eine richtige Engine müsste in unterschiedlichsten Projekten verwendet werden können, ohne etwas am Code ändern zu müssen.

Wenn man wirklich an diesem Kriterium festhält, dann ist man ziemlich limitiert. In der Praxis sollte die Engine halbwegs vernünftig anpassbar sein, das inkludiert Modifikationen am Code. So gut wie alle kommerziellen Spiele mit eingekaufter Engine haben diese angepasst. Eine monolithische Alleskönnerengine ist eine Illusion.

Idealerweise müsste man tatsächlich den bestehenden Quellcode nicht ändern, sondern nur erweitern - Open/Closed Principle. DIe Frage ist allerdings, in wie weit bei einer Engine in der Praxis solche OO-Prinzipien zu Gunsten von anderen Zielen unter den Tisch fallen gelassen werden...

VizOne hat geschrieben:Idealerweise müsste man tatsächlich den bestehenden Quellcode nicht ändern, sondern nur erweitern - Open/Closed Principle. DIe Frage ist allerdings, in wie weit bei einer Engine in der Praxis solche OO-Prinzipien zu Gunsten von anderen Zielen unter den Tisch fallen gelassen werden...

Ich halte das für eine gefährliche Ansicht. In Maßen ist sie natürlich richtig und sinnvoll, sie tendiert aber quasi zu einem Dogma zu werden. Dann hat man eine Codebase, die klar definierte Stellen für Erweiterungen hat, und sonst aber starr und inflexibel ist, wenn ein Use Case sich nicht auf besagte Stellen trivial abbilden lässt. Beispiel: eine Texturklasse, die davon ausgeht, dass man stets nur LDR-Pixelformate einsetzt. Man kann sie problemlos erweitern, wenn aber HDR-Formate benötigt werden, fällt das Design in sich zusammen. Oder wenn man die Engine um einige neue Features erweitern will, die im Kernverhalten des Renderings eingreifen, zB einführung von multithreaded rendering, Geometrieshader, OpenGL transform feedbacks usw. Solche Features können das Design einer Engine schnell zusammenhauen, und sind nicht wirklich vorhersagbar.

Daher versuche ich bei meinen Sachen, ein modulares, sauberes Design einzuhalten, ohne dass Änderungen - falls diese notwendig werden - unnötig schwierig sind. Zu diesem Zweck sei das Stichwort "generisches Programmieren" genannt.

Klar definierte Schnittstellen für Erweiterungen bedeuten nicht starren und unflexiblen Code zu haben. ^^
Das steht und fällt alles mit den Anforderungen und dem Design.

Wenn Dein Design wegen neuer Anforderungen völlig zusammen fällt, dann war das Design nicht gut, oder das Design war gut aber die Umsetzung grauenvoll.

odenter hat geschrieben:Klar definierte Schnittstellen für Erweiterungen bedeuten nicht starren und unflexiblen Code zu haben. ^^
Das steht und fällt alles mit den Anforderungen und dem Design.

Wenn Dein Design wegen neuer Anforderungen völlig zusammen fällt, dann war das Design nicht gut, oder das Design war gut aber die Umsetzung grauenvoll.

Du kannst noch so gut designen, die Zukunft kannst du nicht vorhersagen. Bei jedem Design musst du irgendwo Kompromisse und Annahmen machen. Wenn du später an solchen Fundamenten rüttelst, wirds kritisch. Ein Renderer von 1998 wird ganz andere Annahmen gemacht haben als einer von 2010: ersterer wird zB schauen, dass jedes Dreieck geclippt wird, es null Overdraw gibt usw. während letzteres auf Dinge wie Minimierung von API-Aufrufen und Fillrate achten wird. Levelstrukturen von 98 sind heutzutage unbrauchbar usw.

Kurz gesagt, ein Design, welches alle nur denkbaren Anforderungen erfüllt, und auch bis in alle Ewigkeit erfüllen wird, ist reine Phantasie. Ich kann zB jetzt nicht mal eben Voxel malen mit der UE3, ist das UE3-Design jetzt schlecht?

dv hat geschrieben:

odenter hat geschrieben:Klar definierte Schnittstellen für Erweiterungen bedeuten nicht starren und unflexiblen Code zu haben. ^^
Das steht und fällt alles mit den Anforderungen und dem Design.
Wenn Dein Design wegen neuer Anforderungen völlig zusammen fällt, dann war das Design nicht gut, oder das Design war gut aber die Umsetzung grauenvoll.

Du kannst noch so gut designen, die Zukunft kannst du nicht vorhersagen. Bei jedem Design musst du irgendwo Kompromisse und Annahmen machen. Wenn du später an solchen Fundamenten rüttelst, wirds kritisch. Ein Renderer von 1998 wird ganz andere Annahmen gemacht haben als einer von 2010: ersterer wird zB schauen, dass jedes Dreieck geclippt wird, es null Overdraw gibt usw. während letzteres auf Dinge wie Minimierung von API-Aufrufen und Fillrate achten wird. Levelstrukturen von 98 sind heutzutage unbrauchbar usw.

Wenn ich die Zukunft voraussagen könnte, würde ich hier nicht mehr posten sondern unter Palmen liegen.
Annahmen zu machen ist ganz schlecht, denn diese sind im Zweifel falsch. Und wer an seinem Konzept rüttel muss hat wohl ganz offensichtlich etwas falsch gemacht.

Da kann ich noch soviel mit Templates oder Generics arbeiten, es hilft nichts.

dv hat geschrieben: Kurz gesagt, ein Design, welches alle nur denkbaren Anforderungen erfüllt, und auch bis in alle Ewigkeit erfüllen wird, ist reine Phantasie. Ich kann zB jetzt nicht mal eben Voxel malen mit der UE3, ist das UE3-Design jetzt schlecht?

Wasn das für ne Frage? Ist das Design eines Autos schlecht weil es nicht fliegen kann?
Nein natürlich nicht, weil fliegen nicht Teil der Anforderungen an ein Auto war. ^^
Wenn ich aber Eigenschaften des Autos verändern will, und dafür das ganze Konzept Auto ändern muss, dann ist mein Konzept Auto Scheisse.

Nun ja, wenn der Motor deines Autos plötzlich mit Wasserstoff statt mit Benzin betrieben werden muß, das neue Design des Motors aber andere Schnittstellen zu Getriebe, Tank ( nun gekühlt ), Elektronik etc. erfordert, dann brechen Teile des alten Designs des Benzin-Autos in sich zusammen. Das Redesign ist mit Arbeit verbunden, die tiefgreifend in die Architektur eines Autos eingreifen. Deswegen erfordern Technologiewechsel ja oft auch so lange Lernzeiten vonden Entwicklern ( auch in der Automobil-Industrie ), bis sie all die auftretenden Probleme im Griff haben. Trotz dessen werden Automobil-Entwickler nicht auf Räder verzichten.
Hier hinkt dein Vergleich ;).

Gruß Kimmi

odenter hat geschrieben:Annahmen zu machen ist ganz schlecht, denn diese sind im Zweifel falsch. Und wer an seinem Konzept rüttel muss hat wohl ganz offensichtlich etwas falsch gemacht.

Ohne Annahmen kannst du aber nicht arbeiten. Das geht in zwei Richtungen: mögliche zukünftige Entwicklungen (die JEDES Design kaputtmachen können, siehe mein Rendererbeispiel), und Mindestanforderungen. Besagte UE3 braucht Shader zB, das UE3-Design bricht zusammen, wenn keine Shader vorhanden sind. Es wird also angenommen, dass Shader verfügbar sind. Nochmal: ist das UE3-Design deswegen schlecht?

dv hat geschrieben: Nein natürlich nicht, weil fliegen nicht Teil der Anforderungen an ein Auto war. ^^
Wenn ich aber Eigenschaften des Autos verändern will, und dafür das ganze Konzept Auto ändern muss, dann ist mein Konzept Auto Scheisse.

Dann ändert sich die Definition von Auto, und man erwartet eben schon das es fliegt ...
Oder etwas realistischer: ein Elektroauto bricht mit einer Menge Sachen, die bei einem Auto bisher als üblich gegolten haben. Das interne Design ist ganz anders.

Um das ganze wieder auf die Engines zurückzubringen: sowas wie ein Renderer altert nunmal. Wenn einer zu alt ist, ersetzt man ihn durch einen neuen. Auf Gameplay-Level altert Code viel langsamer bis gar nicht, daher kann man auf hohem Level eine Engine haben, bei der der Renderer ein Modul ist zB. Ich denke da an MVC-Style Designs, wobei ein Renderer nur eine View ist. Aber auch hier gilt: heutzutage kann so ein Design flexibler sein als zB 1995, weil wir viel mehr CPU-Power zur Verfügung haben. 1995 waren Engines notwendigerweise großteils hardcodiert und nicht sehr sauber.

Also das Wort Annahmen gefällt mir überhaupt nicht. (An dem UE3 Beispiel)
Wenn Shader Vorraussetzung sind dafür das eine Engine funktioniert, dann ist das in Ordnung. Wenn ich jetzt keine Shader habe, dann bricht aber nicht das Konzept oder Design der UE3 zusammen, sondern mein eigenes sofern ich mich unter eben diesen Bediungen für die UE3 entschieden habe.
Zumal der Umstand noch nichts darüber aussagt (ich jedenfalls kann das nicht beurteilen) wie einfach die UE3 um Shader erweiterbar wäre/ist, erst dann könnte man sagen ob das Design gut oder schlecht ist.

Eine Annahme wäre z.B. der User wird sicher nie zwei Tasten gleichzeitig drücken, oder es werden nie mehr als 10.000 Objekte gleichzeitig verwendet. Das sind Annahmen die im Zweifel falsch sind. Irgendwann kommt ein User drückt zwei Tasten gleichzeitig und Dein Programm ribbelt ab, weil Du angenommen hast es wird immer nur eine Gedrückt.
Genauso wäre die Annahme es sind immer Shader vorhanden falsch und ganz klar ein Programmfehler.

Der Renderer kann von mir aus jährlich altern, wenn ich das weiss dann berücksichtige ich das in meinem Design und gut. Es gibt mitlerweile Design-Patterns für praktisch jedes Problem und es lässt sich sogut wie alles lose koppeln, Kapselung ist die universal Waffe. :)
Natürlich gilt das ganze nur für aktuelle/neue Projekte, mir ist schon klar das man "neue" Konzepte nicht auf alte Projekte anwenden kann. Zumal "damals" eher Prozedural'er Code geschrieben wurde, aber heute ist halt OO angesagt.

Wer wegen jeder Änderung sein halbes Programm (egal um welche Art Programm es sich handelt) umstricken muss, macht defenitiv etwas falsch.

Es gibt mindestens ein sehr gutes Bucher zu dem Thema (OOAD):
http://www.amazon.de/Objektorientierte- ... pd_sim_b_2
Das Buch mit den Entwurfsmustern von denen ist auch sehr gut, sowie die Bücher der clean code developer initiative.

Hi Leute,

Ich hab eine Frage:

Was benutzt ihr beim Programmieren z.B in 3D (außer dass ihr eine Programmiersprache beherrscht)
Taschenrechner?

MfG GamerZ

Java, schwarz.
Papier, weiss und voellig un-oeko.
Bleistift, graphitgrau.
Brain, vorwiegend grau-braun-gelblich.

Bei mir isses mehr der Herr Jacobs, hellbraun. Papier und Stift sind allerdings ebenso unerlässliche Hilfsmittel. Selten gebraucht, aber wenn dann dringend. "Brain" ist optional, das ist völlig veralteter Mist, der sehr tausenden Jahren nicht mehr aktualisiert wurde.