Anti-Jammer-Thread

[j.klugmann]

Nyan!

[Schrompf]

Ich hab zwar keine Ahnung, was Du damit meinst, aber dadurch hab ich mal auf Deinen Signaturlink geklickt. Und ich muss sagen. "HALTET DEN DIEB!" :-) Ne, im Ernst: sieht gut aus. Mich würde dabei aber interessieren, was Du vor hast, um Dich von den normalen Stadt-Aufbau-Spielen abzugrenzen?

Eigen-Freude: Version zur AMaze Indie Connect ist eingereicht. Einen Tag zu spät, weil ich Trottel mich verlesen hatte und damit wochenlang auf den falschen Termin fixiert war. Aber der Betreiber da ist wirklich cool drauf, der hat mit ein paar Mühen die Anmeldung nochmal für uns aufgemacht. Und *wie immer* finden sich ein paar richtig fiese Bugs erst um 23:35 Uhr ... ordentlich Adrenalin ist garantiert.

[j.klugmann]

Hehe, guck mal auf der Startseite in den Showroom. Da läuft eine kleine Nyan-Katze über den Screen. :P

Wolkenwelt ist leider tot, ich sollte mal meine Signatur ändern. ;)

[Chromanoid]

Schade, das wäre sicher auch was als Browsergame und iOS/Android Spiel.

[Jonathan]

Ja, Nyan Cat ist eine geile Idee :)
Lob an wer immer das auch ausgedacht und umgesetzt haben mag!

[dot]

Jap, Kudos für die Nyan Cat, hab heut Nacht schon gelacht :lol:

[eXile]

Pah, das einzig Gute ist doch, dass man sie abschießen kann …

[Krishty]

RDTSC soll man zwar nicht für Zeitmessung einsetzen, für die Erzeugung schwacher Zufallszahlen ist es aber fast perfekt:

• __rdtsc() modifiziert nicht den globalen Programmzustand; man führt also keine zusätzlichen Wirkungen ein (im Gegensatz zu „echten“ Pseudozufallszahlengeneratoren, die irgendwo über Aufrufe hinweg ihren Zustand speichern und ändern müssten, ist der Time Stap Counter eh immer da und eh immer read-only).
• Der Wert ändert sich schnell genug, um bei jedem Aufruf was anderes zurückzubekommen.
• Es ist um ein Vielfaches schneller als QueryPerformanceCounter(), das zwecks Hardware-Abstraktion nicht nur bloß eine geringere Auflösung liefern könnte, sondern auch erst in den Kernel-Modus schalten müsste.

[eXile]

Dank Meldungen wie dieser hier werden endlich die meisten nahmhaften Softwareanbieter gezwungen sein, high-DPI aware Anwendungen zu schreiben.

Mir graut es nur davor, irgendwann auch mal wirklich 4800×2700 Pixel pro Frame zu shaden (6,25-mal so viele Pixel wie Full-HD). Wenigstens wird man dann wohl kein Rasterisierungs-Anti-Aliasing mehr brauchen (alle anderen Aliasing-Fehler bleiben natürlich unberührt).

Oder wir müssen in ein paar Jahren dann immer eine Lupe verwenden, was bei der aktuellen Softwarequalität nicht verwunderlich wäre.

[CodingCat]

The Programming Languages Beacon - Hauptsächlich C++, kaum Java, und C# ausschließlich in Microsoft Visual Studio. ;-)

Nur schade, dass die Entwickler im großen C++-Schwung nicht gleich auf eine bessere Sprache ausweichen konnten. Aber vielleicht entsteht so auch erst der Druck, der C++ in 20 Jahren zu einer guten Sprache macht.

[kaiserludi]

The Programming Languages Beacon - Hauptsächlich C++, kaum Java, und C# ausschließlich in Microsoft Visual Studio. ;-)

Nur schade, dass die Entwickler im großen C++-Schwung nicht gleich auf eine bessere Sprache ausweichen konnten. Aber vielleicht entsteht so auch erst der Druck, der C++ in 20 Jahren zu einer guten Sprache macht.

Es zeigt eben, dass für die meisten Fälle C++ auf dem heutigen Stand immer noch die beste Option ist, auch wenn es sich nicht perfekt ist, weil einfach die alternativen noch viel schlechter sind.

Scheint mir aber arg ungenau zu sein die Tabelle. Wenn ich mir OS X / iOS so anschaue, so sollte da stehen: Internals und low level API in C, high level API in objC. Auf Applikationsebene kommt man dort im Grunde überhaupt nicht mit der C-API in Berührung und um objC nie komplett drumherum, da man z.B: die Touch UI vom iOS gar nicht auf anderem Wege ansprechen kann. Mann kann aber dennoch durchaus 99% seines Codes rein in C++ schreiben und das ist sogar in der Regel die beste Wahl gegenüber objC, einfach weil man sich die Portierbarkeit offen hält, ohne den ganzen Code erst in eine andere Sprache übersetzen zu müssen.

Android mag im Core zum größten Teil in C sein, die API ist aber in Java bzw. dazu noch eine Wrapper-API in C++ vorhanden, eine reine C-API hingegen existiert nicht.

Und das ist doch das entscheidende für uns als Entwickler: In welchen Sprachen sind die APIs der wichtigen Frameworks, nicht in welchen sind irgendwelche Apps, mit denen wir eh nur als Binary in Kontakt kommen.

[Chromanoid]

Ziemlich einseitige Tabelle, aber das ist dir ja sicher klar, du willst nur foppen :D
http://www.tiobe.com/index.php/content/ ... index.html finde ich interessanter, interessant auch, dass C jetzt oben ist...

[dot]

Also wenn du den Tiobe Index für aussagekräftig hältst, dann hab ich ein richtiges Orakel für dich: http://www.googlefight.com/ ;)

[Chromanoid]

aussagekräftiger als die tabelle, _aussagekräftig_ nicht, ich sehe den index eher als gewisses indiz...

[antisteo]

Krankheit überstanden,
mit neuer Kraft gehts an Projekte.

(Und was ich mal so nebenbei sagen wollte: node.js ist cool)

[CodingCat]

Ich liebe C++. Aus Bequemlichkeit der Typsicherheit mit expliziten Casts das Genick brechen und zugleich für maximale Sicherheit durch das Typsystem den Typ mit Tag-Enum-Template-Argumenten annotieren.
So unvollkommen die Metaprogrammierung mit C++ auch noch immer ist, so sehr hat mir dieses Gefühl von Intelligenz und Überlegenheit nach gelungenem Template-Entwurf auch gefehlt. :mrgreen:

[CodingCat]

Twitter Introduces Innovators Patent Agreement. Ein kleiner Schritt für die Menschheit, und doch ein großer Schritt in die richtige Richtung.

[CodingCat]

Ich weiß nicht so recht, wohin damit, also kommt es einfach hier rein:

UAV Counter Alternative

• Create a 1x1 UAV, this “Global Counter” is used to allocate links in our linked lists. Initialized to 0.
• Instead of IncrementCounter(), get the current value of Global Counter and increment it using InterlockedAdd().
• All threads will be fighting for atomic access in global memory (Could use a NxN buffer with pixel sub-counters to improve performance)
• The global counter method is ~30% slower than using the UAV counter

Was läuft da richtig/falsch?

Egal, folgendes kommt mir dazu in den Sinn: Ist so ein UAV-Counter dann nicht ideal für Stream Compaction bei gleichzeitiger Vermeidung von Bankkonflikten? Mir schwebt folgendes vor: Jeder GPU-Thread zählt seine (unkompaktierten) Datenpakete und ruft für jedes Paket einmal IncrementCounter() zur Allokation eines Speicherslots im Puffer auf. Liegt es nicht in der Natur der SIMD-Architektur, dass benachbarte Threads dies einigermaßen synchron tun, und so ihre Datenpakte gerade nach dem Reißverschlussprinzip bankkonform und kompakt nebeneinander in den Puffer legen?

Wäre das dann nicht wesentlich günstiger und zugleich optimaler als eine deterministische Präfixsumme, welche die Daten obendrein uninterleaved so perfekt nebeneinander in den Speicher legen würde, dass mit massig Bankkonflikten gerechnet werden müsste?

[Schrompf]

Nach meinem Verständnis würden benachbarte Threads nicht im Reißverschlussprinzip, sondern wirklich parallel zu inkrementieren versuchen, und damit die Konfliktanzahl maximieren. Die zitierte Methode würde dagegen nur einmal pro Fragment incrementieren, was bei Shaderlängen von potentiell hunderten Befehlen nur alle Jubeljahre mal zu Konflikten führen würde.

[Jonathan]

Die ANimationen sehen jetzt in meinem Viewer so aus, wie im Assimp Viewer. Ein kleiner Bug muss noch irgendwo im Ogre-Importer sein, aber ansonsten scheint es jetzt echt zu funktionieren. Noch etwas Feinschliff und ich poste mal was richtiges dazu. Soviel vorweg: Beschlossen dass ich Animationen programmieren will, hab ich wohl so ungefähr zu dieser Zeit in 2008 :D

[FredK]

Glückwunsch; wenn es dich aufmuntert: Bei mir sind zwischen dem Zeitpunkt, an dem ich angefangen hab Animationen zu programmieren und sie fertig hatte auch ca. 2 Jahre ins Land gezogen. Wenn ich nun auch noch überlege, wann ich BESCHLOSSEN hab Animationen zu programmieren... NEIN, ich will da gar nicht dran denken, sonst fühl ich mich so alt. :lol:

[eXile]

Kurze Durchsage: Ich habe mal alle meine mathematischen Beiträge auf MathJax umgestellt, und benutze keine halb-garen externen Anbieter mehr. Kurze Auswahl:

• Normal Interpolation
• Radiosity
• Beleuchtung durch Environment Map
• Globaler volumetrischer Nebel
• BRDF für Reflektion
• Diffuser Shader - Normalen-Transformation?

Wenn hier jemand noch mit der LaTeX-Syntax struggelt, kann derjenige einen Blick auf den LaTeX-Code werden (einfach auf „zitieren“ beim jeweiligen Beitrag klicken).

Insbesondere wenn man den Zeilenabstand beispielsweise via \\[-5pt] verringern will, klappt das mit MathJax noch nicht, aber der Bug ist bereits gemeldet, und man kann ihn via /smash{…} und einem positiven Abstand (z.B. \\[5pt]) umgehen.

[CodingCat]

D3DX ist gar nicht tot, nur verteilt. DirectXTex (*.dds Loader, Block Compression, ...), DirectXMath, DirectXTK (C++-Varianten von XNA-Hilfsklassen: Sprite Batch, Sprite Font, Bitmap Font Conversion Utility, State Management, Input Layout Management, ...). Muss ich bei Gelegenheit mal reinsehen.

[Artificial Mind]

Ich habe Variance Shadow Maps für mich entdeckt. Ergeben richtig schöne weiche Schatten, ohne Magic Numbers (*hust*depth * .999999 - .000001*hust*) zur Artefakt-Bereinigung und haben selbst bei geringer ShadowMap-Auflösung ein gutes weiches Ergebnis. Die Geschwindigkeit ist dabei auch nicht langsamer als PCF.
Bei all diesen Vorteilen kann ich sogar das Light Bleeding verkraften, das bei meiner naiven Implementierung an einigen Stellen auftritt.

Variance Shadow Mapping

[Schrompf]

Exakt das Light Bleeding hat mich immer aufgehalten, es überhaupt zu probieren. Deine Szene sieht aber auch gut geeignet aus. Und allgemein gut aus :)

[Artificial Mind]

Vielen Dank ;) Ich mach grade für mein Studium ein Softwarepraktikum, in welchem wir ein Pinball-Game programmieren müssen und ich bin halt für die Effekte zuständig.
Das Light Bleeding tritt eigentlich nur auf, wenn aus mehreren Höhen, die verhältnismäßig weit auseinander liegen, Schatten auf eine gemeinsame Fläche fällt (Sich also Schatten verschiedener Höhen "überlagern"). Ganz unten auf der Fläche gibt es dann das Light Bleeding, da dort die Varianz abnormal hoch ist. Kann man aber auch vermeiden, indem man die Varianz limitiert oder den Blur etwas intelligenter macht und so ein Spaß.

[Schrompf]

Danke für die Tipps. Ich muss das mal bei Gelegenheit ausprobieren... aktuell sieht 32xPCF bei den Splitterwelten auch gut aus, aber es frisst doch Grafikkarten zum Frühstück. Und mit VSM eröffnen sich auch viele Möglichkeiten, eine korrekte Penumbra zu simulieren. Nur das Light Bleeding macht mir mal Sorgen - bei den Splitterwelten sind solche Mehrfach-Tiefen-Szenarien mit Bergen fern, Bäumen in der Mitte und nahen Charakteren eigentlich an der Tagesordnung. Aber VSM ist ja auch schnell implementiert, also ist es einen Versuch wert.

[dot]

Wieso VSM und nicht ESM?

[Artificial Mind]

Wieso VSM und nicht ESM?

Ja, hab mir grade das Paper durchgelesen und implementiert. Das verhindert tatsächlich das Light-Bleeding in den meisten Fällen und sieht gut aus. Ich bin von meinem 9x9 Gauß-Filter auch zurück auf einen 5x5 gegangen, da die Schatten zu weich waren :D
Viele Dank für den Tipp ;)

Nachtrag: Es ist sogar noch schneller als VSM implementiert O.o

[CodingCat]

Thought you're done? Chen, Tatarchuk – Lighting Research at Bungie. Ganz viele Slides und Tipps zu ESM. ;)