Jammer-Thread

[kimmi]

Ich glaube, du nimmst HLSL einfach zu persönlich :). versuch doch mal Freude aus deinen Erkenntnissen zu ziehen.

Gruß Kimmi

[Krishty]

Der Drecks-Code ist viermal so lang wie in C++ und komplett redundant – worüber soll ich mich da freuen?!? Wenn mir HLSL heute nochmal so auf den Kopf kackt, packe ich wieder meine Programmiersprache aus und bastle dafür einen eigenen Shader-Compiler … ich glaube nämlich mittlerweile wirklich, dass ich sowas besser hinbekäme als Nvidia, Microsoft und ISO zusammen …

… oder eine Zeitmaschine ins Jahr 2006, wo ich noch mit Shader-Assembly hantieren durfte …

Achja – lustig wird es auch, wenn sie sich irgendwann entschließen, Zeiger in die Sprache aufzunehmen. Da sie nämlich const nur als Präfix zulassen, wird jeder aus der C-Eck migrierte Programmierer die const-Correctness verhauen. const float const *, klar. Diese Sprache wird früher oder später wie ein Kartenhaus in sich zusammenstürzen, weil sie sich seit 2001 mit SM-2.0-GPUs und VC6-Mongos nicht mehr weiterentwickelt hat.

Edit: Shader@0x00150000(298,2): error X3695: race condition writing to shared memory detected, consider making this write conditional.
Da tritt keine Race Condition auf; die Flow-Control des Compilers ist einfach zu blöd, das Bit-Gepfriemel richtig aufzulösen. Und selbst, wenn eine aufträte, wäre es mir schnurzpiepegal weil die Operationen durch Memory-Barriers getrennt sind. Für heute habe ich die Schnauze voll. Sollen die sich doch ohne mich im Arsch rumpopeln.

[pUnkOuter]

Dieser Thread ist echt erheiternd.

[Krishty]

Okay, die Race-Condition war tatsächlich mein Fehler; weil das dumme HLSL kein by-reference kennt. Plastikkacke; kann ich ja gleich Java programmieren. Bleibt das Problem, dass der Compiler zu langsam ist … ich habe hier acht Shader, die je zehn Sekunden zum Kompilieren brauchen – inakzeptabel.

[Aramis]

Moooooment. Der Compiler hat dich mit seiner absolut korrekten Codeanalyse vor einem schweren Fehler gerettet, und jetzt meckerst du immer noch auf ihm rum? :-) Ich glaube, das waere nun langsam der Punkt an dem ich als Compiler mir absichtlich etwas mehr Zeit lassen wuerde …

[Krishty]

Der hat sich damit höchstens selber gerettet.
Ist jawohl das Mindeste, wenn man so beschissene Call-Conventions einbaut und dabei nicht einmal in / out / inout erzwinge um klarzustellen, was da vonstatten geht.

[eXile]

Bleibt das Problem, dass der Compiler zu langsam ist … ich habe hier acht Shader, die je zehn Sekunden zum Kompilieren brauchen – inakzeptabel.

Natürlich ist das inakzeptabel, aber einfach via Caching lösen: Vorkompilierte Shader benutzen und mit timestamp versehen (oder halt das Erstellungsdatum nehmen, wenn du die im Dateisystem abspeicherst), und dann die Shader nur neukompilieren, wenn wirklich Änderungen vorliegen. Oder direkt ein eigenes Build-System mit neuem Compiler schreiben …

[Krishty]

Vorkompilierte Shader benutzen und mit timestamp versehen (oder halt das Erstellungsdatum nehmen, wenn du die im Dateisystem abspeicherst), und dann die Shader nur neukompilieren, wenn wirklich Änderungen vorliegen.

Japp, muss ich echt tun. Ich brauche ja darüber hinaus noch eine Bibliothek, die es mir erlaubt, einzelne Shader für bestimmte Architekturen zu spezialisieren usw … komme also nicht drumherum. Es ist nur eben wieder so viel Mühe -.-

[joggel]

Es ist schon schade!
Unser Projekt eines 2D-RTS für die ZFX-Action-III mussten wieder niederlegen.... :(

[Schrompf]

Warum? Erzähl mal ein bisschen, vielleicht kann man ja was draus lernen.

[joggel]

Mmhh... da gibts eigentlich nicht viel zu erzählen.
Wiegesagt habe ich immernoch kein Internet.... das Projekt stagnierte schon über eine oder zwei Wochen.
Das Server-Client-Modell was wir, besser gesagt, "anonym" sich überlegt hat, ist nicht geeignet für RTS. So wie ich das verstanden habe, muss man bei einem RTS eine spezielle Server-Client-Architektur einführen.. aber dazu kenne ich mich zu wenig aus.

Der Hauptgrund ist auch der Zeitplan den wir nicht einhalten können.
Die Aufgabenverteilung war schlecht organisiert (fast garnicht).
Das Projekt wurde sehr schlecht geplant..

Ich habe zumindest etwas gelernt:
- eine gute Planung ist das A-und-O!
-> wie soll das Spiel aussehen
-> was soll es können
-> so viel wie möglich spezifizieren
- die Aufgaben müssen gut verteilt sein

[Edit]
Noch was zu sagen: Ich fand es trotzdem eine schöne Zusammenarbeit... bis wir halt nicht mehr weiterkamen :roll:

[Krishty]

Der Shader-Compiler ist echt verrückt. Auf höchster OptimierungsStufe braucht er 20 min pro Shader (!) und das Resultat ist dasselbe wie ohne Optimierung (10 s). AMDs GPU ShaderAnalyzer hört irgendwie ab 320 Instruktionen auf, Statistiken anzuzeigen.

Und warum müssen diese Butterfly-Diagramme so verdammt kompliziert sein? Für eine Radix-8-FFT habe ich fast einen ganzen Tag gebraucht; an Radix-16 mag ich garnicht denken. Dabei scheint die nötig zu werden; eine 2048²-FFT geht gerade mal mit 60 fps – nicht viel, wenn man bedenkt, dass acht davon pro Frame performed werden sollen. Die inverse FFT wird lustig … da darf ich dann die ganzen Butterflies nochmal verkehrt herum erarbeiten -.-

[Schrompf]

Und das alles für die korrekte Lichtstreuung des Mondes in den Augen des Betrachters. "Verhältnismäßigkeit" könntest Du wahrscheinlich nichtmal mehr mit Souffleuse buchstabieren :-)

[Krishty]

Es geht halt nicht anders! Ohne sieht man Sonne und Mond schlicht und einfach nicht, weil sie zu klein sind. Gauss sieht völlig beknackt aus. Und ein Näherungsfilter, der einen genügend großen Bildbereich einschließt, kommt selbst mit Downsampling-bedingtem Zittern, Flackern und Aliasing auf nicht mehr als 10 fps. Ich habe schlicht und einfach den Punkt überschritten, ab dem sich herkömmliche Filter-Tricksereien noch lohnen.

Aber das mit der Souffleuse ist gut.

[eXile]

Ich lehne mich zurück und gucke, was bei rauskommt. Ich hatte noch nie Zeit, das selber zu implementieren, und würde das vielleicht einem Studenten draufdrücken, aber da du das jetzt ja machst … :D

Nein im Ernst: Ich finde deinen Einsatz toll und bin brennend an den Ergebnissen (und natürlich an dem Weg dorthin) interessiert! Go for it! ;)

[Krishty]

Zurücklehnen? Nix da! Du wirst mir schön unter die Arme greifen, wenn meine Mathematik auf Siebtklässlerniveau nicht mehr ausreicht.

GPU Shader Analyzer verweigert Statistiken nicht ab einer bestimmten Anzahl von Befehlen, sondern ab einer bestimmten Anzahl von Synchronisationsoperationen. Danach bleibt diese Funktion deaktiviert, bis ich explizit eine Synchronisation einbaue, auskommentiere und wieder einbaue. Weird.

Und warum müssen die System-Value-Semantics für Compute-Shaders so ähnlich heißen? SV_ThatGroupInternalNumber oder SV_ThatGlobalThreadNumber würden mir bedeutend viele Fehler sparen :roll:

[Krishty]

Code: Alles auswählen

DWORD WINAPI SetFilePointer(
  __in         HANDLE hFile,
  __in         LONG lDistanceToMove,
  __inout_opt  PLONG lpDistanceToMoveHigh,
  __in         DWORD dwMoveMethod
);

HANDLE WINAPI CreateFileMapping(
  __in      HANDLE hFile,
  __in_opt  LPSECURITY_ATTRIBUTES lpAttributes,
  __in      DWORD flProtect,
  __in      DWORD dwMaximumSizeHigh,
  __in      DWORD dwMaximumSizeLow,
  __in_opt  LPCTSTR lpName
);

Die eine Funktion erwartet Dateigröße in DWORDs, die andere in LONGs. Ich muss die Variable also tatsächlich doppelt anlegen, um dieses vollkommen zerpflückte „Typsystem“ der WinAPI zu befriedigen. Das kann doch echt nur böser Vorsatz sein …

[Krishty]

Hey, heute könnte ein neuer Rekordtag werden …

Der GPU Shader Analyzer kompiliert meine Shader ohne zu zicken, allerdings etwa 10× langsamer als meine Anwendung (die braucht „nur“ zwei statt 20 Minuten). Allerdings gibt es noch einen pikanten Unterschied: Der GPU Shader Analyzer ist immer erfolgreich; der D3D-Compiler versagt, sobald die Optimierungen über Level 1 eingestellt werden. Mit meiner Lieblingsmeldung error X3695: race condition writing to shared memory detected, consider making this write conditional., diesmal aber auf eine Variablendeklaration zeigend (statt, wie früher, auf einen Schreibvorgang). Yeah. Diesmal ist da wirklich keine, es sei denn ER hat eine eingebaut.

Ein kleiner Blick in die Interna des aktuellen D3D-Shader-Optimizers:

Der Stock sind meine 32 KiB Group-Shared-Memory.

[Krishty]

Verdammt. Ich habe einen Speicherfehler … den ersten seit einer Ewigkeit … die Adressen meiner Funktionsparameter (und wirklich nur deren, nicht etwa auch die der lokalen Variablen) verschieben sich um 20 Bytes, sobald in einer Funktion eine Exception geworfen wurde (was für den Inhalt der Parameter (Referenzen) natürlich katastrophal ist).

Und ich habe wirklich keinen Plan, was ich nun noch machen soll außer drumherum zu bauen … reproduzieren lässt es sich nicht. Debugging ist auch schon unangenehm, weil der Fehler nur in voll optimiertem Release-Code auftritt. Im Debug-Build sind alle Sicherheitsfeatures aktiviert, die irgendwer irgendwie irgendwann in VC implementiert hat, und sie alle machen keinen Mucks … kein Schreiben über Bereichsgrenzen, kein kaputter Stack, nichts. Komplett-Rebuild habe ich auch schon durchgeführt.

Tjoa.

Achja – Sprachdurchmischung ist scheiße, insbesondere bei Komposita. Nicht nur, dass wir der englischen Sprache unsere Deppen Leerzeichen zu verdanken haben, nein – umgekehrt schreiben sie wegen kompositionsfähigen Sprachen auch bytecode zusammen, aber source code getrennt. Schlimmer als Syntaxschweine in Programmiersprachen sind wirklich nur die Idioten, die natürliche Sprachen verhunzen.

Und ich liebe die feinen Nuancen von C++: error C2440: 'initializing' : cannot convert from 'const char []' to 'const char []'

[Chromanoid]

Und ich habe wirklich keinen Plan, was ich nun noch machen soll außer drumherum zu bauen … reproduzieren lässt es sich nicht. Debugging ist auch schon unangenehm, weil der Fehler nur in voll optimiertem Release-Code auftritt. Im Debug-Build sind alle Sicherheitsfeatures aktiviert, die irgendwer irgendwie irgendwann in VC implementiert hat, und sie alle machen keinen Mucks … kein Schreiben über Bereichsgrenzen, kein kaputter Stack, nichts. Komplett-Rebuild habe ich auch schon durchgeführt.

Wegen solchen Späßen habe ich C-- Programmierung hassen gelernt. Das sind immer die schönsten Sachen, wenn einem VC um alles schöne Sicherheitsbuffer baut von deren unbeabsichtigter Nutzung erfährt man dann erst beim Versuch eine Release-Version auszuführen. Bei mir damals hing das mit meiner Unerfahrenheit in C++ zusammen (habe Mist bei Mehrfachvererbung gebaut), aber dennoch hat mir diese kleine mehrtägige Suche nach den Speicherlecks soviel Spaß gemacht, dass ich C++ am liebsten nicht mehr anrühre. Bei Java oder C# gibts wesentlich weniger Fallen, die einem so langfristig die Motivation rauben können...

[Krishty]

[…] aber dennoch hat mir diese kleine mehrtägige Suche nach den Speicherlecks soviel Spaß gemacht, dass ich C++ am liebsten nicht mehr anrühre.

Du meinst Pufferüberläufe oder Zugriffsverletzungen, oder? Wäre ja ironisch, wenn sich jemand aus der Managed-Ecke über Speicherlecks beschweren würde ;)

Da hat sich in den letzten Jahren viel getan (vor allem, weil Speicherfehler jetzt als große Sicherheitsrisikos angesehen werden) – meine ersten Programme, noch mit VC6 geschrieben, halten in Debug-Builds an gefühlten 100 Zeilen an, wenn sie mit VC 2010 kompiliert werden. Die Möglichkeit, heute trotz aktivierter Sicherheitsfeatures noch den Stack zu korrumpieren, dürfte irgendwo bei eins zu tausend liegen … und da habe ich wohl direkt ins Klo gepackt, yay.

[Chromanoid]

ja das war damals mit vc6... bezüglich speicherlecks: ja ich meinte natürlich zugriffsverletzungen...

[Krishty]

ich hasse ADL

like, REALLY

[Schrompf]

Architektur/Dekoration/Lichtinstallation?

Ich hasse Bones und Bone-Anims. Immer, wenn ich denke, dass ich endgültig alle Aspekte begriffen und umgesetzt habe, passiert mir sowas:



Und ich fürchte, ein substanzieller Teil dieses Elends wird im Importer verborgen sein - es steht also auch nochmal eine dicke Assimp-Debugsession ins Haus. Ich mag net...

[Jonathan]

Immer wieder schön, diese Animationsfehler :) Haben mir die Motivation geraubt, den Ogreimporter endlich fertig zu stellen (kommt aber ganz bestimmt irgendwann noch *g*).

Btw.: Ihr hab schön viele Icons im Editor, sieht ja echt mal so aus, als könne der ne Menge. Lust auf ne kurze Vorstellung (vom Spiel gibts ja schon einige)?

[Jörg]

Ich finde das Schattengrizzeln viel ekliger...das mit den Bones bekommt man ja schnell wieder hin ;)

[Schrompf]

Das sagst Du! :)

@Jonathan: nuja... was soll ich sagen. Ja, der Editor kann inzwischen eine Menge. Leider praktisch alles spezialisiert auf unsere Datenbasis. Das Ding basiert auf einem Rudel Aktionen, die eine schlichte Schnittstelle der Art ausfüllen:

Code: Alles auswählen

class BasisAktion
{
  virtual bool KannMitAuswahl( const AuswahlMap& aktuelleAuswahl) const;

  virtual void Aktivieren();
  virtual void LinkeMaustasteRunter( ...klickstrahl... );
  virtual void LinkeMaustasteBewegt( ...klickstrahl... );
  virtual void LinkeMaustasteHoch( ...klickstrahl... );
  // ... das gleiche für die rechte Maustaste
  virtual void Deaktivieren();
};

Mehr ist es nicht. Der Editor prüft bei jeder Änderung der aktuellen Objektauswahl, welche der Aktionen damit arbeiten können, und graut die Verweigerer aus. Die eigentliche Bedeutung der Klicks implementiert dann die aktuell aktive Aktion (aaA). Und davon gibt's inzwischen einige: Objektmanipulationen wie Erstellen, Löschen, Bewegen, Rotieren, Geometriebearbeitung wie Punkte und Flächen erstellen, löschen, bewegen, Normalen bearbeiten, UVMapping, aus Splines erstellen usw. Dazu gibt es ein abstraktes Interface, um Eigenschaften zu editieren, die die aktuelle Objektauswahl gemeinsam hat, und ein ganzes Rudel Bearbeitungsdialoge für bestimmte Objektklassen - Partikeleditor, Wesen, Inventar, Gegenstände, Interagierbares. Und obendrauf gibt es noch nicht-objektbezogene Bearbeitungsdialoge, z.B. für Cutscenes/Dialoge, Queststrukturen, globales Gedächtnis usw. Alles wie gesagt sehr speziell auf unsere Datenbasis ausgelegt. Und man sieht es auf dem Screenshot nicht, weil ich die ganzen größeren Toolbars auf den zweiten Monitor geschoben habe.

@Jörg: jaja.... die Schatten. Ich finde die jetzt nicht so schlimm, sie sind mir nur noch zu wenig aufgelöst. Vielleicht bau ich irgendwann mal PSSM oder sowas ein, auch wenn ich dafür dann die Szene xmal in die ShadowMap rendern muss. Grmpf. Die aktuelle SinglePass-Lösung hat halt ihre Grenzen.

[Krishty]

Bescheuerter Flash-Player mit seinen spastischen Anfällen … Bug #39: fängt nach dem Ruhezustand doch tatsächlich schon auf dem Anmeldebildschirm an, alle YouTube-Videos so lautstark abzuspielen wie möglich (und wartet nicht – wie sonst – darauf, dass ich die Lautsprecher für eine besonders leise Filmdatei voll aufgedreht habe). Aber Hauptsache, man baut Snake ein. Google gehört dafür echt kopfüber ins Klo getunkt. Aber andererseits würde ich in ein Portal, das zum Großteil von 14-Jährigen am Leben gehalten wird, die im Movie Maker falsch aus dem Internet abkopierte Liedtexte zu Videos zusammenpfriemeln, auch nicht viel Arbeit investieren.

[Aramis]

Ich bin mir nicht sicher ob das Problem vonseiten des YouTube-Players ueberhaupt zu loesen ist. Immerhin muesste Flash dafuer Informationen ueber den aktuellen Status des Betriebssystems/Benutzers durchreichen.

[Krishty]

Doch. Der YT-Player merkt doch überhaupt nichts davon, dass das System in den Standby-Zustand wechselt oder wieder aufwacht – andere Player und Plugins resetten sich dabei schließlich auch nicht.

Es ist ja nicht so, als dass die Videos liefen, als ich den Rechner in den Ruhezustand versetzte … alle paar Tage resetten sich einfach so gleichzeitig alle YouTube-Videos, die offen sind (laden neu und spielen sich ab) … war mit Firefox unter Vista x64 so und ist mit Chrome unter 7 x64 immernoch so. Ich vermute, dass das diesmal zufällig zu dem Zeitpunkt geschah, als das System noch auf dem Anmeldebildschirm war. Ich unterstelle einfach mal, dass da ein Timer zwecks Aktualisierung und Rechtemanagement im Hintergrund läuft. Oder GetTickCount() läuft über :)