ZFX + Developia

@Schrompf: Falls Du es noch nicht kennst, da stehen glaube ich viele nützliche Tipps: https://developers.google.com/international/i18n via diesen interessanten Goolge IO Talk https://developers.google.com/events/io ... /383370298

Uff... immer wenn ich gerade grob ein Thema bewältigt habe, lädst Du nochmal zwei Tonnen Wissenswertes auf mir ab.

CUDA 5.5 ist da - und funktioniert. Damit kann ich jetzt tatsächlich auf VC++ 2012 umsteigen.

Ich habe Alpha to Coverage via Direct3D 10.1s Coverage Output implementiert, und meine Sprites sehen auf einen Schlag deutlich besser aus: Interessenten finden Quelltext auf Seite 51 der DICE-Publikation DirectX 11 Rendering in Battlefield 3.

Hab mir die Präsentation angeschaut, aber ich verstehe nicht genau, worauf Du Dich dazu beziehst. Schreibst Du jetzt gezielt im Shader die Coverage-Samples, und das Resolve der GPU ergibt nachher die sauberen Sprite-Kanten?

Ja; genau. Weil seit Direct3D 10 bei Multisampling der Versatz jedes Samples fest definiert ist, kann man im Shader ausrechnen, an welchen Stellen die Textur bei MSAA abgetastet würde. Dann samplet man diese Stellen selber, und falls der Alpha-Test das Sample behalten würde, setzt man das entsprechende Bit in der Coverage Mask. In der Ausgabe bedeutet das dann Sprite-Kanten, die genau so glatt sind wie die tatsächlicher Dreiecke.

Nervig ist, dass man bei unterschiedlichen AA-Stufen entweder je einen passenden Shader schreiben muss, oder Leistung wegschmeißt. Weil ich aber erstmal bei 4×AA bleibe, kann ich es mir leisten.

CodingCat hat geschrieben:CUDA 5.5 ist da - und funktioniert. Damit kann ich jetzt tatsächlich auf VC++ 2012 umsteigen.

Gut zu wissen :)

Ich habe soeben einen Weg gefunden, das alte new zur Compile-Zeit zu unterbinden: Überladen von new: Mit: Auch in anderen Compilern: http://ideone.com/agWsO3

Nachtrag: Es kommt noch besser, die MSVC 2013 STL kann mit new-Makros umgehen. Die nutzen tatsächlich Makrogeltungsbereiche in Form von #pragma push_macro("new") #undef new #pragma pop_macro("new"), womit eigene new-Makros direkt unterstützt werden.

Krishty hat geschrieben:Ich habe Alpha to Coverage via Direct3D 10.1s Coverage Output implementiert, und meine Sprites sehen auf einen Schlag deutlich besser aus:

13-08-04 no ATC.png

13-08-04 ATC.png

Interessenten finden Quelltext auf Seite 51 der DICE-Publikation DirectX 11 Rendering in Battlefield 3.

Sind die Bilder unterschiedlich? :?

BeRsErKeR hat geschrieben:

Krishty hat geschrieben:Ich habe Alpha to Coverage via Direct3D 10.1s Coverage Output implementiert, und meine Sprites sehen auf einen Schlag deutlich besser aus:

13-08-04 no ATC.png

13-08-04 ATC.png

Interessenten finden Quelltext auf Seite 51 der DICE-Publikation DirectX 11 Rendering in Battlefield 3.

Sind die Bilder unterschiedlich? :?

Im neuen Tab öffnen hilft häufig ;) Achte mal insbesondere auf die "Gitterstreben", da ist der Unterschied mMn am deutlichsten.

Naja ok man sieht kleine Unterschiede, aber für deutliche Unterschiede sind meine Augen dann wohl zu schlecht.

In der Vorschau sieht man tatsächlich keinen Unterschied, aber in groß ist das obere doch extrem pixelig and den Gitterstreben und wenn selbst ich die sehe, dann heißt das schon was.

Das Hello World / fuck C++ in LLVM Assembly funktioniert.

Verblüffend einfach sogar! Ich hatte am Anfang arge Probleme, weil sie für Windows nur MinGW-Binaries anbieten, die auch tatsächlich eine MinGW-Installation voraussetzen. Sobald das installiert ist, fluttscht es aber wie nichts:

• Quelltext in eine Textdatei
• llvm-as test.ll für menschenlesbar-zu-Bitcode
• lli test.bc zum JIT-Ausführen des Programms
• Fertig – Programm ist auf dem Bildschirm.

Ich hatte eine Hölle aus Einsprungspunkten und Abhängigkeiten erwartet (wo nimmt er das printf() und Sleep() her, das ich deklariert habe?), aber alles funktioniert sofort. Absolut großartig und (abgesehen von den MinGW-Abhängigkeiten) wie Software sein sollte!

Keine Forward Declarations wie in C. Ich rufe was auf und deklariere oder definiere es hundert Zeilen später. Falls es aus WinAPI oder CRT kommt, findet der Compiler es ohne weiteres Zutun in den MinGW-Bibliotheken.

EIN TRAUM

Der weitere Plan ist:

• Ein halbes Jahr nur noch in LLVM Assembly programmieren
• LLVM Asm ist hässlicher als „normales“ Asm und drei Mal so viel Schreibarbeit; Hirn wird Matsche sein
• Eine Makro-Sprache im C-Stil hinklatschen, die mir alle nervigen Sachen abnimmt (z.B., dass man von jeder Variable nicht nur bei ihrer Deklaration, sondern auch bei jeder Benutzung explizit den Typ voranstellen muss)
• ???
• PERFEKTE SOFTWEAR UND NIE MEHR C++

H.265 erfüllt wohl die Erwartungen. Eine 0,57-fache Dateigröße bei vergleichbarer Bildqualität (Q=24).

(Und als reine Information, falls sich irgendjemand fragen sollte, wie er seine Videos überhaupt archivieren kann: FFV1.)

Krishty hat geschrieben:Der weitere Plan ist:

• Ein halbes Jahr nur noch in LLVM Assembly programmieren
• LLVM Asm ist hässlicher als „normales“ Asm und drei Mal so viel Schreibarbeit; Hirn wird Matsche sein
• Eine Makro-Sprache im C-Stil hinklatschen, die mir alle nervigen Sachen abnimmt (z.B., dass man von jeder Variable nicht nur bei ihrer Deklaration, sondern auch bei jeder Benutzung explizit den Typ voranstellen muss)
• ???
• PERFEKTE SOFTWEAR UND NIE MEHR C++

Ich für meinen Teil freue mich auf jedes Fitzelchen Gedankenfutter von deinem mutigen, neuen Pfad. ;)

eXile hat geschrieben:Ich für meinen Teil freue mich auf jedes Fitzelchen Gedankenfutter von deinem mutigen, neuen Pfad. ;)

Teile ich gern; auch wenn es im Augenblick wirklich fast nichts zu jammern gibt. Mich stört ein wenig, dass nativ nur ASCII-Strings unterstützt werden. Für das gute alte "foo" in UTF-16 muss man schreiben:

    @string = [4 x i16] { i16 102 i16 111 i16 111 i16 0}

Aber das müsste ich in Visual Studio auch, wenn ich meine Pläne von Strings ohne Nullterminierung umsetzen wollte. Mit linker_private_weak unnamed_addr davor kriege ich außerdem nicht nur String Pooling, sondern allgemeines Pooling mit allen Konstanten.

Auch sonst arbeitet es sich damit wahnwitzig gut, gemessen daran, dass man vor einem portablen Assembler sitzt! Als nächstes kommt Verbinden mehrerer Übersetzungseinheiten

In einer Stunde geht's auf's Summer Breeze. :-) Bin also weg bis Sonntag. So sehr ich mich darüber freue, endlich mal vor meinem Rechner wegzukommen, so sehr stört mich das aktuell auch, weil ich gerade so schön am Voxeltree schraube. Und vorhin kam gerade eine Nachricht rein, dass jemand ein Spielebundle mit (bekannteren) Indie-Spielen baut und gerne Splatter mit aufnehmen würde. Die Gamescom-Vorbereitungen rollen auch gerade unaufhaltsam... es ist eigentlich ein denkbar ungünstiger Zeitpunkt.

Schrompf hat geschrieben:In einer Stunde geht's auf's Summer Breeze. :-) Bin also weg bis Sonntag. So sehr ich mich darüber freue, endlich mal vor meinem Rechner wegzukommen, so sehr stört mich das aktuell auch, weil ich gerade so schön am Voxeltree schraube. Und vorhin kam gerade eine Nachricht rein, dass jemand ein Spielebundle mit (bekannteren) Indie-Spielen baut und gerne Splatter mit aufnehmen würde. Die Gamescom-Vorbereitungen rollen auch gerade unaufhaltsam... es ist eigentlich ein denkbar ungünstiger Zeitpunkt.

Hätte man das nicht zwischen Jammer- und Anti-Jammer-Thread splatten... äh splitten müssen? ;)

Krishty hat geschrieben:EIN TRAUM

Der weitere Plan ist:

• Ein halbes Jahr nur noch in LLVM Assembly programmieren
• LLVM Asm ist hässlicher als „normales“ Asm und drei Mal so viel Schreibarbeit; Hirn wird Matsche sein
• Eine Makro-Sprache im C-Stil hinklatschen, die mir alle nervigen Sachen abnimmt (z.B., dass man von jeder Variable nicht nur bei ihrer Deklaration, sondern auch bei jeder Benutzung explizit den Typ voranstellen muss)
• ???
• PERFEKTE SOFTWEAR UND NIE MEHR C++

Herzlichen Glückwunsch zum geglückten Umstieg.
Wenn's um eine Sprache geht, die nach LLVM-IR übersetzt wird, bin ich dabei. Am besten auch mit einem "Idiotensicher"-Modus, bei dem man bei den Entwicklern eine korrekte API-Nutzung erzwingen kann.

Visual C++’ __assume() hat mich positiv überrascht.

Für Einsteiger: __assume() ist ein Hinweis an den Optimizer. Wenn ihr z.B. garantieren könnt, dass eine bestimmte Variable x niemals 3 überschreitet, schreibt ihr __assume(x <= 3);. Dann wird Visual C++ beim Inlining alle Pfade entfernen, die nur angesprungen werden, falls x größer als 3 wäre. Schreibt ihr vor einen Zeiger-Cast __assume(ptr != nullptr), dann kann der Compiler die Spezialfälle bei Nullzeiger-Casting ignorieren und performanteren Code erzeugen.

Am besten kann man davon Gebrauch machen, indem man seine assert()-Makros so anpasst, dass sie im Release-Modus durch __assume() ersetzt werden. Denn wenn ihr eh schon alle Invarianten eures Programms, die der Compiler nicht von allein erkennen kann, in assert() festhaltet, könnt ihr die Informationen auch dem Optimizer schenken, damit der mit diesem Wissen schnelleren Maschinentext erzeugt. So habe ich das auch gemacht.

Jedenfalls lief der frische Code eines Kollegen nicht mehr, sobald Optimierungen eingeschaltet wurden. Ich habe es ziemlich schnell auf diesen Quelltext eingrenzen können:

    Object result = newAlgorithm();
    Object oldResult;
    #if defined _DEBUG
        oldResult = oldAlgorithm__FOR_DEBUG_ONLY();
    #endif
    assert(result == oldResult);

In der Debug-Version wäre ein Hinweis gekommen, falls die neue Implementierung andere Ergebnisse liefert als die Alte. In der Release-Version hat Visual C++ allerdings gesehen:

    Object result = newAlgorithm();
    Object oldResult;

    assert(result == oldResult);

und interpretiert:

• result wird zurückgegeben.
• result und oldResult müssen denselben Wert enthalten, sagt der Programmierer.
• oldResult ist wesentlich einfacher zu berechnen als result, weil der fette Funktionsaufruf fehlt.
• Der newAlgorithm() ändert auch keine globalen Variablen und ruft keine externen Funktionen auf.
• Da beide zum selben Ergebnis führen, ist es deutlich schneller, sich für oldResult zu entscheiden.

und hat erzeugt:

    Object oldResult;

… und schon hat die Release-Version nur noch uninitialisierten Speicher zurückgegeben.

Was mich dabei positiv überrascht: Object war ein POD-Datentyp. Normalerweise werden solche Hinweise nur für primitive Datentypen implementiert, weil die meisten Programmierer sie nur auf einzelne ints und Zeiger anwenden. Visual Studio hat aber offensichtlich implementiert, dass POD == POD Gleichheit aller Attribute bedeutet. Da hätte ich niemals drauf gewettet.

Schaaatz!

…

Schaaaaaaaahaaaaaatz

– JA WATT IS DENN?

– Du isch glaub’, die Hölle tut sisch schon wieder auf!

– Kamman denn hier nisch mal fünf Minuten seine Ruhe haben? *steht schweren Atems auf* Lad schoma meine Schrotflinte!

– Warte isch mach erst Foto für de Bild!

Sehr schönes Bild. Wo genau ist das Questmonster? Das können Sie unmöglich übersehen.

Sind die Bäume Sprites?

Schrompf hat geschrieben:Sehr schönes Bild. Wo genau ist das Questmonster? Das können Sie unmöglich übersehen.

Stand da bereits hinter mir.

antisteo hat geschrieben:Sind die Bäume Sprites?

Das werde ich morgen früh nachgucken.

Duane Merrill, der Entwickler der Back40Computing CUDA-Bibliothek, arbeitet inzwischen bei NVIDIA an CUB. Mit dessen aktuellen Release ändert sich meine Empfehlung für die mit Abstand schnellste verfügbare Radix-Sort-Implementierung nun von B40C zu CUB. Hat bei mir die Sortierzeit eben von 11 ms weiter auf 7 ms gedrückt. Wenn das mal kein Speedup ist, nur durch Software!

Leider heißt das auch, dass eine kompetitive Sortierimplementierung in HLSL für mich jetzt in noch weitere Ferne rückt. Mein bestes Ergebnis in einer OpenCL-Testimplementierung war zuletzt 14 ms, also nun schon das Doppelte der bestmöglichen Zeit. :-/

Irgendwie macht es Spaß, wenn man Leute glücklich macht, indem man ihnen ihren Drucker unter Windows einrichtet und dafür genau so viel Geld (oder mehr) wie fürs Programmieren bekommt. Vielleicht ändere ich irgendwann mein Lebenskonzept und werde Außendienstmitarbeiter.

Die Druckerindustrie ist eine der verlogensten überhaupt; darum würde es mich nicht wundern, wenn bis heute kein WIRKLICH Plug'n'Play-tauglicher Drucker aus eben dem Grund existiert, dass solche sogenannten "Arbeitsplätze" damit vernichtet würden.

Schon mal einen Drucker unter Linux mit Cups zum Laufen gebracht? :) Das kommt gleich nach X11 / Wayland in der Konsole konfigurieren.

Gruß Kimmi

Hab ich gerade bei reddit gesehen, fand ich sehr interessant und hat mich irgendwie an Dich erinnert, Krishty :D

What language was RollerCoaster Tycoon programmed in?
It's 99% written in x86 assembler/machine code (yes, really!), with a small amount of C code used to interface to MS Windows and DirectX.

http://www.chrissawyergames.com/faq3.htm

Ja; die Grand Prix-Serie wurde auch von Geoff Crammond fast komplett in Assembler geschrieben.

LLVM Assembly ist für mich weiterhin ein Experiment bis ich es vollständig begriffen habe; aber langfristig plane ich, C++ nur noch für Prototyping zu benutzen.

Geoff Crammond hat geschrieben:Allerdings bin ich der Einzige, der meinen Code lesen und verändern kann. Ich kann es mir also nicht leisten, jemals krank zu werden.

:(