ZFX + Developia

Verfasst: **18.05.2012, 20:55**

Man kommt ja doch nicht drumrum: Debug Kernels mit Farbkodierung. Grün heißt korrekt. Nichts geht. Jetzt beginnt der Spaß. Zurück in den Jungle von Resource Bindings.

: Green means correct

Verfasst: **18.05.2012, 21:08**

Dürfte ich eigentlich fragen, ob du die GUI (auch irgendwo auf einem älteren Screenshot besser zu sehen; hier nur in der unteren linken Ecke zu sehen) selbst programmiert hast, oder irgendeine Library dafür benutzt hast?

Verfasst: **18.05.2012, 21:25**

Dürfte http://www.antisphere.com/Wiki/tools:anttweakbar sein. Hab ich auch damals für den Aufbaustrategiebeitrag vom dritten Zfx-Action benutzt.

Verfasst: **19.05.2012, 01:04**

Ja, Jonathan hats erkannt.

Verfasst: **19.05.2012, 21:09**

Warum scheißt einem C++ in die Suppe, wenn man es gerade am wenigsten gebrauchen kann? (Ich frage mich eher, warum ich jetzt erst auf dieses Problem stoße.)

Achja, unique_ptr<void> geht natürlich auch nicht, aber das hätte ich auch nicht erwartet, sondern wäre vom Gegenteil überrascht gewesen. Ist auch besser so.

Verfasst: **20.05.2012, 00:19**

C++/CLR um WPF Applikationen zu schreiben, die auch mal die Windows.h brauchen.

Code: Alles auswählen

mWindow->FindResource("something");

compiled nicht, da es ein

Code: Alles auswählen

#define FindResource FindResourceW

in der Windows.h gibt.
Ja, man kann es undefinen. Toll ist das trotzdem nicht.

Verfasst: **20.05.2012, 10:45**

Artificial Mind hat geschrieben: Ja, man kann es undefinen. Toll ist das trotzdem nicht.

Also ich kenn nix schlimmeres, als die windows.h. Wenn auf einmal dein Vectorklassen-min-Template nicht mehr kompiliert wegen einer komischen Meldung die du nicht verstehst, ist das echt so ziemlich das nervigste, was es gibt. Kann man sich drüber aufregen, nützt aber wohl nichts. Wenn man den Fehler einmal kennt, kann man ihn ja auch recht schnell beheben.

Verfasst: **20.05.2012, 10:46**

CodingCat hat geschrieben:Ja, es sei denn, du begnügst dich mit Forward Declarations der Rasterizer-Implementierungen und freien Funktions-Templates. :|

Freie Funktionen waren mit dem Rasterizer außerordentlich hässlich, darum habe ich das Folgende gemacht, was ich einfach mal Krishty's static single-overridden virtual method dispatching-Muster nenne:

// Rasterizer.hpp
class Rasterizer {
public:
void draw(…); // NICHT virtual
};

// Rasterizer.cpp
// Leer!

// Model.cpp
void drawModel(Rasterizer & r) {
r.draw(…);
…
}

// D3D9Rasterizer.hpp
class D3D9Rasterizer : public Rasterizer {
public:
void draw(…); // immernoch nicht virtual
};

// D3D9Rasterizer.cpp
void D3D9Rasterizer::draw(…) {
// Mein Sorgenkind
}

// Die Magie!
void Rasterizer::draw(…) {
return static_cast<D3D9Rasterizer *>(this)->draw(…); // this is gonna be so inlined
}

Damit habe ich ca. 6 % Leistungsplus gegenüber virtuellen Methoden einkassiert* und abgesehen davon, dass die Implementierung der Basismethoden im Quelltext zur Implementierung der endgültigen Methoden gewandert ist, hat sich nichts geändert. Katzeschööööön!

————
* Meine Maschine ist seit ein paar Tagen ausgelastet, darum rauschen die Messungen sehr. Jedenfalls zwischen 5 und 9 %.

Verfasst: **20.05.2012, 10:49**

Jonathan hat geschrieben:
Artificial Mind hat geschrieben: Ja, man kann es undefinen. Toll ist das trotzdem nicht.
Also ich kenn nix schlimmeres, als die windows.h. Wenn auf einmal dein Vectorklassen-min-Template nicht mehr kompiliert wegen einer komischen Meldung die du nicht verstehst, ist das echt so ziemlich das nervigste, was es gibt. Kann man sich drüber aufregen, nützt aber wohl nichts. Wenn man den Fehler einmal kennt, kann man ihn ja auch recht schnell beheben.

Darum benutze ich nur noch selber verfasste Windows-Header.

Verfasst: **20.05.2012, 11:09**

Jonathan hat geschrieben:
Artificial Mind hat geschrieben: Ja, man kann es undefinen. Toll ist das trotzdem nicht.
Also ich kenn nix schlimmeres, als die windows.h. Wenn auf einmal dein Vectorklassen-min-Template nicht mehr kompiliert wegen einer komischen Meldung die du nicht verstehst, ist das echt so ziemlich das nervigste, was es gibt. Kann man sich drüber aufregen, nützt aber wohl nichts. Wenn man den Fehler einmal kennt, kann man ihn ja auch recht schnell beheben.

exakt: #define NOMINMAX ;)
Für das Problem dass viele "Funktionen" eigentlich Makros sind, gibts aber leider keine Lösung...

Verfasst: **20.05.2012, 11:28**

Krishty hat geschrieben:Freie Funktionen waren mit dem Rasterizer außerordentlich hässlich, darum habe ich das Folgende gemacht, was ich einfach mal Krishty's static single-overridden virtual method dispatching-Muster nenne: [...]

Ja, dieses Muster nutze ich auch für einige Rendering-bezogene Klassen.

Verfasst: **20.05.2012, 15:06**

Ohne jemanden zu nahe treten zu wollen, aber: Assimp Materialien sind eine Qual. Bei den ganzen Makros und Funktionsparametern die Kombination zu finden, die den Wert liefert/setzt den man haben will, so dass es kompiliert und nicht abstürzt ist echt derbe fummelig. Und die Dokumentation ist auch nur sehr begrenzt hilfreich, weil nur Makros aufgelistet werden (vor die man noch einen 'versteckten' Präfix packen muss), aber nicht, wie die jetzt genau auf die generellen get/set Funktionen passen. Und was "The MATKEY_UVWSRC property is only present if the source format doesn't specify an explicit mapping from textures to UV channels." heißen soll, versteh ich auch nicht (der Attribut, welche Textur welchen Uv-Channel benutzt ist nur vorhanden, wenn dies in der Modelldatei nicht stand? Häh?)
Ich weiß, das Zeug ist alt und C-Kompatibel, aber für mich ist halt 'Materialwert abfragen', etwas, das man mit nachschlagen innerhalb von 30 Sekunden hinkriegen können sollte.

Verfasst: **20.05.2012, 15:18**

Wie wäre es mit

Eigene Übersetzung hat geschrieben:Die MATKEY_UVWSRC-Eigenschaft ist nur vorhanden, falls das Quellformat keine explizite Abbildung von Texturen zu UV-Kanälen vorgibt.

Aber das ändert ja an deiner dargelegten, grundsätzlichen Problematik nichts. ;)

Verfasst: **20.05.2012, 15:28**

Ich empfinde das Design der Material-Strukturen und Methoden auch als unglücklich. Mir fallen aber als Alternativen auch nur Ansätze ein, die andere Probleme hätten, und ich habe nicht die Zeit, um alternative Ideen umzusetzen. Zumal wir in Anbetracht der inzwischen beachtlichen Nutzeranzahl auch für Abwärtskompatibilitär sorgen müssten, wenn wir da was neues erfinden.

Verfasst: **20.05.2012, 16:05**

eXile hat geschrieben:Wie wäre es mit
Eigene Übersetzung hat geschrieben:Die MATKEY_UVWSRC-Eigenschaft ist nur vorhanden, falls das Quellformat keine explizite Abbildung von Texturen zu UV-Kanälen vorgibt.
Aber das ändert ja an deiner dargelegten, grundsätzlichen Problematik nichts. ;)

Versteh ich immer noch nicht. Ich will doch bloß wissen, welche Textur welchen Uv-Channel benutzt. Was genau ist da mit Abbildung gemeint? Entweder man hat UV-Maps, oder generiert die halt, aber das wird doch durch MATKEY_MAPPING gesteuert?

Zum Thema neues erfinden: Vielleicht wäre es ja möglich, neue Get/Set Methoden dazuzupacken, die ohne diese seltsamen Makros und so auskommen. Man könnte die alten immernoch benutzen, aber eben auch die schönen, neuen.
Jetzt zum Beispiel hab ich:

Code: Alles auswählen

aiMaterial->Get(AI_MATKEY_UVWSRC(0, DiffuseId), &UvChannel, 1);

(analog zum setzen) und bekomme:

error C2664: 'aiReturn aiMaterial::Get<int>(const char *,unsigned int,unsigned int,int *,unsigned int *) const': Konvertierung des Parameters 5 von 'int' in 'unsigned int *' nicht möglich

und der Fehler sagt mir erstmal rein gar nichts. Und weder ein Blick in die Doku über das Makro und die Get-Funktion sagt mir, was da jetzt falsch ist, weil die Get-Parameter so generisch sind, dass ich keine Ahnung hab, wofür sie eigentlich sind, und das Makro nur sagt, wofür es gut ist, aber nicht, was es eigentlich macht. Und das ganze logisch, Schritt für Schritt durchzudenken fällt echt schwer, wenn man so genervt ist, wie ich jetzt gerade :D

Achja: Und dann stellt man fest, dass

Code: Alles auswählen

aiMaterial->Get(AI_MATKEY_UVWSRC(0, DiffuseId), UvChannel);

funktioniert. Warum ich jetzt diese Version nehmen muss, weiß ich allerdings nicht (wie gesagt, ich wollte es analog zum setzen machen).

Verfasst: **21.05.2012, 00:52**

Schleifenrümpfe im Pixel Shader werden offenbar grundsätzlich immer vollständig ausgeführt (inkl. Speicherzugriffe?!?), bedingte Nebenwirkungen dabei nur per Flag ausgeschaltet. Da hilft nicht mal ein Early Return im Schleifenrumpf, welches den Pixel Shader komplett abbricht. Im Moment kostet mich das hunderte Millisekunden, und ich optimiere mich seit Stunden erfolglos an einzelnen Speicherzugriffen zu Grunde. Was genau da vor sich geht, kann ich bis jetzt nur erahnen, übertrifft aber soweit meine schlimmsten Befürchtungen. :shock:

Oh, und wehe man geht der Sache auf den Grund:

fxc hat geschrieben:internal error: argument pulled into unrelated predicate

Na herzlichen Glückwunsch. Ist der Shader also mal wieder außerhalb der typischen Komplexität fünf Jahre alter Spiele? :evil:

Verfasst: **21.05.2012, 01:13**

Anstatt zu schlafen weil ich in drei Stunden wieder raus muss habe ich eben fünf Stunden lang versucht, LLVM mit Eclipse ans Laufen zu kriegen

Das habe ich alles gesaugt, ausprobiert, installiert, extrahiert:

Eclipse x64 (ich wusste ja nicht, dass man dafür die x64-JRE braucht)
JRE x64 (ich wusste ja nicht, dass Clang auf Windows nur x86 ist)
JRE (jetzt nochmal richtig – im Jahr 2012 muss schließlich alles brav x86 sein)
Eclipse
LLVM plugin for Eclipse CDT
LLVM-GCC 4.2 Front End Binaries for Mingw32/x86
LLVM Binaries for Mingw32/x86
Clang Binaries for Mingw32/x86

und Eclipse so: Nö

und ich so: Och komm

und Eclipse so: Because FUCK YOU

Nachtrag: Und dann habe ich das Häkchen bei „nicht unterstützte Toolchains ausblenden“ weggemacht und obwohl die Toolchain laut Eclipse nicht unterstützt ist sehe ich jetzt ein Stück Clang in der Ausgabe. True Story!

Verfasst: **21.05.2012, 01:26**

clang++: error:
no
such
file
or
directory:
'(x86)\llvm-gcc4.2-2.9-x86-mingw32\include'

Oh fein

Ich darf ALLES NOCHMAL NEU INSTALLIEREN

weil ihr bescheuerten Idioten im Jahr 2012 keine Leerzeichen in Pfaden unterstützt

I CANT EVEN

und warum bricht die Fehlermeldung nach jedem Wort die Zeile um

Bild

IN WAS FÜR EINER WELT LEBEN WIR EIGENTLICH

Verfasst: **21.05.2012, 01:33**

bei der Installation des Plugins via Drag & Drop hängt mein Browser. Der ganze Chrome trotz tollem Sandbox-Konzept.

Eclipse ist nur mit dem Standard-Windows-Farbschema kompatibel

hier surren überall Mücken rum weil das so scheiße grell ist

ich wusste ja, dass es schwierig würde, Clang zum Laufen zu kriegen

Ich hatte gehofft, es würde wie mit Sex – täte nur beim ersten Mal weh

aber mittlerweile installiere ich es zum vierten Mal und blute immernoch

und noch ist keine einzige Zeile kompiliert

Ahja

clang++.exe in PATH eintragen muss ich auch noch

na, hoffentlich stolpert der nicht über die ganzen Leerzeichen, die da drinstehen

Verfasst: **21.05.2012, 01:41**

Haha wie konnte ich so dumm sein, mein Projekt Clang Test zu nennen

Illegal character in path at index 5: clang test.exe

[0] 'c'
[1] 'l'
[2] 'a'
[3] 'n'
[4] 'g'
[5] ' ' <<<<<<
[6] 't'
…

Verfasst: **21.05.2012, 06:40**

Schämst du dich denn gar nicht? Du weißt doch das wir in den 90igern leben. Da kannst du dir doch nicht einbilden, Leerzeichen in einem Pfad - einem PFAD - zu benutzen!

srsly, ich dachte wir wären mit soetwas durch.

Zum Jammern:
Ich kriege gestern eine Mail von einem Projektmitglied, dass sein Code inzwischen ohne Compiler Fehler compiliert. Ich freu mich drauf, git pull, qtcreator build und die ganze dämliche Konsole voller Compiler fehler. Dinge wie for (int u = 0; i < size; i++). (i war nicht woanders definiert)
Ich schreib also ne böse Mail an alle, meldet sich besagtes Teammitglied und entrüstet sich, er fühle sich etwas auf den Schlips getreten, er hätte ja alles gecheckt und in seinen Dateien kämen keine compile errors.
Ich zeig ihm also git log und schon ist er ruhig.

Moral von der Geschichte: in MSVC kann man ein Gedicht in ein unbenutzes Template schreiben und der Compiler freut sich. Mein GCC (ich arbeite für das Projekt unter Linux, meine Teammitglieder unter Windows) versucht das wohl zu instanzieren und rät dann ein paar - allerdings auch nicht alle - Fehler.

Verfasst: **21.05.2012, 10:18**

Artificial Mind hat geschrieben:
Moral von der Geschichte: in MSVC kann man ein Gedicht in ein unbenutzes Template schreiben und der Compiler freut sich. Mein GCC (ich arbeite für das Projekt unter Linux, meine Teammitglieder unter Windows) versucht das wohl zu instanzieren und rät dann ein paar - allerdings auch nicht alle - Fehler.

Ja, das las ich hier im Forum schon mehr als einmal :)

Verfasst: **21.05.2012, 11:13**

Ok, kann mir das mal bitte jemand erklären?
Aus der gmm-Library.

Code: Alles auswählen

template <typename MAT1, typename VECT, typename MAT2>
void symmetric_qr_algorithm(const MAT1 &A, const VECT &eigval_,
                               const MAT2 &eigvect_,
                               tol_type_for_qr tol = default_tol_for_qr,
                               bool compvect = true) {
     VECT &eigval = const_cast<VECT &>(eigval_);
     MAT2 &eigvect = const_cast<MAT2 &>(eigvect_);

     ...
}

eigval und eigvect sind output parameter. Man bekommt die Eigenwerte und Eigenvektoren in diese Parameter geschrieben.
Warum sind die als const übergeben und werden direkt geconst_castet? Man hat mir beigebracht, dass dies wirklich das letzte ist, was man tun möchte.

Verfasst: **21.05.2012, 12:06**

Das ist natürlich völliger Schwachsinn und potentiell undefined behaviour (nämlich dann wenn da mal jemand wirklich einen const VECT übergibt)...

Verfasst: **21.05.2012, 13:15**

@Krishty: Ich kann als Speicherort für alles was mit SDKs usw. zu tun hat nur C:/Users/Public/SDKs o.Ä. empfehlen.

Verfasst: **21.05.2012, 13:25**

Krishty hat geschrieben:hier surren überall Mücken rum weil das so scheiße grell ist

Da weiß ich doch, warum ich hier alle Fenster mit Fliegengittern ausgestattet habe. We have the technology! Oder so.

Verfasst: **21.05.2012, 19:26**

Artificial Mind hat geschrieben:Moral von der Geschichte: in MSVC kann man ein Gedicht in ein unbenutzes Template schreiben und der Compiler freut sich. Mein GCC (ich arbeite für das Projekt unter Linux, meine Teammitglieder unter Windows) versucht das wohl zu instanzieren und rät dann ein paar - allerdings auch nicht alle - Fehler.

Benutz Clang.

Ach; besser doch nicht.

Artificial Mind hat geschrieben:Ok, kann mir das mal bitte jemand erklären?

Da hat jemand gemerkt, dass er nicht mehr in die Parameter schreiben kann, falls für eigval_ und eigvect_ const-Instanzen (z.B. Rvalues) übergeben werden, weil in diesem Fall MAT1 und VECT zu const-qualifizierten Typen aufgelöst werden. Weil er kein unConst-Template auf die Reihe gekriegt, und auch sonst nicht viel von irgendwas verstanden hat, hat er die Parameter const deklariert und das const_cast<>() eingebaut. Auf diese Art und Weise sind lokale Instanzen vom Typ VECT nicht mehr const (das const wird durch das in der Parameterdeklaration von VECT und MAT2 weggezogen), und er kann trotzdem irgendwie in die Instanzen schreiben. Ist aber nur geraten.

Chromanoid hat geschrieben:@Krishty: Ich kann als Speicherort für alles was mit SDKs usw. zu tun hat nur C:/Users/Public/SDKs o.Ä. empfehlen.

Das ist ja nicht einmal ein SDK. Das sind drei Compiler und eine IDE. Irgendwo hört es doch auf.

eXile hat geschrieben:Da weiß ich doch, warum ich hier alle Fenster mit Fliegengittern ausgestattet habe. We have the technology! Oder so.

Ist ein Kippfenster. Dafür habe ich den schöneren Ausblick auf die Sterne. (Falls ich nicht vom Standard-Thema geblendet bin …)

Verfasst: **21.05.2012, 20:17**

Krishty hat geschrieben:
Artificial Mind hat geschrieben:Ok, kann mir das mal bitte jemand erklären?
Da hat jemand gemerkt, dass er nicht mehr in die Parameter schreiben kann, falls für eigval_ und eigvect_ const-Instanzen (z.B. Rvalues) übergeben werden, weil in diesem Fall MAT1 und VECT zu const-qualifizierten Typen aufgelöst werden. Weil er kein unConst-Template auf die Reihe gekriegt, und auch sonst nicht viel von irgendwas verstanden hat, hat er die Parameter const deklariert und das const_cast<>() eingebaut. Auf diese Art und Weise sind lokale Instanzen vom Typ VECT nicht mehr const (das const wird durch das in der Parameterdeklaration von VECT und MAT2 weggezogen), und er kann trotzdem irgendwie in die Instanzen schreiben. Ist aber nur geraten.

Das kommt aus der gmm-Library:
http://download.gna.org/getfem/html/hom ... nseqr.html
Eigentlich ist das eine seriöse und auch von nicht wenigen verwendete Math Library für Linear Algebra Stuff.
Mir kommt eine "da konnte jemand nicht richtig programmieren"-Erklärung irgendwie seltsam vor.

Verfasst: **21.05.2012, 20:22**

Artificial Mind hat geschrieben:Mir kommt eine "da konnte jemand nicht richtig programmieren"-Erklärung irgendwie seltsam vor.

Es gibt aber keine vernünftige Erklärung für das. Wie gesagt, je nachdem wie die Funktion aufgerufen wird, ist das sogar undefined behaviour...

Verfasst: **21.05.2012, 21:00**

ZFX + Developia

Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread

Re: Jammer-Thread