Jammer-Thread

[Krishty]

fuck fuck fuck fuck fuck

ich will Icons mit Alpha-Transparenz (nicht bloß shice Color Keying) in meinem Win32-Tree View. [Tree View ist ein Thread für sich; kommt noch.]

Das geht nur über Image Lists. So eine Hilfsklasse, die gleich große Bilder bündelt. Die übergibt man dem Tree View. Gutes Design, den untrennbar mit diesem Scheißteil zu verbinden!

Also erzeuge ich 1 Image List vong BMP-Resource her. Ich höre ein Geräusch hinter mir und drehe mich um. Nichts ist da, aber der Raum sieht anders aus als sonst. Ich drehe mich zurück und schwebe hoch über meinem Körper, der vor dem Bildschirm zusammengeklappt ist. Die Uhr zeigt, dass drei Stunden vergangen sind. Ein fliegender Köttel nimmt mich an die Hand und führt mich durch meinen Abend.

Er erklärt mir, dass die WinAPI garnicht alle BMPs laden kann, obwohl das BMP-Format von und für die WinAPI entwickelt wurde. Muss man erstmal schaffen! Ich nicke anerkennend.

Er erklärt mir außerdem, dass die 50 StackOverflow- und MSDN-Tabs, die da auf meinem Bildschirm blinken, alle über andere Arten von 32-Bit-BMPs sprechen. Manche laden mit GDI, andere mit GDI+, manche mit WMI, die meisten garnicht. Dass jeder die Farbkanäle anders interpretiert. Dass wir es sozusagen mit dem Donnie Darko unter den Bildformaten zu tun haben.

Ich schäme mich ein Bisschen, als ich mir dabei zusehe, wie ich meine BMP mit Gimp exportiert habe. Dass dieses ranzige Pommesbudenprogramm nur eine exotische Abart von BMP exportiert, hätte ich wissen müssen.

Mir beim Setup von Paint.NET zuzusehen ist geradezu peinlich. Das kann doch gar keine BMPs mit Alpha! Wie soll das überhaupt was können, wenn es doch .NET im Namen hat!

Ich frage den Köttel, ob ich mir das wirklich ansehen muss. Habe ich das verdient? Ja, sagt er. Er ist nun aufgebracht und richtig blutig. „Du hast letztes Jahr einen Loader geschrieben, der 30 verschiedene BMP-Varianten korrekt laden kann. Jede einzelne, die in jedem einzelnen Tab dort verflucht wird. Du wusstest, dass BMP scheiße ist. Du wusstest, dass niemand seinen Job richtig macht. Du hättest wissen müssen, dass die WinAPI keine BMPs laden kann – aus dem ganz einfachen Grund, dass du Windows nicht selber geschrieben hast.“ Ich wache auf.

Die 11-KiB-BMP mit 10 einzelnen Icons ist endlich korrekt exportiert und lädt vernünftig. Und ich brauche einen neuen Bürostuhl.

[Krishty]

Mein VRML-Loader verbrachte 60 % seiner Zeit in einer O(n²)-Allokation, die mir versehentlich reingefluttscht ist. Ich hab’s behoben.

Er war trotzdem viel schneller als die Konkurrenz.

[scheichs]

Eine wirklich wundervolle Geschichte Krishty, die ich vllt. meiner Tochter heute abend beim Zu-Bett-Gehen vorlese... :)

[joggel]

Ich hab Kopfschmerzen :(
Tumor???

[Biolunar]

Ich hab Kopfschmerzen :(
Tumor???

[youtube]OaTO8_KNcuo[/youtube]

[joggel]

Haha :lol:

[joggel]

Versucht niemals eine xlsx-Datei (Excel) mit dieser Interop-Geschichte zu laden. Wirklich: NIEMALS!!!
Ich habe damit eine Datei ausgelesen die 12KB groß ist, und das hat über 2min gedauert!!!

[xq]

joggel: mal will generell keine excel-dateien laden, zudem kannst du xlsx einfach mit nem zip-stream entpacken und das XML interpretieren ;)

[joggel]

...mal will generell keine excel-dateien laden,

Doch! Ich. Oder wie meinst du das?

Aber cool. Es gibt ja eine ZipFile-Klasse! Ich schaue mal...

Okay. Tatsache. Eine Zip-File.
Trotzdem...ist schon etwas Aufwand. Muß ja die sheet.xml Auslesen, und diese verweist dann auf die einträge in sharedStrings.XML.
Der weg über diese Interop-Geschichte war schön bequem...

Letztes Edit:
Ich nehme lieber das hier, weil ich ein stinkend faules Stück bin...
Funzt nich...:(

[Chromanoid]

In der Java Welt nimmt man dazu Apache POI. Es scheint einen .NET Port zu geben: https://npoi.codeplex.com/

[joggel]

Danke Chromanoid.
Werd ich mal probieren :)

[Chromanoid]

Hier ein Stackoverflow-Beitrag, der Dir vielleicht hilft: http://stackoverflow.com/questions/5855 ... using-npoi

[joggel]

(y).png (11.3 KiB) 2082 mal betrachtet

[joggel]

Hätte ich nicht irgend sowas wie eine Sozialphobie, wäre es unter Umständen recht cool hier auf Arbeit...^^

So...genug gejammert für heute!

[Krishty]

Iiiih, Menschen. Und Hosen. Was bin ich froh, dass ich meist von zu Hause aus arbeiten kann. Da muss ich keine Hosen tragen.

[joggel]

Ja, oder frische T-Shirts^^

[joeydee]

Air und Stage3D. Schöne Sache eigentlich, schön Low-Level und trotzdem überschaubar.
Ganz toll: DirectX9 wird aktiviert, höchstes angefordertes Profil (Standard Extended) wird angenommen, Player 21. Laut Referenz funktionieren damit Instance-Buffer. Laut Fehlermeldung kennt meine Plattform das nicht. [Fault] exception, information=Error: Error #3708: Feature not available on this platform. Dann müsste er aber doch schon beim Profil aussteigen, für was gibts die denn sonst ... *grrr* :evil:

[Krishty]

Ich habe ein Array von Funktionszeigern. 50 Stück, also 400 B (auf x64). Das könnte man auf 50 % reduzieren, wenn der Compiler nur den Abstand zum Anfang der EXE (oder des Textabschnitts) speichern würde. (In meinem Fall sogar auf 25 %, weil die EXE nicht größer als 65536 * Call Alignment ist).

Tut er aber natürlich nicht, und wenn ich das selber ausrechne, ist es keine constexpr. Ist doch alles scheiße.

Edit: Eigentlich meide ich switch, weil VC da furchtbaren Code produziert. In diesem Fall könnte ein Jump Table vom Compiler aber kompakter werden. Mal testen.

Edit: Great Success: Visual C++ erzeugt eine 4-B Offset Table. Huge Failure: Nur für die Hälfte der cases. Die andere Hälfte erhält Inline-Kopien der aufzurufenden Funktionen.

Edit: Nein, Epic Fail: Visual C++ erzeugt eine 4-B Offset Table. Gemäß der Tabelle wird gesprungen. Und zwar zu einer von 50 Kopien à „rufe X auf“, die sich nur in X unterscheiden.

[Krishty]

*sigh*

  void IndexList::addIndex(UInt4B i) {
    assert(i < 65536);
    *myIndices.end++ = UInt2B(i);
  }

  void IndexList::addTriangle(UInt4B a, UInt4B b, UInt4B c) {
    addIndex(a);
    addIndex(b);
    addIndex(c);
  }

  void IndexList::addQuad(UInt4B a, UInt4B b, UInt4B c, UInt4B d) {
    addTriangle(a, b, c);
    addTriangle(a, c, d);
  }

wird zu

  mov rax,qword ptr [rbx+18h]
  mov word ptr [rax],dx
  add qword ptr [rbx+18h],2
  mov rax,qword ptr [rbx+18h]
  mov word ptr [rax],cx
  add qword ptr [rbx+18h],2
  mov rax,qword ptr [rbx+18h]
  mov word ptr [rax],r8w
  add qword ptr [rbx+18h],2
  mov rax,qword ptr [rbx+18h]
  mov word ptr [rax],dx
  add qword ptr [rbx+18h],2
  mov rax,qword ptr [rbx+18h]
  mov word ptr [rax],r8w
  add qword ptr [rbx+18h],2
  mov rax,qword ptr [rbx+18h]
  mov word ptr [rax],r9w
  mov qword ptr [rbx+18h],rax

(Ja, wirklich! Ich habe MIT Optimierung kompiliert!)

Also nochmal von Hand:

  void IndexList::addQuad(UInt4B a, UInt4B b, UInt4B c, UInt4B d) {
    assert(a < 65536);
    assert(b < 65536);
    assert(c < 65536);
    assert(d < 65536);

    auto it = myIndices.end;
    *it++ = UInt2B(a);
    *it++ = UInt2B(b);
    *it++ = UInt2B(c);
    *it++ = UInt2B(a);
    *it++ = UInt2B(c);
    *it++ = UInt2B(d);
    myIndices.end = it;
  }

  mov rax,qword ptr [rbx+18h]
  mov word ptr [rax],r9w
  mov word ptr [rax+2],cx
  mov word ptr [rax+4],r10w
  mov word ptr [rax+6],r9w
  mov word ptr [rax+8],r10w
  mov word ptr [rax+0Ah],cx
  add rax,0Ch
  mov qword ptr [rbx+18h],rax

Ist jetzt noch nicht einmal was Geschwindigkeitskritisches, aber … wie kann man das verkacken?! 20× Speicher statt 8×? Ich dachte, der Bug wäre seit Visual Studio 2015 weg. Jedenfalls tritt er *viel* seltener auf als mit VS 2013.

ich bin echt an einem Punkt, an dem es produktiver wäre, direkt Assembler zu schreiben.

[Krishty]

Mir ist gerade klargeworden, dass man einem Kegel keine Smooth Normals verpassen kann. Shhhhhhhhiiiiit. Ich dachte vorher wie selbstverständlich, man könnte alles mit Dreiecken erschlagen :(

Nachtrag: Ach, da war doch noch was! Trapeze texturieren. Das geht ja auch nicht mit Dreiecken. Der Kegel ist sozusagen ganz viele Trapeze mit Oberkante Nullbreite.

Ich steig dann mal auf Wellengleichungen um oder so. Hatte Zudo ja gerade erst erklärt. Dann habe ich zumindest echtes DoF.

[DerAlbi]

Hast du bei dem obrigen Optimierungs-Fail mal getestet, ob es hilft, const-refereces zu übergeben? "const Uint4B& a" ?

[Krishty]

Keine Veränderung. Warum denn? Es kann IMO höchstens schlimmer werden, weil Referenzen Aliasen können, aber Kopien nicht …

[dot]

Mir ist gerade klargeworden, dass man einem Kegel keine Smooth Normals verpassen kann. Shhhhhhhhiiiiit. Ich dachte vorher wie selbstverständlich, man könnte alles mit Dreiecken erschlagen :(

Man könnte natürlich einen entsprechenden Shader verwenden, der die exakte Kegelnormale aus einer interpolierten Parametrisierung berechnet...

[Krishty]

Der könnte ja sogar mit dem normalen Shader identisch sein, weil die Parametrisierung die nicht-normalisierte Normale ist. Der Schock ist aber eher, dass Gouraud Shading schon bei einem so simplen Fall an die Grenzen kommt.

[dot]

Achso, das Problem ist nur bei Gouraud Shading...das wundert mich jetzt ehrlich gesagt nicht wirklich, immerhin ist Gouraud Shading effektiv eine schlechte first-order Approximation einer nichtlinearen Funktion, die an der Spitze des Kegels nicht differenzierbar ist...

[Schrompf]

Microsoft spammt jetzt ohne Opt-Out.

This message from Microsoft is an important part of a program, service, or product that you or your company purchased or participate in.

und man darf ihnen trotzdem keinen Ziegelstein durch's Fenster werfen.

[Zudomon]

Hab durch Zufall das gerade mit dem Kegel noch gesehen.
Aber so ganz begreife ich nicht, was das Problem dabei ist. Wenn man nur Dreiecke für die Seite benutzt, dann hat man natürlich Schrott, was die Normalen angeht. Aber das ist für mich so, wie wenn man sich darüber beklagt, dass man mit 20 Dreiecke keine runde Kugel hinbekommen kann.
Ich hab jetzt auch nur den Artikel mal "angeklickt" ohne wirklich zu lesen.

Also wenn man kurz vor der Spitze nochmal die Dreiecke splittet, dann ist das doch in Ordnung... die Spitze ist dann die gemittelte normale von allen Seiten... also zeigt sie in die Richtung, in die auch der Kegel zeigt. Ich bin damit sehr zufrieden, weil ich dafür nichts extra anpassen muss, keine Spezialshader oder dergleichen. Und so krasse Spitzen hat man doch in Wirklichkeit kaum.

So sehen die "Spitzen" bei dem Drachen aus...
Krallen und Hörner...

Vielleicht nochmal Wireframe...

[Krishty]

Visual C++ ist jetzt richtig kaputt. Im Sinne von

  static const int fooArray[] = { 1, 2, 3 };

enthält bei Ausführung völlig zufällige Werte oder zeigt auf gesperrten Speicher. Bis irgendwann heute nachmittag ging’s noch, aber jetzt sind alle Konstanten fratze (inklusive Strings). Visual Studio neu gestartet, Windows neu gestartet, Memtest, alles ohne Erkenntnis. Ich kann nichts selber kompilierters mehr ausführen.

fml.png (6.23 KiB) 1929 mal betrachtet

[antisteo]

Visual C++ ist jetzt richtig kaputt. Im Sinne von

  static const int fooArray[] = { 1, 2, 3 };

enthält bei Ausführung völlig zufällige Werte oder zeigt auf gesperrten Speicher. Bis irgendwann heute nachmittag ging’s noch, aber jetzt sind alle Konstanten fratze (inklusive Strings). Visual Studio neu gestartet, Windows neu gestartet, Memtest, alles ohne Erkenntnis. Ich kann nichts selber kompilierters mehr ausführen.

fml.png

Das kommt davon, dass du so viel damit zumspielst. Installiere am besten Windows neu und lösche alle alten Einstellungen .

[Krishty]

Ich habe einen großen Code-Block gelöscht, in dem eine Konstruktion à

  union { char a[]; struct { int x; } b; } data = { { 0xAA, 0xBB, 0xCC, 0xDD } };

vorkam, und das hat das Problem gelöst. Ich bin drauf gekommen, weil der Fehler nur in Translation Units vorkam, die einen bestimmten Header nutzten. Mehr noch: In dem Müll, der in den Strings stand, konnte ich andere Strings wiederfinden, nur unglücklich verschoben.

Ich schließe daraus, dass der 32-Bit-Visual C++-Compiler

1. alle konstanten Daten nacheinander in ein großes Array schreibt
2. für jeden konstanten Pointer einen Offset in dieses Array speichert
3. bei variable-sized members innerhalb von unions das Offset falsch oder garnicht hochzählt
4. dadurch alle späteren Konstanten falsche Werte enthalten.

Ich hatte keinen Nerv, es auf einen simplen Fall zu reduzieren, und kein 64-Bit-System zum Testen zur Verfügung – das würde aber wie gespuckt passen auf das „der Compiler war für 32 KiB RAM entworfen und kennt deshalb nur die letzten fünf Zeilen“-Verhalten, das sie Ende 2016 nach 30 Jahren endlich aus dem 64-Bit-Compiler rausgeschmissen haben. Ich denke also nicht, dass der 64-Bit-Compiler betroffen ist oder dass Microsoft Anstrengungen unternehmen würde, das noch zu fixen (weil der 32-Bit-Compiler eh weggeschmissen und durch die 64-Bit-Codebase ersetzt wird).