ZFX + Developia

Eine Hassrede ohne Gleichen :D ..
Also ich arbeite ja auch mit Qt, und muss auch sagen, dass es einige Sachen gibt die mir nicht gerade gefallen oder mit denen ich Probleme habe.
Aber is auf jeden Fall um einiges bessert als mit MFC rumzukrauchen...

Das ist echt der Gipfel. setTabOrder() leitet nur zur Hälfte an Focus Proxies weiter (nach Doku behandelt es Focus Proxies voll transparent!), ganz offensichtlich schludig implementiert (und redundant! Focus Proxies werden echt ÜBERALL erneut von Hand von der gleichen zigfach kopierten for-Schleife aufgelöst). Widgets ohne Focus Policy (d.h. ALLE Composite Widgets) werden deshalb von setTabOrder() immer ignoriert. Schlussendlich gibt es überhaupt keine andere Möglichkeit, die Ordnung von Elementen vollständig zu verändern, als diese gleich in der richtigen Reihenfolge in das Composite Widget einzufügen. Dabei sind Composite Widgets ja ach so verbreitet:

When a widget is used as a container to group a number of child widgets, it is known as a composite widget. Many of the examples provided with Qt use this approach, and it is also covered in the Qt Tutorials.

Es hilft alles nichts, ich habe die Qt Designer XML Files per Texteditor in die richtige Reihenfolge gebracht, nun habe ich FAST was ich will (und die Hälfte des fraglichen Codes befasst sich schon mit dem Setup von Focus Proxies). Wenn sich jetzt noch die Buttons in den Composite Widgets entschließen könnten, ihren Focus nicht immer direkt an den ersten Butten des Parent-Widgets weiterzugeben. :evil:

Die neue Windows 8 Beta hat mir gerade eine thumbs.db Datei erstellt. In einem Ordner ohne Bilder.
Und das .NET Framework 2.0 ist anscheinend nicht mehr vorinstalliert.

Helmut hat geschrieben:thumbs.db

It's 2001 all over again!

Qt Doku hat geschrieben:

Code: Alles auswählen

 bool MainWindow::eventFilter(QObject *obj, QEvent *event)
 {
     if (obj == textEdit) {
         if (event->type() == QEvent::KeyPress) {
             QKeyEvent *keyEvent = static_cast<QKeyEvent*>(event);
             qDebug() << "Ate key press" << keyEvent->key();
             return true;
         } else {
             return false;
         }
     } else {
         // pass the event on to the parent class
         return QMainWindow::eventFilter(obj, event);
     }
 }

Notice in the example above that unhandled events are passed to the base class's eventFilter() function, since the base class might have reimplemented eventFilter() for its own internal purposes.

Notice in the example above that no unhandled textEdit events are ever passed to the base class's eventFilter() function, and thus never reach the base class's own implementation of eventFilter(), even if the base class is desperately waiting for such events for its own internal purposes.

Schon beim Lesen der Doku wird einem schlecht.

Es gibt Tage, da hat man echt keinen Bock mehr. Gestern Abend wollte ich lexical_cast benutzen und bekam alberne Fehlermeldungen in irgendwelchen Boost Headern. Es stellte sich heraus, dass es schon reichte, die lexical_cast.hpp zu inkludierne, um diese Fehler zu kriegen. Also hab ich so ziemlich jede Mögliche Include Riehenfolge durchgetestet, brachte alles nix. Dabei habe ich diese dumme Header schon millionenfach benutzt! Um zu demonstrieren, dass es sonst überall geht, hab ich nochmal ein anderes Projekt kompiliert, und BAM, da kam der gleiche Fehler. Nachdem ich dann alles von boost 1.47 auf 1.49 umgestellt habe (das ich erst installieren musste), ging dann alles wieder. Dabei haben ich nichts an der boost Installation gemacht.

Und weiter gehts: Assimp aktualisiert und kompiliert, schon kriege ich alberne Fehler in DirectX Headern. Also kurzerhand das SDK neu installiert (ist die aktuelle Version echt von Juni 2010???). Dann ging es wieder.

Aber kurz darauf bekomme ich Fehler in assimp_view.rc (error RC2104: undefined keyword or key name: S_SETFONT)
und diesmal weiß ich nicht, was ich neu installieren soll. Viellicht Windows?

Das alberne ist ja, ich habe absolut nichts gemacht, was all diese kaputten Sachen erklären würde. Ganz ganz toll.

Ich quäle mich gerade durch OpenGL Tutorials (bin ja ursprünglich DirectX gewohnt) und habe versucht VBOs zu implementieren. Nun hab ich sämtliche erdenkliche Möglichkeiten ausprobiert um endlich ein simples Dreieck auf den Bildschirm zu zaubern, da leider rein gar nichts gezeichnet wurde. Nach nun wohl gut vier Stunden fällt mir auf das ich durch Copy&Paste die Daten immer auf den selben Index im VBO geschrieben habe und somit ein Dreick in einem Punkt gezeichnet habe... ARRGGGHHH

Ich sitze schon zwei Tage daran, eine Sprite via Direct3D 9 1:1 in einer 3D-Szene anzuzeigen.

Woran scheitert's da denn?

Die Vertex-Koordinaten auf die Pixel zu kriegen.

Ich hatte das Pech, dass mein Fenster zufällig immer eine gerade Anzahl Pixel breit und hoch war – darum habe ich völlig verpennt, dass der Koordinatenursprung mit wechselnder Auflösung hübsch zwischen den Pixeln hin- und hergleitet.

Und wenn das getan ist, darf ich rausfinden, warum meine Texturen selbst mit Point Filtering noch verschwimmen. Da muss noch viel mehr falsch sein.

Der Ursprung wird in D3D9 in der Pixelmitte rasterisiert. Eventuell entsprechendes halbes Pixeloffset vergessen?

Das Vertex (0, 0) liegt in der Bildschirmmitte. Allerdings liegt es nicht automatisch in einer Pixelmitte – falls dein Bildschirm eine gerade Anzahl Pixel breit und hoch ist, liegt (0, 0) genau zwischen zwei Pixelmitten. Falls er eine ungerade Anzahl breit ist, genau in einem drin. Und danach kommt noch ein halber Pixel Versatz drauf; oder eben nicht. Und danach noch ein halber Texel auf die Texturkoordinaten. Und da vergeht mir schon wieder die Lust.

Der Punkt (-1, 1) liegt in einer Pixelmitte (linkester oberster Pixel des Viewports). Wenn du dich von da an in Pixelschritten bewegst, liegst du immer in der Pixelmitte. Danach ein halbes Pixeloffset von der Position abziehen, und die Texturkoordinate des rasterisierten Pixels entspricht gerade einer Texelmitte (bei 1:1). Wenn du irgendwo in der Mitte des Bildschirms anfängst, musst du natürlich relativ zu so einem Ankerpunkt runden.

In D3D9 sind Texel und Pixel um 0.5 verschoben: http://msdn.microsoft.com/en-us/library ... 19690.aspx ;)
Du musst entweder die Vertexkoordinaten um 0.5 Pixel nach oben links oder die Texturkoordinaten um 0.5 Texel nach unten rechts offsetten.

Fehlermeldung:

Visual Studio hat geschrieben: error C2275:Foo<__formal,Etype>' : illegal use of this type as an expression

Fehlerursache:
Auf eine static Membervariable der struct 'Foo' versehentlich mit "." statt mit "::" zugegriffen.

Was würde ich für ausnahmslos immer aussagekräftige Fehlermeldungen geben *seufz*

EDIT:
Und wo wir schon dabei sind:
Ich finde es auch immer ganz toll, dass bei Templates eine einzelne Fehlermeldung schnell mal mehrere DIN A4 Seiten lang werden kann :x

PS:
C++ Template-Metaprogrammierung hat echt eine Syntax, die Verückte macht :?

The Android emulator included in SDK is quite slow and unfortunately this is noticeable while debugging. You might experience several second delay during stepping. Delays longer than a couple of seconds should be rather uncommon.

Ach, so lange es nur ein paar Sekunden für den Sprung von einer Zeile zur nächsten sind mit core i7, 8GB RAM mit SSD, dann ist es ja halb so wild... :x

y = HTONS(x) bzw. y = HTONL(x) unter Windows: y = htons(x) bzw. y = htonl(x)
y = HTONS(x) bzw. y = HTONL(x) unter BSD-Derivaten wie z.B. Unixoiden: y = x = htons(x) bzw. y = x = htonl(x)

Wer hat sich eignetlich dieses unituitive Verhalten der BSD-Implementation ausgedacht? Ich will meine mit dem diesbzüglichen Debugging verschwendete Lebenszeit von ihm zurück verlangen!

Keine Ahnung warum du da x nochmal zuweist. Scheint mir recht sinnfrei zu sein.

Wieso ich? Das ist die Standard BSD-Implementation.
Würde ich das selber machen, dann müsste ich ja nicht drüber jammern ;)

Achso. Wer Macros nutzt ist selber Schuld würd ich fast sagen. :P

Warum ist meine Berechnung im Releasemodus (fast) richtig und im Debugmodus total falsch. WARUM???? ICH WILL NICHT MEHR!!!! WARUUUM????

FredK hat geschrieben:Warum ist meine Berechnung im Releasemodus (fast) richtig und im Debugmodus total falsch. WARUM???? ICH WILL NICHT MEHR!!!! WARUUUM????

Uninitialisierte Variablen gehören auf jeden Fall zu den Favoriten.

Hmm... sollten alle initialisiert sein.

sollte(n) ist ein Arschloch. Hat mir auch schon oft alles kaputt gemacht. ;)

Hätte jetzt erwartet, dass sie im Debugmodus richitg wären und im Releasemodus eher falsch, weil da ggf. Defaultwerte wegoptimiert werden. Aber ist halt andersrum....

Initialisieren nicht einige Compiler im Debugmodus absichtlich mit Müll, damit man es merkt und bei release kann man halt das Pech haben, dass vieles einfach auf 0 initialisiert wird und damit sich "fast gut" verhält?

Korrekt. Vor allem bei bools gefährlich, weil die im Debug-Modus einen definierten Wert "true" haben, während sie im Release auch mal false sein können.

Du kannst auch Debug-Symbole im Release-Modus anmachen und dann mal durchsteppen, wo genau es scherbelt. Sei aber versichert: es ist praktisch ausgeschlossen, dass der Compiler was falsch macht. Mit höchster Wahrscheinlich ist Dein Code das Problem. Und damit hast Du also beste Chancen, den Fehler zu finden.

Hört! Hört! Ihr plebejisches Fußvolk, hört was euer Gott Mike Acton sich wieder aus den Fingern gesaugt hat!

Und Referenzen sind überflüssiger Müll!1

Schrompf hat geschrieben:es ist praktisch ausgeschlossen, dass der Compiler was falsch macht.

http://lwn.net/Articles/478657/ *scnr*

eXile hat geschrieben:wieder

Ist bei mir broken.

Ich hab nicht gesagt, dass keine Compiler-Bugs existieren. Nur ist das Geschrei bei Debug vs. Release meist groß nach "Compiler-Fehler!!!11elf", aber in den allermeisten Fällen ist es nunmal nicht der Compiler. Mehr wollte ich nicht sagen. Ist doch auch ne gute Sache! Eigene Fehler finden sich viel leichter als Compiler-Bugs.