Seite 30 von 69

Re: Anti-Jammer-Thread

Verfasst: 23.01.2013, 23:02
von Krishty
Ich liebe meine Release-Rituale. Den ganzen Tag über werden nochmal alle Use Cases durchgespielt … nein; laaaangweilig. Neinein.

Zuerst wird nochmal im ganzen Quelltext nach Stichwörtern wie test oder temp gesucht um sicher zu gehen, dass nichts im Programm ist, was nicht reinsollte. Dann wird der Dependency Walker angeschmissen um nachzusehen, ob nicht irgendwo ein Import zu viel reingerutscht ist. Überall die Programmversion suchen und anpassen; genau so Daten und Urheberrechtshinweise (wir haben ja ein neues Jahr!). Den Abschnitt der Exe mit den konstanten Daten öffnen und alle Strings durchlesen. Via vmmap noch einen Blick auf den gesamten Adressraum werfen; könnte ja sein, dass die Stack Reserve Size zu hoch eingestellt ist! Direct3D-Debug-Laufzeitbibliothek und Application Verifier auspacken; den Staub runterpusten; einschalten. Nochmal das Zittern beim Start. Ressourcenverbrauch beobachten; Festplatte lauschen. Logdateien wälzen. Dann die Archive packen; optimieren; testen. Ich könnte Tage damit verbringen. Das Kitzeln beim Hochladen …

… und das ungeduldige Entgegenfiebern der ersten gemeldeten Fehler.

Re: Anti-Jammer-Thread

Verfasst: 23.01.2013, 23:43
von CodingCat
Da ich noch immer mit dem VC 2010-Compiler vorliebnehmen muss (kein Range-based for), bin ich soeben der Range-Iteration verfallen:

Code: Alles auswählen

for (Material::Effects linkedEffects = material->GetLinkedEffects(); linkedEffects; ++linkedEffects)
   bEffectsChanged |= (linkedEffects->GetSuccessor() != nullptr);
So viel weniger Ärger mit Iteratoren, herrlich. Funktioniert leider nur vorwärts gut, aber das tut Range-based for ja auch. (Um Dummheiten vorzubeugen, habe ich operator -- gar nicht erst implementiert. Rückwärtsiteration ist nur folgendermaßen korrekt: for (it = end; it-- != begin; ) ...; möglich wäre, invertierte Ranges mit einem operator -- (Postfix) auszustatten, die Klarheit leidet aber.)

Re: Anti-Jammer-Thread

Verfasst: 24.01.2013, 16:32
von Krishty
Krishty hat geschrieben:Hat man drei Vertices a, b und c im Camera Space, die ein Dreieck aufspannen; und möchte bestimmen, ob es Backface Culling zum Opfer fällt, ist der übliche Weg, dass man testet, ob die Dreiecksnormale in dieselbe Richtung zeigt wie die Richtung vom Betrachter (Nullpunkt) zu irgendeinem Punkt auf dem Dreieck:

   bool cull = 0 >= dot(cross(a - b, c - b), -b));

Geübte Augen erkennen darin das Spatprodukt:

   0 >= (BA × BC) • -b

(sry, eXile – bin LaTeX nicht so mächtig ;) ); das entspricht wiederum der Determinante der 3×3-Matrix, die von den drei Vektoren aufgespannt wird. Neugierig, wie ich bin, wollte ich testen, ob das nicht schneller (oder besser für OoOE) ist. Verpeilt, wie ich bin, habe ich aber versehentlich geschrieben:

   0 < (a × c) • -b

bzw.

   return 0.0f < ((a.x * b.y * c.z) - (a.z * b.y * c.x)) + ((a.y * b.z * c.x) - (a.y * b.x * c.z)) + ((a.z * b.x * c.y) - (a.x * b.z * c.y));

Das Verblüffende: Es scheint ziemlich gut zu funktionieren. Kann mir jemand erklären, ob das eine stabile Alternative ist oder ob ich einfach nur sau viel Glück mit meinen Daten habe?

(Muss 151.000 Dreiecke auf der CPU cullen und optimiere deshalb mal wieder jede Anweisung einzeln …)
CodingCat hat geschrieben:Ja, das ist für perspektivische Projektion korrekt, weil du im Kameraraum das Projektionszentrum gerade im Ursprung sitzen hast. Das Kreuzprodukt aus a und c entspricht somit der Kantennormale der (projizierten) Kante AC im projektiven Raum; oder anschaulich der Normale der Ebene, die von Projektionszentrum und den beiden Vertices aufgespannt wird, und somit sowohl die Kante AC als auch deren perspektivische Projektion enthält. Jetzt musst du nur noch testen, auf welcher Seite dieser Ebene der Vertex B liegt, was du mit dem Skalarprodukt auch tust. Denn die Drehrichtung des Dreiecks ändert sich logischerweise genau dann, wenn in der Projektion des Dreiecks der projizierte Punkt B die (verlängerte) projizierte Kante AC überquert.

Die langweilige Begründung:
((a - b) × (c - b)) • -b
= (a × (c - b) - b × (c - b)) • -b
= (a × c - a × b - b × c + b × b) • -b // b × b = 0
= (a × c - a × b - b × c) • -b // a × b und b × c orthogonal zu b
= (a × c) • -b
(Von hier)
Geht leider nicht. Ich habe eben gemerkt: Werden die Dreiecke sehr schlank, flackert es wie Sau. Ich werde mir mal ansehen, ob da numerische Ungenauigkeiten auftreten …

Re: Anti-Jammer-Thread

Verfasst: 25.01.2013, 00:07
von CodingCat
Überraschung des Tages: UAV Counters arbeiten unter Compute genau wie man es gerne hätte: Rufen alle Threads gleichzeitig IncrementCounter(), ist das Ergebnis Thread-konsekutiv, d.h. benachbarte Threads einer Gruppe (eines Warps) erhalten in aufsteigender Reihenfolge benachbarte Zahlen.

(Warum Überraschung? Tatsächlich erscheint dies die einzig sinnvolle und effiziente Implementierung. Bisher hatte ich mir jedoch nur die Reihenfolge in Pixel Shaders angesehen, wo IncrementCounter() rasterisierungsbedingt Zahlen in wildem Durcheinander liefert. Ein wichtiger Grund für Compute Processing gegenüber Pixel Shader Processing?! Stellt sich die Frage, welches Durcheinander man beim Pixel Processing eigentlich sieht, und ob sich Pixel mit benachbarten Counter-Indizes darin tatsächlich so etwas wie eine Thread/Gruppe einen Warp teilen.)

Re: Anti-Jammer-Thread

Verfasst: 27.01.2013, 21:04
von B.G.Michi
constexpr ist ekelhaft... und wunderschön...

Trotzdem:
multidimensionale, constexpr-taugliche Arrayklasse (Dimension und Größe statisch und dynamisch)... CHECK
constexpr-taugliche Tensorklasse (Rang und Dimension statisch und dynamisch)... IN PROGRESS
komponentenweise Operatoren... CHECK
Skalarprodukt... CHECK
Kreuzproduckt... CHEEEECCKKKKKKKK

Code: Alles auswählen

// vector cross product
TEMPLATE_ARGUMENT_LIST
class TensorT<TYPE, STORAGE>::InternCrossProduct
{
public:
	template<int COLUMN, class ROWS> class InternDeterminant;

	template<int COLUMN, int... ROWS> class InternDeterminant<COLUMN, sequence<ROWS...> > { public:
	template<class... ARGS> MG_FORCEINLINE static constexpr decltype(product_range<COLUMN - 1, sizeof...(ARGS)>(typename remove_reference<ARGS>::type::MyType()...))
		Get(ARGS&&... _Args)
	{
		return sum( pow_t<-1, find_in_sequence<ROWS, sequence<ROWS...> >::value>::value * (select<COLUMN - 1>(forward<ARGS>(_Args)...)[ROWS] *
			InternDeterminant<COLUMN + 1, typename remove_from_sequence<find_in_sequence<ROWS, sequence<ROWS...> >::value, sequence<ROWS...> >::type>::Get(forward<ARGS>(_Args)...))... );
	}};

	template<int COLUMN, int ROW> class InternDeterminant<COLUMN, sequence<ROW> > { public:
	template<class... ARGS> MG_FORCEINLINE static constexpr typename select_type<COLUMN - 1, typename remove_reference<ARGS>::type::MyType...>::type
		Get(ARGS&&... _Args)
	{
		return select<COLUMN - 1>(forward<ARGS>(_Args)...)[ROW];
	}};

	template<int ROW, class... ARGS>
	MG_FORCEINLINE static constexpr decltype(product(typename remove_reference<ARGS>::type::MyType()...))
		InternGet1(ARGS&&... _Args)
	{
		return pow_t<-1, ROW>::value * InternDeterminant<1, typename remove_from_sequence<ROW, typename generate_sequence<sizeof...(ARGS) + 1>::type>::type>::Get(forward<ARGS>(_Args)...);
	}

	template<class... ARGS, int... SEQUENCE1>
	MG_FORCEINLINE static constexpr Tensor<decltype(product(typename remove_reference<ARGS>::type::MyType()...)), TensorStorageFixedDimension<sizeof...(ARGS) + 1>::template type>
		InternGet(sequence<SEQUENCE1...>, ARGS&&... _Args)
	{
		return { InternGet1<SEQUENCE1>(forward<ARGS>(_Args)...)... };
	}

	template<class... ARGS>
	MG_FORCEINLINE static constexpr typename enable_if<InternCanBeVector<Tensor<TYPE, STORAGE> >() && and_t<InternCanBeVector<ARGS>()...>::value,
		Tensor<decltype(product(TYPE(), typename remove_reference<ARGS>::type::MyType()...)), TensorStorageFixedDimension<sizeof...(ARGS) + 2>::template type> >::type
		Get(const TensorT<TYPE, STORAGE>& _1, ARGS&&... _Args)
	{
		return ASSERT_EXCEPTION(_1.GetRank() == 1 && _1.GetDimension()[0] == sizeof...(ARGS) + 2 && logical_and((_1.GetDimension() == _Args.GetDimension())...)),
			InternGet(typename generate_sequence<sizeof...(ARGS) + 2>::type(), _1, forward<ARGS>(_Args)...);
	}
};
Ein Gedicht. Beliebige Dimension. Kein "for". Keine überflüssige Operation.
(na gut: O(n!). Aber wer verwendet schon ein Kreuzprodukt in mehr als 3 Dimensionen) :)

nächster Halt: Matrixprodukt

Re: Anti-Jammer-Thread

Verfasst: 28.01.2013, 12:48
von Schrompf
Brrr... wer würde sowas freiwillig nutzen.

Code: Alles auswählen

for( auto& e : a.p )
So fühlt sich Zen an.

Re: Anti-Jammer-Thread

Verfasst: 28.01.2013, 14:42
von Jonathan
Hm, ist doch schön. Zumindest schön kompakt :D Hätten die Variablen noch aussagekräftige Namen wäre doch alles super? Und wieso Zen?

Re: Anti-Jammer-Thread

Verfasst: 28.01.2013, 14:53
von Schrompf
Zen eben gerade, weil es völlig aussagelos minimal kryptisch ist. Buddhistische Mönche werden doch auch bewundert, wenn sie nach dem Sinn des Lebens befragt nur ein Aufrufezeichen als Antwort schreiben :D

Re: Anti-Jammer-Thread

Verfasst: 28.01.2013, 18:46
von Helmut
CodingCat hat geschrieben:Da ich noch immer mit dem VC 2010-Compiler vorliebnehmen muss (kein Range-based for), bin ich soeben der Range-Iteration verfallen:
In VC2010 kannst du übrigens "for each" benutzen. Das ist im Grunde das "C++11 for", nur mit einer etwas anderen Syntax. Und sobald du auf den neuen Compiler umsteigst kannst du dir ja ne Stunde Zeit nehmen und alle for eachs austauschen.

Re: Anti-Jammer-Thread

Verfasst: 01.02.2013, 00:20
von antisteo
Ich finde die Aufmachung der Story in World of Goo genial.

Hochachtungsvoll,
der Schildermaler

Re: Anti-Jammer-Thread

Verfasst: 01.02.2013, 00:48
von klickverbot
B.G.Michi hat geschrieben:Aber wer verwendet schon ein Kreuzprodukt in mehr als 3 Dimensionen
Die Frage ist doch: Was soll das Kreuzprodukt in mehr als 3 Dimensionen überhaupt sein? ;)

Grassmann-Algebren sind lustig.

Re: Anti-Jammer-Thread

Verfasst: 01.02.2013, 11:32
von Schrompf
antisteo hat geschrieben:Ich finde die Aufmachung der Story in World of Goo genial.

Hochachtungsvoll,
der Schildermaler
Unbedingt! Rundherum ein sehr cooles Spiel.

Re: Anti-Jammer-Thread

Verfasst: 01.02.2013, 16:21
von glassbear
Crysis 3 I like :ugeek:

Re: Anti-Jammer-Thread

Verfasst: 03.02.2013, 00:27
von Krishty
__if_not_exists(Context::onCursorMoved) {
    static_assert(false, "the window context must implement 'onCursorMoved()'");
}


Generische Programmierung und statisches Dispatching sind gerade 1000 % einfacher geworden … wenn das jetzt bloß noch außerhalb von Funktionen ginge …

Re: Anti-Jammer-Thread

Verfasst: 03.02.2013, 00:30
von antisteo
gwscripten macht Spaß

http://goldenwipf.de/hg/index.cgi/rev/aad51345761c

Einfach Spiellogik hinschreiben und die Objekte verhalten sich auch noch so. Hier am Beispiel des Hochofens.

Re: Anti-Jammer-Thread

Verfasst: 03.02.2013, 02:13
von Krishty
Ich habe gerade richtig Spaß daran, die WinAPI wegzukapseln. Möglicherweise ist das der Schlafentzug – aber ich habe das Gefühl, dass es sich trotz der Wucherungen, Fehlbenennungen, völlig verkackten Doku, und gigantischer Komplexität um ein ziemlich klug durchdachtes und exakt funktionierendes System handelt.

Das mag lächerlich aus dem Mund von jemandem klingen, der gerade die vierte Fensterklasse in zwei Jahren schreibt, aber: So langsam nehme ich es nicht mehr als gottgegeben hin, dass Maskierungsversuche wie die MFC so episch danebengehen; und meine Meinung darüber verschiebt sich von das ist so fett und hässlich weil es nicht anders geht zu das ist so fett und hässlich weil da Idioten am Werk waren.

Mal sehen, wie lange das so bleibt.

Re: Anti-Jammer-Thread

Verfasst: 04.02.2013, 18:17
von CodingCat
Mit Variadic Templates lassen sich endlich ohne wahlweise Reservierungsverrenkungen oder mehrfache Reallokation Strings konkatenieren. (Zuerst die Länge der Konkatenation aller Argumente berechnen, dann direkt in den Zielspeicher kopieren.)

Re: Anti-Jammer-Thread

Verfasst: 07.02.2013, 17:11
von Schrompf
Mein Google-Fu wird besser. Habe soeben einen Visual Studio Debug Visualizer für meine kleine statische Array-Klasse geschrieben. Die Klasse ist im Kern ein statisches Array, bietet aber nach draußen die Schnittstelle eines std::vector an. Als Code:

Code: Alles auswählen

template <typename Typ, size_t Groesse>
class TArray
{
protected:
  char mFeld[Groesse*sizeof( Typ)];
  Typ* mEnde;

public:
  ...
Ein char-Array, damit nicht sofort im Konstruktor der Default-Konstruktor aller Elemente läuft. Stattdessen wird in-place-konstruiert. Nur sieht man im Debugger dann natürlich ein Byte-Array, was immer etwas mühseliges Tippen bedeutet, um den waren Inhalt der enthaltenen Elemente zu sehen. Und da kommt der Visualizer ins Spiel.

Code: Alles auswählen

; C:\Program Files (x86)\Visual Studio 11\Common7\Packages\Debugger\autoexp.dat

TArray<*,*>{
	preview (
		#(
			"[",
			($e.mEnde - (($T1*) &($e.mFeld[0]))),
			"](",
			#array(
				expr: ((($T1*) &($e.mFeld[0]))[$i]),
				size: ($e.mEnde - (($T1*) &($e.mFeld[0])))
			),
			")"
		)
	)

	children (
		#(
      #([raw members] : [$e,!]),
			#([size] : ($e.mEnde - (($T1*) &($e.mFeld[0])))),
			#array(
				expr: ((($T1*) &($e.mFeld[0]))[$i]),
				size: ($e.mEnde - (($T1*) &($e.mFeld[0])))
			)
		)
	)
}
Die Dokumentation von Microsoft ist übel veraltet und unvollständig, aber zum Glück gab es bereits vor langer Zeit ein paar Helden, die das rückinterpretiert haben. Jetzt sieht es im Debugger vernünftig aus:
CustomVisualizer.jpg
Und ich bin - für VisualStudio-Probleme unüblich - unter einer Stunde Zeitaufwand rausgekommen! Yeah.

Re: Anti-Jammer-Thread

Verfasst: 07.02.2013, 22:06
von Krishty
Wow; nett. Ich hatte das ja alles schon mit VS 2010 gemacht, und dann kam mit VS 2012 angeblich ein neues Dateiformat und ich hatte keinen Bock, das jemals wieder zu machen … ein Link zu den paar Helden wäre nicht schlecht.

Re: Anti-Jammer-Thread

Verfasst: 08.02.2013, 01:01
von Schrompf
Nicht so hilfreich: http://www.idigitalhouse.com/Blog/?p=83
Besser: http://www.virtualdub.org/blog/pivot/entry.php?id=120

Letzteres ist aber sehr alt. Einige der Variablen heißen jetzt anders. Abgesehen davon hat mit die Seite aber sehr geholfen.

Re: Anti-Jammer-Thread

Verfasst: 09.02.2013, 12:39
von Schrompf
Nochmal ich:
Microsoft Connect hat geschrieben:This notification was generated for feedback item: [Codename Milan] initializer_list constructor not found (http://connect.microsoft.com/VisualStud ... -not-found) which you submitted at the Microsoft Connect (http://connect.microsoft.com) site.

Hi:
Thanks for reporting the issue.
A fix for this issue has been checked into the compiler sources. The fix should show up in the next release of Visual C++.

Xiang Fan
Visual C++ Team
Jubel!

Re: Anti-Jammer-Thread

Verfasst: 09.02.2013, 16:04
von dot
didn't see that coming :D

Re: Anti-Jammer-Thread

Verfasst: 09.02.2013, 16:51
von CodingCat
Ich hoffe nur, sie reden vom Update, und haben nicht mal eben das gesamte CTP nach VS 2014 verschoben.

Re: Anti-Jammer-Thread

Verfasst: 09.02.2013, 22:05
von antisteo
Ich habe jetzt ein WeTab und es ist, genau wie ich es gehofft hatte, ein vollständiger Netbook-Ersat, der zugleich mobiler (keine Tastatur) und besser zu bedienen (Touch) ist.
Nachdem ich Gnome3 eingerichtet hatte (ein paar Probleme, eine Bildschirmtastatur zu finden, die wirklich gut zu mir passt, ein bisschen Skripte schreiben, damit der Sensor-Knopf funktioniert), ist ein vollwertiger PC im Tablet-Format eingerichtet.

Re: Anti-Jammer-Thread

Verfasst: 10.02.2013, 12:06
von Krishty
Schrompf hat geschrieben:Jubel!
Auch einer meiner alten Bugs wurde just als behoben gekennzeichnet:
https://connect.microsoft.com/VisualStu ... -as-double

ABER: Die Lösung lautet, ich solle Visual Studio 2012 RTM benutzen. Das bedeutet für mich: Jemand hat durch 1 1/2 Jahre alte Bug-Meldungen geforstet; hat geprüft, ob sie sich mit VS 2012 noch reproduzieren lassen; und falls nicht, sie als erledigt markiert.

Ich traue dem Braten nicht weil mein Fehler sehr sehr flüchtig war und der Kommentar klingt, als hätte da niemand richtig ermittelt, was das denn wohl gewesen war.

Andererseits scheint die Register Allocation für VS 2012 neugeschrieben worden zu sein; und möglicherweise ist der ganze Code, der für den Bug hätte verantwortlich sein können, einfach rausgeflogen und sie haken nun vielleicht alle Karteileichen ab, die noch dranhängen könnten.

Re: Anti-Jammer-Thread

Verfasst: 14.02.2013, 12:36
von Jonathan
Yay, neue DrMemory Version:
"Added support for the Microsoft Visual Studio dynamic debug C library"

Damit dürfte das umständliche neu kompilieren sämtlicher statischer Bibliotheken der Vergangenheit angehören :)

Re: Anti-Jammer-Thread

Verfasst: 20.02.2013, 01:19
von eXile
Für alle, die gerade den Firefox aktualisiert haben und mit pdf.js Mühe und Not haben: Mit Pfeil-nach-links und Pfeil-nach-rechts kann man zwischen ganzen Seiten blättern. Bei anderweitiger Benutzung geht einem sonst das Mausrad in Flammen auf.

Re: Anti-Jammer-Thread

Verfasst: 21.02.2013, 03:46
von eXile
Sony schmeißt endlich die SPUs weg und steigt auf normale GPUs um? Ich bin okay damit.

Re: Anti-Jammer-Thread

Verfasst: 21.02.2013, 17:27
von Krishty
lincs or it didn't happen

Re: Anti-Jammer-Thread

Verfasst: 22.02.2013, 01:23
von eXile
Krishty hat geschrieben:lincs or it didn't happen
Hier; die haben einfach einen PC genommen und Sony draufgeschrieben.

[youtube]0rJDn0jRnUQ[/youtube]