Anti-Jammer-Thread

[CodingCat]

Offsensichtlich dürfen DX11 (DXGI) Back Buffers nicht nur beschrieben, sondern auch in Shaders gelesen werden. Ich glaubs erst wenn ichs seh.

[Krishty]

4×3-Matrizen (oder 3×4, falls man drauf steht) reichen für alle,s was man außerhalb des Renderers macht, aus.

[eXile]

Da hat noch nie jemand Radiosity implementiert oder eine Linie mit einer Quadrik geschnitten. Aber richtig ist, dass man homogene Matrizen außerhalb des Renderers relativ selten antrifft, da man in den seltensten Fällen die affine (w=1)-Hyperebene mittransformieren will (sprich: wir sind nur im World-Space, und machen nie eine perspektivische Division). Wobei der Übergang zwischen m×n-Matrizen und m×n-Arrays auch fließend ist. ;)

[Krishty]

Wobei der Übergang zwischen m×n-Matrizen und m×n-Arrays auch fließend ist. ;)

Diese Anspielung verstehe ich leider nicht.

[eXile]

Diese Anspielung verstehe ich leider nicht.

Präziser: Wobei der Übergang zwischen m×n-Matrizen (idealerweise reeller Zahlen, hier von Gleitkommazahlen) und m×n-Arrays (von Gleitkommazahlen) auch fließend ist, da man beliebige Operationen auf diesen Arrays auch äquivalent (aber fast immer weniger performant) mittels geeigneter Matrizen und Matrixoperationen erreichen kann. Im Endeffekt ist das Haarspalterei, da in der Regel ja jede Matrixklasse ein Array von Gleitkommazahlen verwaltet. Darum habe ich von einem „fließenden“ Übergang gesprochen.

[Krishty]

Ah. Ich sehe nur keinen höheren Zusammenhang, weil ich nirgends was anderes als Matrizen erwähnt habe :)

Um am anti-jammern zu bleiben:
/STACK:268435456 mit alloca()

Nachtrag: In Bedrängnis kommt man allerdings, falls man in derselben Funktion C++-Ausnahmebehandlung nutzen möchte. Hier würde es sich wirklich anbieten, wenn man via WinAPI oder CRT eine Möglichkeit hätte, den Freiraum (oder zumindest die Größe) des Stapelspeichers zu ermitteln …

[Krishty]

Template-Magie und Operatorüberladung für transparente Implementierung von Z-Kurven (und vielleicht auch irgendwann Hilbert-Kurven) in Dingen, die wie mehrdimensionale C++-Arrays aussehen <3

Allerdings vermisse ich verzweifelt Intrinsics, um zwei Bit-Werte miteinander zu „interleaven“. Gibt es hier auch einen Naja-Thread?

[eXile]

Template-Magie und Operatorüberladung für transparente Implementierung von Z-Kurven (und vielleicht auch irgendwann Hilbert-Kurven) in Dingen, die wie mehrdimensionale C++-Arrays aussehen <3

Hast du dir dann auch direkt den passenden Satz an Iteratoren dazu definiert? Ich meine: Man muss nicht immer von links nach rechts, von oben nach unten durch ein Array iterieren. Wenn dein Array gemäß einer Z-Kurve linearisiert im Speicher vorliegt, kannst man dann ja auch einfach gemäß der Z-Kurve über das Array drüberlaufen (d.h. physikalisch ist das einfach nur das Inkrementieren eines Pointers, welcher in das Array zeigt). Hauptsache, man durchläuft damit das gesamte Array einmal. Wie ist egal.

[Krishty]

Guuute Idee; danke … bisher waren die Arrays ROM; aber sobald ich Schreibzugriff brauche, werden die Iteratoren sicher abgehen.

[Lukander]

Hab jetzt nichts besseres gefunden.
Ich suche Leute die bei einem Projekt mitwirken wollen (Ich weiß ich könnte in dem anderen Bereich Mitarbeiter suchen, möchte das aber noch nicht.)
Es geht um ein Tycoon Spiel. Bitte bei Interesse mit einer Nachricht melden.

[Artificial Mind]

Code: Alles auswählen

            var progman = FindWindowEx( IntPtr.Zero, IntPtr.Zero, "Progman", null );
            var shelldll = FindWindowEx( progman, IntPtr.Zero, "SHELLDLL_DefView", null );
            var wnd = FindWindowEx( shelldll, IntPtr.Zero, "SysListView32", null );
            SendMessage( wnd, LVM_SETVIEW, 0x0001, 0 );

Und schon hat man eine "Details"-Ansicht auf dem Desktop ^__^

[Tejio]

Wir schauen uns die Vorstellung von Windows 8 an und warten gespannt auf die Aussage, wann Windows 8 und Visual Studio 2011 als Developer Version freigegeben werden. "...Tomorrow..."
Reaktion vom Chef: Aufspringen und freuen wie ein kleines Kind, dass es schon so bald ist.
Nice :D

[CodingCat]

Wow.

Windows 8 will ship with a pair of runtimes; a new .NET runtime (currently version stamped 4.5), and a native code C++ runtime (technically, COM, or a derivative thereof), named WinRT. There will be a new native user interface library, DirectUI, that builds on top of the native Direct2D and DirectWrite APIs that were introduced with Windows 7.
[...]
WinRT provides a clean and modern API for many of the things that Win32 does presently. It will be, in many ways, a new, modern Win32. The API is designed to be easy to use from "modern" C++ (in contrast to the 25 year old, heavily C-biased design of Win32)

Eine moderne WinAPI für C++!

It gives parity to native C++ and managed .NET code. [...] If Microsoft adds new APIs to core Windows, the WinRT system will ensure that they're seamlessly available to managed code, meaning that .NET developers will no longer be at a disadvantage relative to native ones.

Native C++ als primäre API-Sprache!

You can access WInRT from C/C++, C#/VB, or JavaScript. XAML is the UI layer for C, C++, C#, and Visual Basic. HTML/CSS will continue to be used as the UI layer for JavaScript.

Sensationell: Modernes .NET-style User Interface, native in C++ implementiert. Damit dürfte diese Plage von Managed-Interop endlich überwunden sein, dasselbe UI in C++ und Managed Code. JavaScript wird offenbar eine etwas merkwürdige Extrawurst, hoffentlich nicht eine primäre Extrawurst.

Overlapping Windows No Longer Exist.
The performance cost and usability concerns are simply no longer justifiable to Microsoft. Applications that wish to use this pattern will have to develop other ways to express things such as message boxes.

Windows 8, das erste Desktopsystem, das Fenster fallen lässt? :D

Another library that didn’t make it into WinRT is GDI.

Hallelujah!

[Schrompf]

Das liest sich ja schonmal sehr gut! Ich hab aber auch was eigenes zum Anti-Jammern:

Soeben ist das erste InGame-Musikstück für Splatter eingetroffen. Richtig düsterer Ambient im Spielhintergrund - ich freu mich wie ein Schneemann im Frostfach!

[Matthias Gubisch]

Die Neuigkeiten zu Windows 8 lesen sich ja echt super :)

Ich glaub ich hab noch nen alten Rechner um die Developer Vorschau zu testen ;)

@Schrompf: Glückwunsch, bin eh schon gespannt auf des neue Splatter :)

[CodingCat]

Btw. gibt es das oben von Tejio angesprochene Developer Preview (Win 8, Visual Studio 11) hier zum Download: http://msdn.microsoft.com/en-us/windows/apps/br229516

Ich habe eben die Dokumentation zu WinRT gefunden, und meine Begeisterung schlägt schon wieder um: http://msdn.microsoft.com/en-us/library/windows/apps/

Code: Alles auswählen

// C++
MainPage::MainPage()
{
    InitializeComponent();
}

MainPage::~MainPage()
{
}

void HelloWorld::MainPage::HelloButton_Click(Platform::Object^ sender, Windows::UI::Xaml::RoutedEventArgs^ e)
{
    DisplayText->Text = "Hello World";
}

Das sieht mir stark nach C++/CLI aus. Bisher kannte ich diese abstoßende Hybridsprachen ausschließlich im Rahmen der CLR/des .NET-Frameworks, sollte das also tatsächlich ohne CLR zu Maschinencode kompilierbar sein und somit die neue native Schnitstelle zu "modernem" C++ darstellen, wäre das wohl eher die größte auszumalende Katastrophe als der Lichtschimmer am Horizont. Ich hoffe noch auf ein ordentliches undokumentiertes COM-style C++ Interface.

Update: Das IST das neue native Interface. Grob gesagt haben sie die C++/CLI-Spracherweiterung einfach in eine Reihe von internen Smart-Pointers umgewandelt, die per Compiler-Switch nachträglich implantiert werden. JETZT weiß ich, woran das C++-Compiler-Team die ganze Zeit arbeiten musste. Und wehe, WEHE, sie haben diese Smart Pointers nicht auch in Standard-C++ implementiert!

[Artificial Mind]

Ist das hier nicht der _ANTI_-Jammer-Thread? ;)

Aber ja, C++/CLI ist eklig. Das letzte mal, als ich es benutzen "durfte", brauchte ich eine .NET GUI, die C++ DirectX-Routinen aufruft. Das war ein Spaß mit *-Pointer und ^-Pointern und std::string und .NET string :)

[Artificial Mind]

Gratis-Smilies im C++/CLI-Code: (http://msdn.microsoft.com/en-us/library ... s/br211380)

Code: Alles auswählen

Vector<Object^>^ FeedData::Items::get()
{
	return this->_items;
}

[CodingCat]

Das, was man als PIX kennt, ist in Visual Studio 11 fertig integriert: http://blogs.msdn.com/b/jasonz/archive/ ... eview.aspx

Etwas befremdlich ist, dass auch ein einfacher Modell- und Textureditor eingebaut sind.
NOCH erstaunlicher ist jedoch der eingebaute Node-basierte grafischer Shader-/Effekteditor:



Da ich selbst mal sowas gebaut habe, weiß ich, wie schwierig das ist, beliebig viele beliebig komplexe Shader-Fragmente sinnvoll zu ganzen Effekten zusammenzusetzen. Tatsächlich konnte ich persönlich rückblickend nie wirklich großen Nutzen aus einem solchen Editor ziehen, aber ich bin gespannt, wie funktionsfähig dieser in Visual Studio integrierte grafische Shadereditor wird.

[klickverbot]

Tomasz Stachowiak hat im Rahmen seiner MSc-Arbeit auch eine, wie ich meine, ganz nette Umsetzung eines Graph-Based Rendering Pipeline (oder wie auch immer man das jetzt nennen will) entwickelt: http://h3.gd/pub/msc.html

[CodingCat]

Und das in D, habe kurz über die Arbeit geschaut, sieht wirklich exzellent aus. Man könnte fast auf die Idee kommen, dass D doch eine ernstzunehmende Alternative darstellt...
Vorausgesetzt, man ignoriert den letzten Blog-Eintrag: :mrgreen:

It’s been a ride, but got depressing in the end. Now that priorities for language selection have been punched right into my face by reality itself, I’m ready to go back to C++. Sure, it sucks, but then, everything does.

Zurück zur WinRT: Ich habe inzwischen dank Waigie Einblick die WinRT Headers bekommen, und es handelt sich prinzipiell tatsächlich um eine einfache COM-Schnittstelle, sehr ähnlich der von DirectX 11. Damit dürfte die Schnittstelle über den üblichen V-Table-Makro-Zauber sogar weiterhin C-kompatibel sein. Ansonsten sollte sich die WinRT-API mit exakt denselben Smart-Pointer-Klassen wie die DirectX-APIs nutzen lassen, was leider auch bedeutet, dass Exceptions und RAII ohne die Visual-Studio-Erweiterungen weiterhin einiges an stumpfsinniger Wrapping-Arbeit erfordern werden.

[kaiserludi]

Und das in D, habe kurz über die Arbeit geschaut, sieht wirklich exzellent aus. Man könnte fast auf die Idee kommen, dass D doch eine ernstzunehmende Alternative darstellt...
Vorausgesetzt, man ignoriert den letzten Blog-Eintrag: :mrgreen:

It’s been a ride, but got depressing in the end. Now that priorities for language selection have been punched right into my face by reality itself, I’m ready to go back to C++. Sure, it sucks, but then, everything does.

Zurück zur WinRT: Ich habe inzwischen dank Waigie Einblick die WinRT Headers bekommen, und es handelt sich prinzipiell tatsächlich um eine einfache COM-Schnittstelle, sehr ähnlich der von DirectX 11. Damit dürfte die Schnittstelle über den üblichen V-Table-Makro-Zauber sogar weiterhin C-kompatibel sein. Ansonsten sollte sich die WinRT-API mit exakt denselben Smart-Pointer-Klassen wie die DirectX-APIs nutzen lassen, was leider auch bedeutet, dass Exceptions und RAII ohne die Visual-Studio-Erweiterungen weiterhin einiges an stumpfsinniger Wrapping-Arbeit erfordern werden.

Erinnert mich an den Kommentar einer Kollegin über eine Zeile C#-Code heute (Ja, richtig gelesen, wir haben wirklich weibliche Programmierer *g*):
fixed byte* ptr = &arr[0];
Ihr Kommentar: "Iih, was ist das denn? Ich habe mich doch extra für C# entschieden, um so etwas nie zu Gesicht zu bekommen."

[Krishty]

QueryProcessCycleTime() und QueryThreadCycleTime() ♥

Nun kann ich meine Mikrooptimierungen endlich halbwegs zuverlässig messen …

[Jörg]

CycleTime? Was ist das denn fuer eine Bezeichnung??? Wenn man sich dann noch die Anmerkungen durchliest kann man nur hoffen, dass sie wirklich nur einen Cycle-Counter auslesen...

[Krishty]

Naja; die Bezeichnung für die Prozesszeit gemessen in Takten? :)

Nach dem, was ich in verstreuten Forenbeiträgen zusammengelesen habe, scheint es RDTSC-basiert zu sein.

[Krishty]

Wer auch immer schonmal eine Mathebibliothek geschrieben hat weiß, dass es zwar einfach ist, an die speziellen Gleitkommawerte wie +INF / -INF und NaN zu kommen – dass es aber eine umso haarigere Angelegenheit ist, diese Zahlen als Compile-Time-Constant in den Quelltext zu kriegen.


GCC bietet dafür (nicht standardisierte) Präprozessormakros an; da ist die Sache also noch einfach. Visual C++ ist hingegen richtig hartnäckig. Beispielsweise wird

static double const infinity = 1.0 / 0.0;

mit einer Fehlermeldung quittiert, die auf eine ungünstige Formulierung des C++-Standards zurückzuführen ist: Ein Programm ist ill-formed, sobald eine Konstante mit einem Wert initialisiert wird, der mathematisch nicht definiert ist. Das ist hier ein großes Problem, denn im IEEE 754-Standard ist die Division durch Null zwar als +-INF wohldefiniert; so lange sie aber mathematisch undefiniert ist, muss der Compiler abbrechen. (GCC frisst das hingegen – habe ich gehört – mit einer Warnung.)


Ich habe auch den Schritt über union probiert:

static union {
    unsigned int asInt;
    float asFloat;
} const binaryNaN = { 0x7F800000 };
static float const NaN = binaryNaN::asFloat;

Allerdings scheint VC hier dynamische Initialisierung anzuwenden: binaryNaN wird zwar bei der Übersetzung ausgewertet; die Initialisierung von NaN geschieht jedoch erst zu Programmstart (als fünfzeilige fld-fstp-Funktion). Im Release-Build konnte ich die Funktion zwar nicht mehr finden; NaN landete aber trotzdem im Read-Write-Datenabschnitt der Exe – im Zweifel gegen den Compiler.


Das Problem scheint übrigens auch Visual C++’ CRT zu haben, denn wenn man std::numeric_limits<float>::infinity() aufruft, wird die float aus dem entsprechenden Symbol in msvcrt.dll importiert.


Dabei ist die Lösung so banal wie effektiv:
Sind Intrinsic Functions aktiviert, wird die Auswertung vieler häufige Routinen von der Ausführungszeit zur Übersetzungszeit vorgezogen, falls sie mit statischen Parametern aufgerufen werden. Und darunter finden sich auch die üblichen mathematischen Routinen inklusive log() und sqrt():

static double const negativeInfinity = ::log(0.0);
static double const positiveInfinity = -negativeInfinity;
static double const NaN = ::sqrt(-1.0);

Tadaaaaaa! Wird absolut statisch ausgewertet und bei Verwendung schön optimiert.


(dass keine einzige der Lösungen hier auf allen Compiler gleich funktioniert, dürfte klar sein.)

[Krishty]

Rundet man bei einer float-Heightmap alle Werte so, dass die minderwertigsten acht Bits 0 werden, kann man den Kram mehr als doppelt so klein komprimieren (in meinem Fall 3,08 MiB statt 6,35). Und die zwei dezimalen Nachkommastellen braucht in diesem Anwendungsfall doch eh niemand.

[Krishty]

Dank dichtem Nebel konnte ich heute morgen zum ersten Mal mit bloßem Auge Sonnenflecken sehen.

[Krishty]

Mit Intrinsic Functions eingeschaltet verursachen sqrtf(), absf() usw. keine Datenzugriffe mehr.

Geinlined wird aber zumindest sqrtf() trotzdem nicht; weiß der MS-Compiler-Programmierer, warum. Dass die float-Überladungen intern auch weiterhin mit doppelter Präzision arbeiten (bspw. SQRTSD statt SQRTSS inklusive der dafür nötigen Registerschieberei) ist auch was, was ich beim nächsten Release lieber nicht mehr sehen würde.

Generell scheint VCs Optimizer deutlich auf double ausgelegt zu sein, damit erzeugt er jedenfalls den mit Abstand saubersten Maschinentext.

————

Überladene Operatoren new, new[], delete und delete[] muss man nicht deklarieren, sondern nur definieren. Damit entfällt die Exception Specification, also auch das Referenzieren von bad_alloc, also auch das Einbinden von <new> – dem letzten nicht-eigenen Header, den ich noch zwingend einbinden musste. Bye-bye, STL. (Jedenfalls, so lange man nicht Placement-Syntax verwenden will.)

[Krishty]

Ich schreibe mein Framework neu. Von jetzt an wird in Headern auf STL, CRT, WinAPI und generell auf alles, was ich nicht selber geschrieben habe, geschissen.

Aktuelles Projekt mit 1 MiB Quelltext in 20 Übersetzungseinheiten (.cpp-Dateien) und 70 Headern, im Debug-Modus:

1>Build succeeded.
1>
1>Time Elapsed 00:00:01.89
========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ==========

Im Release-Modus kommen ca. 6 s für Link-Time Code Generation dazu.