Anti-Jammer-Thread

Hier kann über allgemeine Themen diskutiert werden, die sonst in kein Forum passen.
Insbesondere über Szene, Games, Kultur, Weltgeschehen, Persönliches, Recht, Hard- und Software.
Benutzeravatar
CodingCat
Establishment
Beiträge: 1857
Registriert: 02.03.2009, 21:25
Wohnort: Student @ KIT
Kontaktdaten:

Re: Anti-Jammer-Thread

Beitrag von 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!
alphanew.net (last updated 2011-07-02) | auf Twitter | Source Code: breeze 2 | lean C++ library | D3D Effects Lite
Benutzeravatar
Artificial Mind
Establishment
Beiträge: 802
Registriert: 17.12.2007, 17:51
Wohnort: Aachen

Re: Anti-Jammer-Thread

Beitrag von 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 :)
Benutzeravatar
Artificial Mind
Establishment
Beiträge: 802
Registriert: 17.12.2007, 17:51
Wohnort: Aachen

Re: Anti-Jammer-Thread

Beitrag von 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;
}
Benutzeravatar
CodingCat
Establishment
Beiträge: 1857
Registriert: 02.03.2009, 21:25
Wohnort: Student @ KIT
Kontaktdaten:

Re: Anti-Jammer-Thread

Beitrag von CodingCat »

Das, was man als PIX kennt, ist in Visual Studio 11 fertig integriert: http://blogs.msdn.com/b/jasonz/archive/ ... eview.aspx
Bild
Etwas befremdlich ist, dass auch ein einfacher Modell- und Textureditor eingebaut sind.
NOCH erstaunlicher ist jedoch der eingebaute Node-basierte grafischer Shader-/Effekteditor:

Bild

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.
alphanew.net (last updated 2011-07-02) | auf Twitter | Source Code: breeze 2 | lean C++ library | D3D Effects Lite
klickverbot
Establishment
Beiträge: 191
Registriert: 01.03.2009, 19:22
Echter Name: David N.

Re: Anti-Jammer-Thread

Beitrag von 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
Benutzeravatar
CodingCat
Establishment
Beiträge: 1857
Registriert: 02.03.2009, 21:25
Wohnort: Student @ KIT
Kontaktdaten:

Re: Anti-Jammer-Thread

Beitrag von 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.
alphanew.net (last updated 2011-07-02) | auf Twitter | Source Code: breeze 2 | lean C++ library | D3D Effects Lite
kaiserludi
Establishment
Beiträge: 467
Registriert: 18.04.2002, 15:31

Re: Anti-Jammer-Thread

Beitrag von kaiserludi »

CodingCat hat geschrieben: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."
"Mir ist auch klar, dass der Tag, an dem ZFX und Developia zusammengehen werden der selbe Tag sein wird, an dem DirectGL rauskommt."
DirectGL, endlich ist es da
:)

"According to the C++ standard, it's "undefined". That's a technical term that means, in theory, anything can happen: the program can crash, or keep running but generate garbage results, or send Bjarne Stroustrup an e-mail saying how ugly you are and how funny your mother dresses you." :shock:[/size]
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Anti-Jammer-Thread

Beitrag von Krishty »

QueryProcessCycleTime() und QueryThreadCycleTime()

Nun kann ich meine Mikrooptimierungen endlich halbwegs zuverlässig messen …
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Jörg
Establishment
Beiträge: 296
Registriert: 03.12.2005, 13:06
Wohnort: Trondheim
Kontaktdaten:

Re: Anti-Jammer-Thread

Beitrag von 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...
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Anti-Jammer-Thread

Beitrag von 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.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Anti-Jammer-Thread

Beitrag von 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.)
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Anti-Jammer-Thread

Beitrag von 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.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Anti-Jammer-Thread

Beitrag von Krishty »

Dank dichtem Nebel konnte ich heute morgen zum ersten Mal mit bloßem Auge Sonnenflecken sehen.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Anti-Jammer-Thread

Beitrag von 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.)
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Anti-Jammer-Thread

Beitrag von 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.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
eXile
Establishment
Beiträge: 1136
Registriert: 28.02.2009, 13:27

Re: Anti-Jammer-Thread

Beitrag von eXile »

Hab mir mal die Windows Developer Preview mit Visual Studio 11 Express angeschaut:
  • Solution explorer:
    • Man kann jetzt die Dateianzeige auf bestimmte Unterordner einschränken (ähnlich der Funktionalität, die schon die Productivity tools brachten).
    • Für jede Datei kann man die enthaltenen Klassen-, Methoden- und Attributsdefinitionen anzeigen lassen (ähnlich der Funktionalität vom „Class View“-Fenster).
  • Neue solution properties:
    • Debugging → Debugger Type: GPU Only
    • Debugging → GPU Debugging Accelerator Type: GPU – DirectCompute Ref Emulator
      „The debugging accelerator type to use for debugging the GPU code.“
    • Debugging → GPU Default Breakpoint Behavior: Break once per warp
      „The CPU behavior is that every thread that hits a default breakpoint (i.e. non-conditional, non-filtered, etc) causes the debugger to break. Through this setting you can change the debugger to break only once per warp per kernel, or even only for a single warp (the first one that hits a default breakpoint) per kernel.“
    • Anscheinend steht das alles im direkten Zusammenhang mit C++ AMP; leider war in dieser Version alle weitere dahingehende Funktionalität deaktiviert.
    • C/C++ → All Options: Übersicht über alle C/C++-Optionen.
    • Linker → All Options: Dito für die Linker-Optionen.
    • HLSL Compiler: Alles einstellbar von Include directories, Entrypoint, Shader model bis Preprocessor definitions. „Effects compiler“ ist jetzt als Dateityp (so komisch es klingt) einstellbar (und bewirk natürlich, dass der fxc.exe zum Kompilieren dieser datei verwendet wird).
  • Text editor:
    • Quick find / Quick replace aus den Productivity tools eingebaut.
    • Man kann jetzt Tabs pinnen (bleiben immer ganz links in der Tab-Leiste).
    • Via „Go to definition“ aufgerufene Tabs sind nur Tabs zweiter Klasse (bleiben immer ganz rechts in der Tab-Leiste); man kann sie aber zu normalen Tabs „promoten“.
    • Syntaxhighlighting für HLSL-Dateien.
    • Keinerlei Intellisense für HLSL-Dateien.
    • Die Auto-Vervollständigung von Intellisense scheint besser geworden zu sein; zumindest werden schon während des Schreibens Vorschläge gemacht (z.B. ththis).
    • Es gibt jetzt Code-Snippets, aber das wird niemand benutzen. (Es gibt wirklich ein Snippet für { … }!)
  • Notepad versteht noch immer keine Newlines ohne Carriage-Returns.
Von der neuen PIX-Integration war noch nichts zu sehen – dazu braucht es wohl erst ein neues DirectX-SDK. Was wohl auch der Grund ist, warum bereits so lange kein neues erschienen ist.
Benutzeravatar
Jonathan
Establishment
Beiträge: 2353
Registriert: 04.08.2004, 20:06
Kontaktdaten:

Re: Anti-Jammer-Thread

Beitrag von Jonathan »

Alter, die **** geht! Und man sieht das geil aus!
Näheres in 2 Sekunden im WIP Thread, yay!
Lieber dumm fragen, als dumm bleiben!
https://jonathank.de/games/
Benutzeravatar
CodingCat
Establishment
Beiträge: 1857
Registriert: 02.03.2009, 21:25
Wohnort: Student @ KIT
Kontaktdaten:

Re: Anti-Jammer-Thread

Beitrag von CodingCat »

OOOkaay. So enttäuschend PhysX 3.0 in seiner äußeren Form war, so überraschend ist PhysX 3.1. Die haben es doch tatsächlich fertig gebracht, ihre Verzeichnisse zu ordnen, sämtliche relativen Includes zu fixen UND obendrein alles sauber in Namespaces zu verpacken. So liegt mir nun wohl das erste aufgeräumte PhysX SDK in der Geschichte vor, Wow!
alphanew.net (last updated 2011-07-02) | auf Twitter | Source Code: breeze 2 | lean C++ library | D3D Effects Lite
Benutzeravatar
CodingCat
Establishment
Beiträge: 1857
Registriert: 02.03.2009, 21:25
Wohnort: Student @ KIT
Kontaktdaten:

Re: Anti-Jammer-Thread

Beitrag von CodingCat »

Binärdateien Lesen mit Memory-Mapped Files, Zeigerarithmetik und Exception-Safety ist ein TRAUM! Wenn ich da an Java zurückdenke, als ich in den Genuss kam, zehntausende von Binärdateien wahlweise mittels Streams oder Byte-Buffer-Index-Schieberei in endlos langen Hilfsklassen auszulesen ...
Und wenn ich nicht die Hälfte meiner Zeit damit verbringen müsste, zwischen Headers und Compilation Units hin- und herzuspringen, und alle Deklarationen doppelt zu schreiben, C++ wäre DIE produktivste Sprache der Welt - DANK Zeigerarithmetik (und deterministischer Zerstörung)!
alphanew.net (last updated 2011-07-02) | auf Twitter | Source Code: breeze 2 | lean C++ library | D3D Effects Lite
j.klugmann
Establishment
Beiträge: 201
Registriert: 07.07.2010, 13:00
Kontaktdaten:

Re: Anti-Jammer-Thread

Beitrag von j.klugmann »

Die produktivste gleich nach Haskell? :D
Imaging-Software und bald auch Middleware: http://fd-imaging.com
kaiserludi
Establishment
Beiträge: 467
Registriert: 18.04.2002, 15:31

Re: Anti-Jammer-Thread

Beitrag von kaiserludi »

CodingCat hat geschrieben:Binärdateien Lesen mit Memory-Mapped Files, Zeigerarithmetik und Exception-Safety ist ein TRAUM! Wenn ich da an Java zurückdenke, als ich in den Genuss kam, zehntausende von Binärdateien wahlweise mittels Streams oder Byte-Buffer-Index-Schieberei in endlos langen Hilfsklassen auszulesen ...
Und wenn ich nicht die Hälfte meiner Zeit damit verbringen müsste, zwischen Headers und Compilation Units hin- und herzuspringen, und alle Deklarationen doppelt zu schreiben, C++ wäre DIE produktivste Sprache der Welt - DANK Zeigerarithmetik (und deterministischer Zerstörung)!
Header nerven zwar in der Hinsicht, dass man sich selbst darum kümmern muss, alles so zu inkludieren und zu deklarieren, dass jeder Codepart alles kennt, was er braucht, aber dafür hat man hinterher eine schöne Übersicht direkt im Code unabhängig davon, was die IDE kann und wie gut man sich in der IDe auskennt, über das Interface einer Klasse. Dass Java, C# und co. so etwas wie Header nicht haben, ist für mich kein Plus-, sondern ein dicker Minuspunkt dieser Sprachen gegenüber C, C++ oder objC!
"Mir ist auch klar, dass der Tag, an dem ZFX und Developia zusammengehen werden der selbe Tag sein wird, an dem DirectGL rauskommt."
DirectGL, endlich ist es da
:)

"According to the C++ standard, it's "undefined". That's a technical term that means, in theory, anything can happen: the program can crash, or keep running but generate garbage results, or send Bjarne Stroustrup an e-mail saying how ugly you are and how funny your mother dresses you." :shock:[/size]
Benutzeravatar
Krishty
Establishment
Beiträge: 8229
Registriert: 26.02.2009, 11:18
Benutzertext: state is the enemy
Kontaktdaten:

Re: Anti-Jammer-Thread

Beitrag von Krishty »

kaiserludi hat geschrieben:Header nerven zwar in der Hinsicht, dass man sich selbst darum kümmern muss, alles so zu inkludieren und zu deklarieren, dass jeder Codepart alles kennt, was er braucht, aber dafür hat man hinterher eine schöne Übersicht direkt im Code unabhängig davon, was die IDE kann und wie gut man sich in der IDe auskennt, über das Interface einer Klasse.
Wäre ja toll, wenn es wirklich nur die öffentliche Schnittstelle wäre. Aber nee, man muss ebenfalls alle geschützten und privaten Attribute, Methoden und Vererbungen auflisten.

Was die Kopie der Funktionsdeklarationen angeht, ist das so ein riesiger Verstoß gegen Don't Repeat Yourself, dass es der größte C++-Eiferer nicht mehr schönreden kann. Um da irgendwie rauszukommen haben sie Templates so formalisiert, dass diese abartigen Header-only-Bibliotheken entstanden sind, die deine Kompilierleistung dann endgültig mit ihrer Textwucht begraben.

Und zu guter letzt führt man damit in die Sprache ein in Zeit- und Speicherbedarf exponentielles Problem ein (da meist immer alle Header alle anderen #includen müssen, um ihre Abhängigkeiten aufzulösen), von dem ich aus Erfahrung sage, dass man es bei unter Zeitdruck entstandenen Projekten (also allem, was kommerziell ist) weder vermeiden noch durch steigende Rechenleistung besiegen kann – sondern nur durch den Rückgriff auf nicht-standardkonforme Erweiterungen wie Vorkompilierte Header. Fuck, sogar in meinem mit endloser Liebe zum Detail entstandenen Hobbyprojekt kriege ich keine Header-Struktur hin, die DirectX (und damit COM (und damit die WinAPI (und damit die CRT (und damit die STL (… merkst du, wo das hinführt?))))) vermeidet.

Es ist einfach nur ein riesiger, nutzloser Haufen stinkender Redundanz auf die ich a) keinen Bock habe; den b) zum Großteil der Compiler für mich erzeugen könnte; und c) der erst geschätzte 30 % der Entwicklungszeit frisst indem man Deklarationen mit Dokumentation anlegt, die man nie wieder aktualisiert, und danach nochmal 50 % indem man nach jeder kleinen Änderung im hintersten Popel-Header eine Viertelstunde neukompilieren muss.

So war mein Tag.
seziert Ace Combat, Driver, und S.T.A.L.K.E.R.   —   rendert Sterne
Benutzeravatar
CodingCat
Establishment
Beiträge: 1857
Registriert: 02.03.2009, 21:25
Wohnort: Student @ KIT
Kontaktdaten:

Re: Anti-Jammer-Thread

Beitrag von CodingCat »

Meine allergrößte Hochachtung.

Ich könnte mir nichts ätzenderes vorstellen,
als diesen ganzen Mist,
der die letzten 10 Jahre von CAD-Software herausgeschissen wurde,
zu analysieren, lesen und zu verpacken,
und den ganzen Mist dann
zu fixen, zu ergänzen und rundzulutschen,
und DAS dann noch
wiederverwendbar, ABI-sicher UND mit Support
allen frei zur Verfügung zu stellen.

Danke Aramis, Schrompf, kimmi. Danke, Danke, Danke!
alphanew.net (last updated 2011-07-02) | auf Twitter | Source Code: breeze 2 | lean C++ library | D3D Effects Lite
Benutzeravatar
Schrompf
Moderator
Beiträge: 4838
Registriert: 25.02.2009, 23:44
Benutzertext: Lernt nur selten dazu
Echter Name: Thomas Ziegenhagen
Wohnort: Dresden
Kontaktdaten:

Re: Anti-Jammer-Thread

Beitrag von Schrompf »

Support für die CAD-Files stammt alles von Aramis *finger zeig*
Früher mal Dreamworlds. Früher mal Open Asset Import Library. Heutzutage nur noch so rumwursteln.
Benutzeravatar
Aramis
Moderator
Beiträge: 1458
Registriert: 25.02.2009, 19:50
Echter Name: Alexander Gessler
Wohnort: 2016
Kontaktdaten:

Re: Anti-Jammer-Thread

Beitrag von Aramis »

(Wenn ich an die vielen Codeleichen und ungefixten Bugs in unserer Codebasis denke, wird mir schlecht.) Aber davon abgesehen, danke fuer die Blumen, ich freue mich immer wahnsinnig ueber ein "Dankeschoen", das nicht mit einer Supportanfrage gekoppelt ist :-)

PS: *zurueckzeig, er hat Collada gebaendigt*
kaiserludi
Establishment
Beiträge: 467
Registriert: 18.04.2002, 15:31

Re: Anti-Jammer-Thread

Beitrag von kaiserludi »

Was lernen wir daraus? Supportanfragen und Dankeschöns immer separat, nicht aneinander gekoppelt -> Gefühlsachterbahnfahrt für Aramis *g*
"Mir ist auch klar, dass der Tag, an dem ZFX und Developia zusammengehen werden der selbe Tag sein wird, an dem DirectGL rauskommt."
DirectGL, endlich ist es da
:)

"According to the C++ standard, it's "undefined". That's a technical term that means, in theory, anything can happen: the program can crash, or keep running but generate garbage results, or send Bjarne Stroustrup an e-mail saying how ugly you are and how funny your mother dresses you." :shock:[/size]
Benutzeravatar
eXile
Establishment
Beiträge: 1136
Registriert: 28.02.2009, 13:27

Re: Anti-Jammer-Thread

Beitrag von eXile »

Benutzeravatar
CodingCat
Establishment
Beiträge: 1857
Registriert: 02.03.2009, 21:25
Wohnort: Student @ KIT
Kontaktdaten:

Re: Anti-Jammer-Thread

Beitrag von CodingCat »

Ich habe in der letzten Studen sieben coole Assets selbst kreiert. Blender rulet, und jetzt fühle ich mich schon fast wie ein Pro-Modeller!
(Na gut, ich gebs zu, alles aus Quadern ...)
alphanew.net (last updated 2011-07-02) | auf Twitter | Source Code: breeze 2 | lean C++ library | D3D Effects Lite
Benutzeravatar
CodingCat
Establishment
Beiträge: 1857
Registriert: 02.03.2009, 21:25
Wohnort: Student @ KIT
Kontaktdaten:

Re: Anti-Jammer-Thread

Beitrag von CodingCat »

Eine Steintextur tileable gehört wohl zu den meditativsten Dingen, die ich je gemacht habe. Und dank genialer kognitiver Fähigkeiten bezüglich Mustererkennung weiß das Hirn natürlich trotzdem gleich, was Sache ist. :(
alphanew.net (last updated 2011-07-02) | auf Twitter | Source Code: breeze 2 | lean C++ library | D3D Effects Lite
Benutzeravatar
Chromanoid
Moderator
Beiträge: 4254
Registriert: 16.10.2002, 19:39
Echter Name: Christian Kulenkampff
Wohnort: Lüneburg

Re: Anti-Jammer-Thread

Beitrag von Chromanoid »

gerade drüber gestolpert: http://blogs.amd.com/developer/2011/09/ ... e-aparapi/ find ich cool. Eine vernünftige Java API für OpenCL... Java byte code wird direkt in OpenCL Code umgewandelt. http://code.google.com/p/aparapi/
Antworten