ZFX + Developia

Chromanoid hat geschrieben:Ziemlich viele coole Neuerungen im Beta Release von NetBeans, wer JavaScript programmiert sollte sich das mal anschauen: http://wiki.netbeans.org/NewAndNoteworthyNB73
Für C++ Programmierer vielleicht ganz interessant: Memory usage improvements - requires 2x less memory for big projects; Parser speed and scalability improvements :)

Verwendest Du Netbeans schon länger? Bei mir hier unter Linux ist Netbeans 7.2 im Vergleich mit Windows verdammt langsam. Ist das normal? Ich habe einiges ausprobiert, z.B. das OpenJDK durch das von Oracle ersetzt, (GUI-)Einstellungen herumexperimentiert.

Ich habe gestern eine Partie C&C Tiberian Sun im Internet gespielt.

anonym hat geschrieben:

Chromanoid hat geschrieben:Ziemlich viele coole Neuerungen im Beta Release von NetBeans, wer JavaScript programmiert sollte sich das mal anschauen: http://wiki.netbeans.org/NewAndNoteworthyNB73
Für C++ Programmierer vielleicht ganz interessant: Memory usage improvements - requires 2x less memory for big projects; Parser speed and scalability improvements :)

Verwendest Du Netbeans schon länger? Bei mir hier unter Linux ist Netbeans 7.2 im Vergleich mit Windows verdammt langsam. Ist das normal? Ich habe einiges ausprobiert, z.B. das OpenJDK durch das von Oracle ersetzt, (GUI-)Einstellungen herumexperimentiert.

Seit 5.5 allerdings fast ausschließlich für java Hobbyprojekte. Unter Windows habe ich bisher keine Probleme gehabt. Unter Linux habe ich es nicht benutzt, da ich Linux nicht nutzte ;-) schade wenn das so ist. Vielleicht mal bei den Bugs schauen oder einen eintragen. Ist schließlich open source und hat eine recht aktive community. Das hast du schon gesehen http://wiki.netbeans.org/FaqSlowNetBeans ?

Chromanoid hat geschrieben:

anonym hat geschrieben:

Chromanoid hat geschrieben:Ziemlich viele coole Neuerungen im Beta Release von NetBeans, wer JavaScript programmiert sollte sich das mal anschauen: http://wiki.netbeans.org/NewAndNoteworthyNB73
Für C++ Programmierer vielleicht ganz interessant: Memory usage improvements - requires 2x less memory for big projects; Parser speed and scalability improvements :)

Verwendest Du Netbeans schon länger? Bei mir hier unter Linux ist Netbeans 7.2 im Vergleich mit Windows verdammt langsam. Ist das normal? Ich habe einiges ausprobiert, z.B. das OpenJDK durch das von Oracle ersetzt, (GUI-)Einstellungen herumexperimentiert.

Seit 5.5 allerdings fast ausschließlich für java Hobbyprojekte. Unter Windows habe ich bisher keine Probleme gehabt. Unter Linux habe ich es nicht benutzt, da ich Linux nicht nutzte ;-) schade wenn das so ist. Vielleicht mal bei den Bugs schauen oder einen eintragen. Ist schließlich open source und hat eine recht aktive community. Das hast du schon gesehen http://wiki.netbeans.org/FaqSlowNetBeans ?

Habe den Post heute mal wieder zum Anlass genommen, da ein bischen nachzuforschen und ich habe tatsächlich nach mehr oder weniger wahllosem Austesten von im Internet gefundenen JVM-Parameterkombinationen eine gefunden, die meine Probleme zumindest deutlich mindert (meine Permiere in diesem Thread :D ). Das Hauptübel dürfte damit wohl irgendwo in der Konfiguration der JVM liegen. Trotzdem vielen Dank.

Was, schon zwei Tage nichts Positives mehr? Dann will ich mal etwas beisteuern. Nach ein paar Wochen Tief macht meine Diss nun tatsächlich wieder ordentliche Fortschritte. Code und Text fließen quasi aus den Fingern, ein Ende ist absehbar :-)

Zurück von der Reise. Erster Preis für Splatter auf der Devmania :-) Und danach noch ein paar Freunde besucht, die ich seit Ewigkeiten nicht mehr gesehen habe, und an derem kleinen Familienleben mit anderthalbjähriger Tochter teilgenommen. Auch sehr schön, auch wenn es gegensätzlicher kaum sein könnte.

Jea grad das letzte Prüfungsergebnis bekommen :)

Damit ALLE Studienleistungen mit Ausnahme der Masterarbeit erledigt :)
und bei der gehts grad ganz gut vorwärts :)

@Schrompf: Wie sieht's denn mit Splatter aus? Neuigkeiten?

Wusstet ihr, dass der HLSL Compiler schon seit dem June 2010 SDK symbolisch Differenzieren kann? Gut, ich auch nicht, aber woher denn auch, denn in der MSDN steht sowas natürlich nicht; derart nebensächliche Dinge werden bestenfalls ein Jahr später so im Vorbeigehen in irgendwelchen Blogs erwähnt...
Ich frag mich ja schon lang, ob HLSL eigentlich jemals wirklich dokumentiert werden wird ... oder vielleicht sogar mal einen richtig ordentlichen Compiler bekommt ... na super, jetzt hab ich das Gefühl, dass das wohl eher doch in den Jammer Thread sollte...

Ja, ich habe aber bisher einen großen Bogen darum gemacht, zum Einen, weil der Compiler schon dann nicht immer zuverlässig ist, wenn ich den Ausgangsquelltext kenne, zum anderen weil ich dann erst im ASM sehe, was bezüglich Komplexität eigentlich nach dem Ableiten rauskommt. Der HLSL-Compiler kann im Uebrigen auch Klassen, Vererbung, Interfaces (auch zur Compilezeit ohne Dynamic Shader Linkage) und sogar Closures (iirc mit lokalen Strukturen). Aber das letzte Mal, als ich darauf gesetzt habe, war mit der naechsten Compiler-Version alles kaputt, weshalb ich mich von derart undokumentiertem Verhalten jetzt lieber fernhalte.

j.klugmann hat geschrieben:@Schrompf: Wie sieht's denn mit Splatter aus? Neuigkeiten?

Moin, und Danke der Nachfrage! Ich freue mich über das Interesse :-) Es geht gerade wieder richtig gut voran, und ich muss endlich mal neue Bilder / Videos machen, um das auch zu zeigen. Weitere Details dann im eigenen Thread.

Schrompf hat geschrieben:

j.klugmann hat geschrieben:@Schrompf: Wie sieht's denn mit Splatter aus? Neuigkeiten?

Moin, und Danke der Nachfrage! Ich freue mich über das Interesse :-) Es geht gerade wieder richtig gut voran, und ich muss endlich mal neue Bilder / Videos machen, um das auch zu zeigen. Weitere Details dann im eigenen Thread.

Sehr gerne. Ich für meinen Teil bin auch "perma-interessiert", aber man kann dich ja nicht ständig mit Nachfragen "nerven".

ACK ACK ACK.

Würde mich bei Splatter über Bilder und Gameplay-Videos und natürlich letztendlich auf das fertige Spiel freuen.

Gerade nach DirectXTex konvertiert und dabei D3DX losgeworden. Sehr schöne Bibliothek, sauber und leichtgewichtig. Es ist an alles gedacht, sogar daran, dass sich Bilder oftmals nicht korrekt als SRGB ausweisen, entsprechend hat die ScratchImage-Klasse eine Methode OverrideFormat() und der DirectX-Namespace eine Funktion MakeSRGB(format).

Hachja, Data Oriented Design ist wunderbar. Jetzt kann ich fast meine komplette Lib parallel laufen lassen. :>

struct und class sind abseits der Definition tatsächlich Synonyme. Ob class oder struct spielt für die Deklaration genauso wenig eine Rolle wie die constness von Parametern:

The class-key or enum keyword present in the elaborated-type-specifier shall agree in kind with the declaration to which the name in the elaborated type-specifier refers. This rule also applies to the form of elaborated-type-specifier that declares a class-name or friend class since it can be construed as referring to the definition of the class. Thus, in any elaborated-type-specifier, the enum keyword shall be used to refer to an enumeration (7.2), the union class-key shall be used to refer to a union (Clause 9), and either the class or struct class-key shall be used to refer to a class (Clause 9) declared using the class or struct class-key

Trotzdem warnt MSVC. Eine weitere Warnung in meiner Standard-Ignore-Liste? :-/

Die größte Schwierigkeit an datenorientiertem Design bis jetzt: Viele parallele Vektoren/Arrays synchron zu verwalten. Ich sehe bis jetzt leider keinen eleganten Weg der Automatisierung einer Structure-of-Arrays-Datenstruktur, wie man sie für Array-of-Structures mit einem einfachen std::vector<Struct> hat.

Davon abgesehen ist es tatsächlich nicht nur weniger Aufwand, Sammlungen von Objekten direkt als solche vorliegend zu verarbeiten, sondern auch kaum mehr Aufwand, diese Objekte direkt in diesen Sammlungen zu verwalten. Lästige Ein- und Austragungsschritte entfallen, auch der Besitz ist wesentlich klarer geregelt.

CodingCat hat geschrieben:Die größte Schwierigkeit an datenorientiertem Design bis jetzt: Viele parallele Vektoren/Arrays synchron zu verwalten.

Weil man genau das ja auch zu keinem Zeitpunkt will. Würde man die Daten synchron bearbeiten, lägen sie als AoS vor. Bleiben also nur Allokationen; und wie ich dich kenne, sind in der Hauptschleife längst keine mehr drin, oder?

Außerdem habe ich zu der ganzen Chose noch eine Frage:

Sagen wir, mein Rendering läuft so ab, dass ich erst culle (eine Bounding Box teste) und bei Sichtbarkeit was mit Geometriedaten (Vertex- und Indexbuffer-Zeiger oder so) mache. Lässt sich an der Stelle überhaupt noch was mit Datenorientierung machen?

Objektorientiert hätte ich das AoS [Culling, Geometrie]. Wenn ich nun eine Szene hätte, bei der sich sichtbare und unsichtbare Objekte ständig sofort abwechselten, schöbe ich sowohl die Culling-Daten als auch die Geometriedaten durch die Caches.

Mit einer SoA (Culling[], Geometrie[]) würde ich nichts mehr rausholen können, so lange die Geometriedaten kleiner als eine Cache-Zeile sind: Ein unsichtbares Objekt griffe dann zwar nicht auf das Geometriedaten-Array zu; weil sein Vorgänger und Nachfolger aber darauf zugriffen, würden die Daten trotzdem durch den Cache geschoben.

Wie könnte man das datenorientiert verbessern? Oder ist die blanke Tatsache, dass ich bei alldem die Physik- und Gameplay-Daten weggelassen habe, an sich schon Datenorientierung?

Krishty hat geschrieben:

CodingCat hat geschrieben:Die größte Schwierigkeit an datenorientiertem Design bis jetzt: Viele parallele Vektoren/Arrays synchron zu verwalten.

Weil man genau das ja auch zu keinem Zeitpunkt will. Würde man die Daten synchron bearbeiten, lägen sie als AoS vor.

Achtung, ich rede von Verwaltung, d.h. lästigen Dingen wie dem Einfügen oder Entfernen von Elementen zur Lade-/Bearbeitungszeit. Dort darfst du dann z.B. nicht eines der Arrays bei der Vergrößerung vergessen. Noch lustiger wird es mit Ausnahmesicherheit. Selbstverständlich mache ich den ganzen Tanz mit SoA nur deshalb, um anschließend bei der Be-/Verarbeitung auf echten Teilen der Daten arbeiten zu können.

Krishty hat geschrieben:Sagen wir, mein Rendering läuft so ab, dass ich erst culle (eine Bounding Box teste) und bei Sichtbarkeit was mit Geometriedaten (Vertex- und Indexbuffer-Zeiger oder so) mache. Lässt sich an der Stelle überhaupt noch was mit Datenorientierung machen?

Objektorientiert hätte ich das AoS [Culling, Geometrie]. Wenn ich nun eine Szene hätte, bei der sich sichtbare und unsichtbare Objekte ständig sofort abwechselten, schöbe ich sowohl die Culling-Daten als auch die Geometriedaten durch die Caches.

Mit einer SoA (Culling[], Geometrie[]) würde ich nichts mehr rausholen können, so lange die Geometriedaten kleiner als eine Cache-Zeile sind: Ein unsichtbares Objekt griffe dann zwar nicht auf das Geometriedaten-Array zu; weil sein Vorgänger und Nachfolger aber darauf zugriffen, würden die Daten trotzdem durch den Cache geschoben.

Wie könnte man das datenorientiert verbessern? Oder ist die blanke Tatsache, dass ich bei alldem die Physik- und Gameplay-Daten weggelassen habe, an sich schon Datenorientierung?

Datenorientiert wäre ganz einfach, zunächst alle Objekte zu cullen und im Anschluss nur die sichtbaren zu rendern. Natürlich ist das keine binäre Angelegenheit, auch die von dir angesprochene Datentrennung ist bereits eine Form von datenorientiertem Entwurf.

Wieso komme ich heute erst auf die Idee, nach einer Funktion uncaught_exception() zu suchen, die es dann auch prompt gibt? Um einen Stack Trace der wichtigsten von Exceptions durchkreuzten Funktionen zu erhalten, reicht eine triviale Hilfsklasse und ein simples Makro in denselben:
Benutzung:
Das kann ich jetzt mühsam überall dort nachtragen, wo ich es all die Jahre vermisst habe.

War mir in all den Jahren nicht klar: Folgender Code ist vollkommen korrekt.
Parameter- und Rückgabetyp müssen nur bei Aufruf und Definition vollständig bekannt sein. In der Deklaration tun es unvollständige Typen, auch by Value.

Eine äquivalente Form ohne die Pflege einer expliziten Forward-Deklarationsliste wäre:
Finde ich angenehmer zu schreiben, als immer an anderer Stelle sicherstellen zu müssen, dass die Typen auch angegeben wurden.

CodingCat hat geschrieben:Datenorientiert wäre ganz einfach, zunächst alle Objekte zu cullen und im Anschluss nur die sichtbaren zu rendern. Natürlich ist das keine binäre Angelegenheit, auch die von dir angesprochene Datentrennung ist bereits eine Form von datenorientiertem Entwurf.

Jup; darum schrieb ich unscharf, dass ich mit den sichtbaren Objekten was mache. Also habe ich zumindest nichts falsch verstanden.

1>Time Elapsed 00:00:00.87
========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ==========

Ich habe meine ganzen alten Projektdateien gelöscht und neue VS2012-Projekte aufgesetzt. Dass die Compiler-Einstellungen nun anders sind ist klar (an den alten Projekten hatte ich fast zwei Jahre rumexperimentiert); aber dass (mit VS2010) das Kompilieren im Debug-Modus 25 % schneller geht (obwohl die Clang-Kompatibilität den Quelltext hat wachsen lassen) und dass die Release-Version 2 % schneller läuft und ebensoviel kleiner ist, verblüfft mich dann doch. Schön, wenn der Herbstputz was bringt.

Krishty hat geschrieben:

CodingCat hat geschrieben:Datenorientiert wäre ganz einfach, zunächst alle Objekte zu cullen und im Anschluss nur die sichtbaren zu rendern. Natürlich ist das keine binäre Angelegenheit, auch die von dir angesprochene Datentrennung ist bereits eine Form von datenorientiertem Entwurf.

Jup; darum schrieb ich unscharf, dass ich mit den sichtbaren Objekten was mache. Also habe ich zumindest nichts falsch verstanden.

Jetzt weiß ich erst recht nicht mehr, was genau du meintest. Im Extremfall machst du eben nichts mit den ausgewählten Daten, sondern referenzierst/selektierst sie nur für einen subsequenten Datentransformationsschritt (z.B. Rendering), in welchem du dann tatsächlich etwas mit den Daten machst.

Ich schubse sie in einen Puffer, von dem aus ich im nächsten Schritt rendere.

Gut. ;)

Übrigens habe ich dadurch erst den Sinn von Bindless Textures verstanden: Rein objektorientiert hätte man hier wieder das absolut Cache-vernichtende Verhalten, dass die Render-Daten mitunter aus einem Textur-Zeiger bestehen, den die Grafik-API erstmal dereferenziert, um davon zu lesen, was sie in den Command Buffer der GPU schreiben soll. Bindless entfällt das.

Normalerweise habe ich Sicht über das halbe Ruhrgebiet; heute ist die Luft aber so neblig, dass sie im milchigen Schein der Großstadt fast taghell zu glühen scheint.

Man tritt heraus und der Himmel leuchtet hellblau, türkis und dunkelrot. Weil die Nuancen so weich sind, scheint das Licht der Luft innewohnend zu sein. Wirklich außergewöhnlich.

————

DXGI.h ist in mein Framework kopiert und dabei absolut entschlackt. Keine Auswirkung auf Kompilierzeit. Jetzt ein paar Wrapper schreiben, dann weiter zu D3D11.h.

Endlich! Ich habe zum ersten Mal Lambdas eingesetzt! Früher:

    namespace {
        __forceinline // hat nur einen Aufrufer; aber das kapiert VC wohl nie
        IDXGIFactory & create() {
            IDXGIFactory * retval;
            CreateDXGIFactory(…, &retval);
            return *retval;
        }
    }

    class DXGIFactory {
        IDXGIFactory & myFactory;
    public:
        DXGIFactory()
            : myFactory(create())
        { }
    };

heute:

    class DXGIFactory {
        IDXGIFactory & myFactory;
    public:
        DXGIFactory()
            : myFactory([]() -> IDXGIFactory & {
                IDXGIFactory * retval;
                CreateDXGIFactory(…, &retval);
                return *retval;
            }())
        { }
    };

Wie wunderschön und lesbar das ist! Und wie stolz ich bin, so wundervolle Schnittstellen von Microsoft nutzen zu dürfen, die nur Ausgabeparameter kennen! Fast so gut wie die eine Bibliothek, deren Array<>::begin() einen Smart-Pointer auf die IObject-Basisschnittstelle eines dynamisch allokierten Iterators zurückgibt!

Krishty hat geschrieben:    class DXGIFactory {
        IDXGIFactory & myFactory;
    public:
        DXGIFactory()
            : myFactory([]() -> IDXGIFactory & {
                IDXGIFactory * retval;
                CreateDXGIFactory(…, &retval);
                return *retval;
            }())
        { }
    };

Kleine Korrektur:

: myFactory([]() -> __forceinline IDXGIFactory & {

Ich scheine bei Microsoft einen Seelenverwandten zu haben … oder wie viele Menschen auf der Welt sind pedantisch genug für sowas? Aber vielleicht ist es auch nur ein Bug.