ZFX + Developia

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.

Immer diese analogen Leute … MSPaint für Skizzen, Windows-Taschenrechner für Binär- und Hexadezimalgeraffel, Notepad++ für Notizen … sporadisch auch HxD um Kompilate und binären Output zu checken … und die Hand immer in Wartestellung über Alt+Tab. Einen Stift hatte ich seit bestimmt zwei Monaten nicht mehr in der Hand.

Krishty hat geschrieben:Immer diese analogen Leute … MSPaint für Skizzen, Windows-Taschenrechner für Binär- und Hexadezimalgeraffel, Notepad++ für Notizen … sporadisch auch HxD um Kompilate und binären Output zu checken … und die Hand immer in Wartestellung über Alt+Tab. Einen Stift hatte ich seit bestimmt zwei Monaten nicht mehr in der Hand.

Habe ich in der Uni auch so gemacht … um dann eines Tages feststellen zu müssen, dass Windows Update trotz meiner expliziten Einstellung den Rechner neugestartet hat (dabei können nur Anwendungen mit sichtbaren Fenstern ein Veto gegen den Neustart aussprechen, und ich hatte den Editor minimiert). Konsequenz: Wenn es geht, alles in ein paar Notepad-Fenster reinschreiben, die man mindestens einmal explizit abgespeichert hat.

Obwohl ich ein Tablett+Stift habe finde ich Kuli+Karopapier immer noch schneller und flexibler als skizzieren am PC.

Ich denke dass Stift und Papier nicht so schnell aussterben werden. Ich zumindest mache immer wieder Gebrauch davon. Das gute daran ist, man kann Probleme lösen auch wenn die Kiste mal nicht läuft (zB irgendow draussen auf der Terrasse) Und das Ganze 3D Zeugs ist ja nichts anderes als gute alte Vektorgeometrie, im Prinzip wie damals Mathe Aufgaben lösen ;-)