Artikelempfehlungen, interessante Publikationen o.Ä.

[Jonathan]

Ich fand PHP schon immer doof, weil selbst die einfachsten Sachen auf stundenlange Fehlersuche hinauslaufen. Jetzt weiß ich, dass es wohl nicht an meiner mangelnden Erfahrung liegt.
Was empfiehlt sich denn sonst so für Webseiten? PHP ist ja mehr oder weniger Standard, wenn man das nicht benutzen will, was bleibt dann?

[Chromanoid]

Java, Ruby, Python, Perl, JavaScript, im Grunde alles was das Herz begehrt Ich würde Java nehmen, weil ich Java mag. http://tapestry.apache.org/ sieht nett aus. Java Hoster sind auch gar nicht mehr so selten, vielleicht ist ja auch die Google App Engine interessant für dich. GWT ist für Webanwendungen auch cool...

Facebook wird übrigens vorwiegend mit PHP entwickelt und dann in C++ konvertiert, Link den ich auch im Linkdump-Thema gepostet habe:

Exclusive: a behind-the-scenes look at Facebook release engineering, Ryan Paul, ars technica, 05.04.2012

[CodingCat]

Functional Programming in C++ - John Carmack über Nebenwirkungen, referenzielle Transparenz und die Vermeidung von Zustand.

[antisteo]

Ich fand PHP schon immer doof, weil selbst die einfachsten Sachen auf stundenlange Fehlersuche hinauslaufen. Jetzt weiß ich, dass es wohl nicht an meiner mangelnden Erfahrung liegt.
Was empfiehlt sich denn sonst so für Webseiten? PHP ist ja mehr oder weniger Standard, wenn man das nicht benutzen will, was bleibt dann?

Node.js rockt auch (hat aber ähnliche Probleme mit Fehlersuche [kann ich nicht beurteilen, hab nie einen Fehler in node.js gesucht und auch in PHP haben sich alle Probleme in Sekundenschnelle erledigt])

[simbad]

C/C++?

[kimmi]

Node.js == Javascript.

Gruss Kimmi

[Eike Anderson]

Real-time Realistic Rendering and Lighting of Forests, Éric Bruneton, und Fabrice Neyret, Computer Graphics Forum/Eurographics 2012, 2012
Eine Methode zum Echtzeitrendern von bewaldetem Terrain mit (hundert-)tausenden von Baeumen, entwickelt von der Computergrafikgruppe von INRIA (Frankreich). Weitere Publikationen der Gruppe und eine GPL Lib, die die Techniken implementiert gibt es hier: http://proland.inrialpes.fr

[eXile]

Clustered Deferred and Forward Shading

Wie gut, dass ich eh noch nicht mit einem Tile-based-Renderer angefangen habe.

[rüp]

Ein Interview mit Knut Müller.

[antisteo]

Ihr fragt euch sicher, welche die am besten lesbare Programmiersprache ist.
Hier ist sie: https://github.com/substack/number-script

[Jörg]

ASTC Details Teil 1:
http://blogs.arm.com/multimedia/754-arm ... ce-part-1/

[Krishty]

Hm. So lange ich nur 50×100 Pixel große Beispielbilder mit bloß zwei Farbtönen drin sehe, haut mich da garnichts vom Hocker; zumal ich nicht glaube, dass die konzeptuellen Schwächen von DXT durch die höhere Zahl von Zwischenschritten aus der Welt geräumt werden können.

Andererseits frage ich mich seit eXiles Link zu den euklidischen Farbräumen, wie DXT wohl damit aussehen könnte.

[Jörg]

ASTC umschifft einige der DXT-Beschraenkungen, nicht alle. Aber wenn man bei gleicher Bitrate hoehere Qualitaet erhaelt und der HW-seitige Mehraufwand dabei gering ausfaellt, ist das wirklich was wert. Und das man mit einer Implementierung sowohl staerker als auch schwaecher als DXT komprimieren kann, erfreut hoffentlich die Grafiker.
Den perfektionistischen Rest erledigt dann Cric-TC im naechsten Jahr?
Eines ist immer schwierig fuer die HW-Entwicklung: Sobald ein Format zu sehr aus dem Rahmen faellt, wird es haarig. Die Festlegung auf 128 bit/Block z.B. erlaubt eine Wiederverwendung der vorhandenen Prefetch und Cache-Module. Am Ende soll as neue Format beim Verwenden ja auch nicht langsamer erscheinen. Mit breiterer Context-Information kann man definitv besser Komprimieren, aber der Dekompressionsschritt wird einfach langsamer. Wahlfreier Zugriff auf die Texel schraenkt die effizienten Implementierungen ziemlich ein :/

[Krishty]

Dass man Blockkomprimierung braucht, ist klar. Dass die Blöcke fixed-size sein müssen, auch. Und dass bei ARM jeder Transistor zählt, sowieso.

Aber ein 15 Jahre altes Format durch ein paar zusätzliche Blockmodi und neue Farbtiefen aufzubohren; dabei keine fundamentalen Verbesserungen zu bringen (habt ihr auch was für Normal Maps?); und es dann mit einem daumengroßen Bildausschnitt vorzustellen halte ich für absolut übertrieben.

Und so hoch kann der Transistoraufwand auch nicht sein, wo ja Ericssons iPACKMAN ein Bisschen mehr als bloß Interpolation ist und auch trotzdem schon seit 2006 in Hardware verbaut wird.

[Jörg]

Auf ETC sowie (Tangentspace-)Normalmaps wird im 2. Teil kurz eingegangen. Und keine Sorge, der Testkorpus zum Ermitteln der durchschnittlichen Qualitaetsverbesserung enthaelt mehr als ein Bild: http://www.davemc.net/HPG2012/105-114.p ... t.pdf.html, da findest Du die 'nicht-gebloggte' Version verlinkt.