Artikelempfehlungen, interessante Publikationen o.Ä.

[Krishty]

Wow. Bin ich echt so doll auf Polemik und Flaming abgestürzt, dass „Ihr habt doch keine Ahnung“ nicht mehr ausreicht um eure Sarkasmusfühler zum Knattern zu bringen? :)

@Top-OR: Ja tut er, hier.

[eXile]

Da ich ZFX nicht in 4chan verwandeln will, jetzt dann doch noch mal was Konstruktives:
Zusammengeschustertes Video auf http://vimeo.com/13958264
Slides auf http://chrishecker.com/Structure_vs_Style

Das Beispiel der AI ist jetzt vielleicht nicht wirklich relevant, aber die Dekomposition in „Structure vs. Style“ (muss man aber nicht so nennen) war mir zwar lange, lange Zeit unterschwellig klar, aber endlich hat's mal jemand gesagt. Unbedingte Anschauempfehlung. (Ich habe 45 Minuten gebraucht, um das wiederzufinden; ich hoffe, euch gefällt's.)

[Top-OR]

Ja tut er, hier.

Ahhhhhjaaaa ...

*AlohaPfeifendImDunkelnVerschwindend*

[rüp]

Ich habe Herrn Acton dieses Jahr live auf'm Game Forum Germany in Hamburg gesehen, und muss sagen, dass ich ihn recht unsympathisch fand, oder zumindest seine Präsentation / sein Thema ziemlich sinnlos. (Seine Seite altdevblogaday.org ist aber dennoch sehr gut.)

Ansonsten find' ich die Post-Its lustig, ist mal was anderes.

[Seraph]

Ich schmeisse einfach mal ohne weitere Worte den folgenden Link in die Runde:

You don't want to work in the games industry

[kimmi]

Ein sehr interessanter Artikel, dem ich nach eigenen Erzählungen und Erfahrungen ebenfalls nur zustimmen kann.

Gruß Kimmi

[Chromanoid]

Sehr geil der Link aus dem Artikel (You don't want to work in the games industry):
How to Write Unmaintainable Code (Humorous Article)
Er wird in diesem Zusammenhang erwähnt:
"Big studios are only secure for the “Unfireables”; the guys who have been there for a decade and wrote the subsystem or tool so terrible, that only they can maintain it, thus indefinitely extending their employment." :D

Den Typen kenne ich auch :P

Gruß Kimmi

[Top-OR]

You don't want to work in the games industry

Nicht, dass ich es "gewust" habe, aber warum wundert mich das nicht?

Sehr interessant, danke.

[Chromanoid]

@kimmi :) einfach meinen post für dich beanspruchen tststs :D :D

[CodingCat]

Interactive Indirect Illumination and Ambient Occlusion Using Voxel Cone Tracing:
http://blog.icare3d.org/2011/06/interac ... n-and.html
http://artis.imag.fr/Publications/2011/CNSGE11/

[eXile]

Nichts da „A Preview“, eher „An Insight“:
http://artis.imag.fr/Publications/2011/CNSGE11a/

Aber leider gibts noch kein ganzes Paper. Muss mir mal anschauen, ob man das mit Light Propagation Volumes zusammenschustern kann. Die Haupteinschränkung sind wohl lokal gaussche BRDFs, auch wenn man so wohl eine komplexe BRDF durch mehrere Gauss zusammenbasteln kann. Auch überlege ich gerade, ob man nicht vielleicht statt mehreren Gauss lokal beschränkte SH nehmen könnte; aber das ist jetzt nur eine Idee.

[Schrompf]

Wow, enorm beeindruckend. Der Film sieht aus, als wäre das ein Alles-Tot für die Global Illumination. Hoffentlich kommt das Paper auch für Normalsterbliche - die Siggraph hat sich da ja immer ein bisschen.

[kimmi]

@kimmi :) einfach meinen post für dich beanspruchen tststs :D :D

Nicht beanspruchen, sondern einigen Kollegen auf diesem Wege zugänglich machen, wie das sonst nicht kennen würden.

Gruß Kimmi

[Alexander Kornrumpf]

Du hast seinen Post editiert, war das Absicht?

[Krishty]

Statt auf „Zitieren“ auf „Ändern“ geklickt? Ist super – da werden die extra möglichst weit auseinander platziert, damit beim Danebenklicken nicht viel passieren kann. Dann sind sie aber wiederum so weit auseinander, dass sich die Hand nicht merken kann, ob sie jetzt auf das Pinke ganz links außen oder auf das Pinke ganz rechts außen klicken sollte …

… ich frage mich, warum „Ändern“ nicht ausgegraut ist. Ich meine: Verwarnen, Information und der restliche Moderatorenkram sind das schließlich auch.

[Alexander Kornrumpf]

Weil auch nicht-Moderatoren eigene Beitäge ändern können. Ändern müsste von der Logik her nur bei fremden Beiträgen grau sein, oder?

[Krishty]

Genau. Ist es aber nicht.

[Chromanoid]

Boah ich glaube ich muss diesen Thread mal aufräumen oder wir brauchen ne ZFX Link Liste. Meine ursprüngl. Intention einer schnell überfliegbaren Liste mit interessanten Links, die in einem gut lesbaren Format vorliegen, ist ja echt ziemlich schnell unter gegangen ^^

[Krishty]

Link-Liste. Durch die Benutzerbilder, Signaturen *hust* und ähnlichen Overhead ist das Link-zu-Platz-Verhältnis imho eh nicht in einem effizienten Bereich.

[Chromanoid]

Hat nicht irgendwer Lust sowas mal mit GWT zu bauen? :) Die Integration in phpBB könnte via Webservice funktionieren. Das wäre doch mal ein schönes Übungsprojekt für GWT ^^

[eXile]

Platform Abstraction with C++ Templates
Ist jetzt absolut nichts weltbewegendes, aber einmal durchlesen schadet nun auch nicht.

[Jaw]

Für eine Linkliste im Form wäre es wohl dann eher praktisch, alle guten Links in den ersten Beitrag aufzunehmen und den immer zu ändern, und die Diskussion dahinter einfach laufen zu lassen. Zur Sicherheit kann man ja noch zwei weitere Posts direkt am Anfang als Platzhalter anlegen, falls der erste zu groß wird. Aber für solche Sammeleien und Stickies sollten wirklich die Resultate dann am Anfang stehen, damit man eben nicht x Seiten durchgrasen muss.

-JAW

[Krishty]

Platform Abstraction with C++ Templates
Ist jetzt absolut nichts weltbewegendes, aber einmal durchlesen schadet nun auch nicht.

Verstehe ich nicht. Wenn man sowieso uniforme Schnittstellen anlegen und nur die „richtigen“ Dateien kompilieren muss, warum nicht per #include die richtigen einbinden und des ganzen Template-Kram sparen? Zumal die „nice error messages“ des Linkers bei Templates doch nicht ganz so nice sind wie die des Präprozessors oder des Compilers. Bei Endianness und Byte-Größe würde ich das ja noch akzeptieren, aber bei der Wahl zwischen OutputDebugStringA() und __android_log_print() definitiv nicht.

Dass die korrekten Umgebungsbibliotheken paratliegen ist das Problem des Programmierers und seiner Programmierumgebung, nicht des Compilers und Linkers, nur, damit einer zeigen kann, dass er weiß, was Templates sind.

Und Jaw hat recht.

[joggel]

Naja, also für mich macht das schon Sinn mit diesen Templates.
Wenn ich nun auf einer anderen Platform kompiliere, muss ich nichts an der Klasse "Debug" ändern...
Kann sein, dass ich da jetzt falsch liege.. oder den Link oder Krishty's Post falsch verstanden habe.

[Krishty]

Ich meine (42 Zeilen):

Code: Alles auswählen

#include <cstdio> 

namespace Private
{
	// generic declaration (the base interface class)
 	template <int PlatformID>
	class Debug
	{
	public:
		static void print(const char *str);
	};

	// specialization for Windows platform (the derived class for Windows)
	template<>
	class Debug<PLATFORM_WINDOWS>
	{
	public:
		static void print(const char *str);
	};

	// specialization for Android platform (the derived class for Android)
	template<>
	class Debug<PLATFORM_ANDROID>
	{
	public:
		static void print(const char *str);
	};

	// generic platform (base interface class) implementation
	template <int PlatformID>
	void Debug<PlatformID>::print(const char *str)
	{
		::puts(str);
	}
}

// … .cpp …

#if (PLATFORM_ID == PLATFORM_WINDOWS)

	#include <windows.h>

	// implementation for Windows
	void Debug::print(const char *str)
	{
		::OutputDebugStringA(str);
		::OutputDebugStringA("\n");
	}

#elif (PLATFORM_ID == PLATFORM_ANDROID)

	#include <android/log.h>

	// implementation for Android
	void Debug::print(const char *str)
	{
		::__android_log_print(ANDROID_LOG_INFO, "MyApp", str);
	}

#endif

Warum nicht einfach den ganzen Template-Kram fallen lassen (25 Zeilen):

Code: Alles auswählen

namespace Debug {

	void print(char const * str);

}

// … .cpp …

namespace Debug {
#if defined(PLATFORM_WINDOWS)

	#include <windows.h>

	// implementation for Windows
	void print(const char *str)
	{
		::OutputDebugStringA(str);
		::OutputDebugStringA("\n");
	}

#elif defined(PLATFORM_ANDROID)

	#include <android/log.h>

	// implementation for Android
	void print(const char *str)
	{
		::__android_log_print(ANDROID_LOG_INFO, "MyApp", str);
	}

#else

	#include <cstdio>

	// default
	void print(const char *str)
	{
		::puts(str);
	}

#endif
} // namespace Debug

Dann habe ich dasselbe plattformunabhängige Debug::print(), aber mit halb so viel Quelltext zum Deklarieren der ganzen Templates, die

• … eh nie mit mehr als einem Parameter instanziert werden und damit den Sinn von generischer Programmierung so ziemlich ad abhirntot führen
• … ich vom Präprozessor über den ersten Compiler-Pass schleppe, damit sie im 2. Pass und im Linker aufgelöst werden statt … sofort
• … mich am Ende der Kompilierung mit Template- und Link-Time-Fehlermeldungen beglücken statt einfach mit „nicht definiert“ direkt am Anfang
• … ich im Debugger und in Fehlermeldungen nicht wiederfinde, weil sie __QZYWprint@@Debug@4CW1337 heißen und nicht einfach _print@Debug (und nebenbei auch schwerer für den Compiler zu handhaben sind).

Sieht für mich nach vollendeter Sinnlosigkeit aus – aber kann ja sein, dass ich in meinem Schlafentzug den ganz genialen Geistesblitz übersehen habe (zumal ich bei eXiles Links immer ein wenig brauche, um das volle Potenzial zu begreifen).

[joggel]

Mh... irgendwie macht das Sinn was Du schreibst!
Joar, stimmt... erschliest sich mir jetzt auch nicht mehr der Vorteil der Templates in dem Fall ... :oops:

[eXile]

Ich gebe Krishty uneingeschränkt recht. Je mehr ich darüber nachdenke, desto mehr ist der Link ein Griff ins Klo.

Die hier zu implementierende Verzweigung sollte schon vor der Kompilieren (d.h. mit dem Präprozessor) und nicht erst bei der Kompilierung (d.h. mit Templates) ausgelöst werden. Auch hier gilt (wie eigentlich immer) „je früher desto besser“. Etwas, was zur Kompilierzeit feststeht, implementiert ja auch niemand mittels Polymorphie zur Laufzeit; ebenso sollte man etwas, was vor der Kompilierzeit feststeht (wie nun einmal Build-Settings) auch nicht mittels Templates, sondern mit dem Präprozessor lösen. Eine Ausnahme davon mag nun einmal dadurch gegeben sein, dass der Präprozessor nicht alles kann, Templates (wenn auch mit Verkrampfungen) schon; diese Ausnahme ist hier jedoch nicht gegeben. Da gibt es nicht mehr Potenzial, Krishty ;)

Allerdings hat mir der dortige Kommentar von Garett Bass sehr gut gefallen - mir war natürlich das Konkatenieren mit dem Präprozessor wohlbekannt, aber das auch im #include zu verwenden, ist mir bisher nicht eingefallen. Bei wenigen Dateien natürlich Overkill.

Ich bin übrigens auch dafür, die Links im ersten Post zu sammeln; diese Links werden aufgenommen, sobald die Diskussion oder allgemeines Nicht-Diskutieren zur Annahme geführt haben (d.h. fast immer). Beispielsweise hat sich der von mir gepostete Link wohl bereits disqualifiziert.

[Chromanoid]

So hab die Links mal gesammelt. Irgendwie brauchen wir, so glaube ich, dennoch auf lange Sicht eine Art durchsuchbares Directory System... Links werden ab jetzt nur noch aufgenommen, wenn sie das Format vom ersten post einhalten. Wenn ich was vergessen habe, einfach nochmal posten oder mir ne PM schreiben, aber bitte im richtigen Format... Alle die sonst auch Moderator-Rechte haben, können gerne in meinem Post rumeditieren.

[Seraph]

Die aktuelle Linkliste ist imho viel zu sehr mit unnoetigem Kram aufgeblaeht. Die Beschreibungen kann man doch fast immer auch schon am Link-Text selbst ablesen. Evtl. koennte man noch das Datum und den Autor hinzufuegen, wobei ich das nun nicht unbedingt als so wichtig empfinde. Wenn ich selbst nach einem bestimmten Thema suche dann gehe ich nach dem Text und der Autor und das Datum kommen erst spaeter. Suche ich nach etwas von einem bestimmten Autor hilft mir Google oder jede beliebige andere Suchmaschine da sicher auch weiter.

Warum nicht einfach

Kategorie 1

• interessanter Artikel hier
• toller Artikel da
• bombastischer Artikel
• bla bla bla

Kategorie 2

• interessanter Artikel hier
• toller Artikel da
• bombastischer Artikel
• bla bla bla

Eigentlich ist es eine doofe Idee in diesem Thema eine Diskussion anzufangen, aber Du kannst meinen Post ja ggf. wieder loeschen. :P

[Chromanoid]

Alle die sonst auch Moderator-Rechte haben, können gerne in meinem Post rumeditieren.

;)
Mir ist es recht egal. Ich habe nur keine Lust das Zeug immer zu sortieren etc.