Seite 83 von 252

Re: Jammer-Thread

Verfasst: 26.08.2012, 11:05
von dot
:lol:

Re: Jammer-Thread

Verfasst: 26.08.2012, 15:14
von kaiserludi
dot hat geschrieben: :lol:
Falscher Thread! In diesem Thread musst du " :cry: " schreiben :x

Re: Jammer-Thread

Verfasst: 26.08.2012, 15:51
von eXile
Krishty hat geschrieben:eXile (echter Name Nils) hat mir dann geholfen. Wir haben schnell ein Tarnnetz aus zwei übereinanderliegenden Fliegengittern gebaut – das entstehende Moiré hat die Bilderkennung derart verwirrt, dass mein Terminator aus dem Fenster gestürzt ist.
Lustigerweise kombiniert das sowohl diesen Post von mir wie auch unsere früheren Diskussionen über Frequenzräume und FFTs bzw. Glare (das Moiré-Muster entsteht durch Unterabtastung; die notwendige Abtastfrequenz wird durch das Nyquist–Shannon-Theorem gegeben; alles im engen Zusammenhang mit Signalverarbeitung und FFTs).

(Und der echte Name ist noch nicht korrekt von deinem Hirn deduziert worden, bald werde ich aber auch auf Klarnamen hier umschwenken. Bisher lesen aber noch ein paar Leute der Arbeitsgruppe mit, da bleibe ich noch lieber anonym, aber wohl nicht mehr lange.)

Um das notwendige Quäntchen Jammern noch unterzubringen:

Code: Alles auswählen

error X3004: undeclared identifier 'EvaluateAttributeAtCentroid'
Dahingegen klappt EvaluateAttributeAtSample ohne Probleme. Haben die das einfach vergessen im HLSL-Compiler zu implementieren?!

Re: Jammer-Thread

Verfasst: 26.08.2012, 16:06
von Krishty
Von meiner Seite gibt es keinen Klarnamenszwang. Ich bin ja auch anonym unterwegs; nicht einmal der Name im Sternen-Artikel ist 100 % authentisch.

————

Gejammer: JDownloader auf einem Eee PC.

Re: Jammer-Thread

Verfasst: 26.08.2012, 17:08
von CodingCat
Am Horizont tanzen noch immer bunte Laserstrahlen. :?
eXile hat geschrieben:Um das notwendige Quäntchen Jammern noch unterzubringen:

Code: Alles auswählen

error X3004: undeclared identifier 'EvaluateAttributeAtCentroid'
Dahingegen klappt EvaluateAttributeAtSample ohne Probleme. Haben die das einfach vergessen im HLSL-Compiler zu implementieren?!
Wie sieht es mit EvaluateAttributeSnapped(var, 0) aus?

Re: Jammer-Thread

Verfasst: 26.08.2012, 17:37
von eXile
Ich habe mir mal alle Strings aus der D3DCompiler_43.dll dumpen lassen:
Stringdump der D3DCompiler_43.dll hat geschrieben:
GetRenderTargetSampleCount
offset
EvaluateAttributeSnapped
EvaluateAttributeCentroid
index
EvaluateAttributeAtSample
DeviceMemoryBarrierWithGroupSync

Na, seht ihr es? Da steht EvaluateAttributeCentroid, nicht EvaluateAttributeAtCentroid. Damit funktioniert es, so wie auch alle anderen EvaluateAttribute*-Funktionen.

Bild

Die haben einfach die Intrinsic-Funktion bei der Compiler-Implementierung falsch benannt. So etwas kann man sich nicht ausdenken. :evil:

Re: Jammer-Thread

Verfasst: 28.08.2012, 22:26
von Andre
DirextXMath ist doch behindert. Muss ich wirklich immer meine daten wenn ich irgendwas mit Vektoren rechnen möchte von XMFLOAT3 nach XMVECTOR umlagern?!
Auch wenn ich nur einen 2D-Vektor brauche?

Hab ich das einfach nur noch nicht richtig verstanden oder ist das am Ende wirklich so? Falls ja, D3DX ftw.

Re: Jammer-Thread

Verfasst: 28.08.2012, 22:43
von dot
Dafür generiert es dir SSE Code. D3DX ftl. ;)

Re: Jammer-Thread

Verfasst: 29.08.2012, 13:33
von Schrompf
Achtung, dicke Bilder.

Einer unserer Grafiker hat vor geraumer Weile mal den Basis-Charakter für die Splitterwelten geschaffen. Der heißt so, weil er das Skelett und die Schnittstellen definiert, nach der sich alle weiteren Köpfe und Körper zu richten haben, damit wir kombinieren können. Ich habe leider nicht mehr das orginale UV-Layout da, daher hab ich ihm mal zum Zeigen schnell einen Metall-Shader verpasst. Der Typ sah damals nämlich so aus:

Bild

Bevor es nun aber dazu kam, dass wir auf diesen Vorgaben basierend weitere Köpfe oder Körper bekommen hätten, hat der Grafiker erstmal noch irgendwas "optimiert". Das hat nicht nur das UV-Layout über den Haufen geworfen, sondern vor allem die verdammte Bind Pose und das komplette fucking Koordinatensystem!. Wenn man jetzt die damals erstellten Platzhalter-Anims auf das neue Skelett anwendet, bekommt man sowas hier:

Bild

Und so standen jetzt alle Charaktäre im Spiel rum. Rumlaufen führte zu einer kleinen Explosion an Dreiecken. Ich habe nun insgesamt vielleicht 6 volle Arbeitstage investiert, um die Anims irgendwie auf das neue Skelett umzurechnen. Hiermit gebe ich offiziell auf. Die meisten Versuche waren nur noch schlimmer explodiert als vorher, die aktuelle Version jetzt ist zwar immernoch in sich verdreht, aber zumindest nicht mehr so schmerzhaft für die armen Dorfbewohner:

Bild

Wenn wir irgendwann mal richtige Anims bekommen sollten, werden die ja gleich auf dem neuen Skelett erstellt oder von einer MoCap-Quelle auf das neue Skelett umgerechnet. Dann hoffentlich von einem Tool, das schlauer als ich ist.

Re: Jammer-Thread

Verfasst: 30.08.2012, 18:35
von eXile
Die Quick-Launch-Leiste von Visual Studio 2012 ist total nutzlos: Man kann noch nicht einmal nach den Einstellungen aus den Property-Manager suchen (also so etwas wie neue Libraries setzen, etc.). Man kann sie immerhin abschalten.

Re: Jammer-Thread

Verfasst: 30.08.2012, 18:44
von kimmi
Board-Support-Packages und Cross-Compiler-Environments aufsetzen für Embedded-Linux in einem Firmen-Netzwerk, welches den assigsten Proxy dieses Planeten hat, mit Störungen zwecks Festlegung von Requirements über knittrige Telefon-Leitungen in die USA und dazu eine schlecht gelaunte Freundin zu Hause, weil das Kind krank ist und helut, gehören definitiv verboten. Ich fahr mal durch den Regen heim in die Taufe.

Gruß Kimmi

Re: Jammer-Thread

Verfasst: 30.08.2012, 20:07
von antisteo
eXile hat geschrieben:Die Quick-Launch-Leiste von Visual Studio 2012 ist total nutzlos: Man kann noch nicht einmal nach den Einstellungen aus den Property-Manager suchen (also so etwas wie neue Libraries setzen, etc.). Man kann sie immerhin abschalten.
Ist diese Leiste ein Feature der IDE oder der grafischen Oberfläche? (Okay, die wist bei Windows Teil des Kernels...)

Re: Jammer-Thread

Verfasst: 30.08.2012, 20:45
von eXile
antisteo hat geschrieben:Ist diese Leiste ein Feature der IDE oder der grafischen Oberfläche?
Ersteres.

Re: Jammer-Thread

Verfasst: 30.08.2012, 21:22
von antisteo
eXile hat geschrieben:
antisteo hat geschrieben:Ist diese Leiste ein Feature der IDE oder der grafischen Oberfläche?
Ersteres.
Es ist doch Microsoft... Wieso bauen die nicht gleich die Suchfunktion ins Programm-Menü ein? Ubuntu machts doch vor.

Re: Jammer-Thread

Verfasst: 30.08.2012, 21:56
von Schrompf

Code: Alles auswählen

unsigned int pos = someStdString.find( '$');
if( pos == std::string::npos )
  break;
Unter 64Bit wird die Bedingung nie erfüllt. Wie sagte CodingCat mal so schön: der größte Feind des Programmierers ist sein 5 jahre jüngeres Selbst. In diesem Fall 8 Jahre oder so, aber trotzdem würde ich mir gern rückwärts durch die Zeit eine Ohrfeige verpassen.

[edit] Und weiter geht der Reigen:

Code: Alles auswählen

size_t off = someStdString.find( '$');
if( off == 0xffffffff )
  break;
Es ist nie zu spät, aber selten zu früh, die Freuden von size_t und SIZE_MAX kennen zu lernen.

Re: Jammer-Thread

Verfasst: 30.08.2012, 22:09
von dot
Schrompf hat geschrieben:Es ist nie zu spät, aber selten zu früh, die Freuden von size_t und SIZE_MAX kennen zu lernen.
Oder in dem Fall überhaupt einfach auto ;)

Re: Jammer-Thread

Verfasst: 01.09.2012, 14:46
von Krishty
Dass WinAPI-Nachrichten nicht mit einem präzisen Zeitstempel kommen, ist ein riesiger Haufen Scheiße. Ich kann garnicht in Worte fassen wie fatal das für die Komplexität von Hochleistungsanwendungen ist.

Re: Jammer-Thread

Verfasst: 01.09.2012, 17:21
von Krishty
Mein räudiges Nokia-Handy hat eine logarithmische Batteriestandsanzeige. Eine Woche zeigt es 100 % an; dann zwei Tage 75; einen Tag 50; eine halbe Stunde 25; und dann ist es leer. Wenn man bei 75 % zwei Tage wegfährt und den Stecker nicht mitnimmt, ist man gearscht.

Re: Jammer-Thread

Verfasst: 01.09.2012, 21:42
von antisteo
Ausgerechnet der Funktionsaufruf der Physik-Bibliothek, der die meiste Rechenzeit beansprucht, kann nicht parallel aufgerufen werden, weil die Funktion am Anfang viel rechnet und das Ergebnis anschließend in irgendeine verkettete Liste einsortiert. Warum?

Re: Jammer-Thread

Verfasst: 02.09.2012, 15:36
von Krishty
Die gute Nachricht: Ich habe Visual C++ gerade dazu gekriegt, unter x86 die Gleitkommaarithmetik mit SSE durchzuführen.

Die schlechte Nachricht: Ich weiß nicht, wie.

Die noch schlechtere Nachricht:

Code: Alles auswählen

 cvtsi2ss    xmm1,ebx  
 cvtss2sd    xmm0,xmm0  
 cvtps2pd    xmm1,xmm1  
 mulsd       xmm0,xmm3  
 mulsd       xmm1,xmm3  
 cvtsd2ss    xmm0,xmm0  
 cvtpd2ps    xmm1,xmm1  
 movss       dword ptr [esp+1B0h],xmm0  
 movss       dword ptr [esp+1B4h],xmm1  
 movq        xmm4,mmword ptr [esp+1B0h]  
 movq        mmword ptr [esp+23Ch],xmm4  
 movss       xmm4,dword ptr [ecx+1AD0h]  
 cvtps2pd    xmm4,xmm4  
 cvtss2sd    xmm0,xmm0  
 addsd       xmm4,xmm0  
 add         edi,eax  
 sub         edi,edx  
 cvtsi2ss    xmm2,edi  
 xorps       xmm0,xmm0  
 cvtpd2ps    xmm0,xmm4  
 movss       xmm4,dword ptr [ecx+1AD4h]  
 cvtps2pd    xmm4,xmm4  
 cvtps2pd    xmm2,xmm2  
 cvtss2sd    xmm1,xmm1  
 addsd       xmm4,xmm1  
 mulsd       xmm2,xmm3  
 cvtpd2ps    xmm2,xmm2  
 movss       dword ptr [esp+1B8h],xmm2  
 mov         edx,dword ptr [esp+1B8h]  
 xorps       xmm1,xmm1  
 cvtpd2ps    xmm1,xmm4  
 movss       xmm4,dword ptr [ecx+1AD8h]  
 cvtps2pd    xmm4,xmm4  
 cvtss2sd    xmm2,xmm2  
 addsd       xmm4,xmm2  
 cvtps2pd    xmm6,xmm0  
 mov         dword ptr [esp+244h],edx  
 cvtpd2ps    xmm2,xmm4  
 cvtps2pd    xmm4,xmm1  
 mulsd       xmm4,xmm5  
 movss       xmm5,dword ptr [esp+60h]  
 cvtps2pd    xmm5,xmm5  
 mulsd       xmm5,xmm6  
 movss       xmm6,dword ptr [esp+78h]  
 addsd       xmm4,xmm5  
 cvtps2pd    xmm6,xmm6  
 cvtps2pd    xmm5,xmm2  
 mulsd       xmm5,xmm6  
 movss       xmm6,dword ptr [esp+84h]  
 cvtps2pd    xmm6,xmm6  
 addsd       xmm5,xmm6  
 addsd       xmm4,xmm5  
 movss       xmm6,dword ptr [esp+70h]  
 cvtps2pd    xmm5,xmm1  
 cvtps2pd    xmm7,xmm0  
 cvtps2pd    xmm6,xmm6  
 mulsd       xmm5,xmm6  
 movss       xmm6,dword ptr [esp+64h]  
 cvtps2pd    xmm6,xmm6  
 mulsd       xmm6,xmm7  
 movss       xmm7,dword ptr [esp+7Ch]  
 addsd       xmm5,xmm6  
 cvtps2pd    xmm0,xmm0  
 cvtps2pd    xmm7,xmm7  
 cvtps2pd    xmm1,xmm1  
 cvtps2pd    xmm6,xmm2  
 mulsd       xmm6,xmm7  
 movss       xmm7,dword ptr [esp+88h]  
 cvtps2pd    xmm7,xmm7  
 addsd       xmm6,xmm7  
 addsd       xmm5,xmm6  
 cvtpd2ps    xmm5,xmm5  
 movss       dword ptr [esp+24Ch],xmm5  
 movss       xmm5,dword ptr [esp+74h]  
 cvtps2pd    xmm5,xmm5  
 mulsd       xmm1,xmm5  
 movss       xmm5,dword ptr [esp+68h]  
 cvtps2pd    xmm5,xmm5  
 mulsd       xmm5,xmm0  
 cvtps2pd    xmm0,xmm2  
 movss       xmm2,dword ptr [esp+80h]  
 cvtps2pd    xmm2,xmm2  
 mulsd       xmm0,xmm2  
 movss       xmm2,dword ptr [esp+8Ch]  
 cvtps2pd    xmm2,xmm2  
 addsd       xmm0,xmm2  
 addsd       xmm1,xmm5  
Fast die Hälfte des Texts sind Konvertierungen zwischen float und double – und das obwohl im Quelltext überhaupt keine double vorkommt. Die eigentliche Berechnung kann man überhaupt nicht mehr erkennen. Vielleicht steckt dahinter ein besonders absurder Versuch, die FPU nachzubilden. Ich weiß es nicht.

Re: Jammer-Thread

Verfasst: 02.09.2012, 19:50
von CodingCat
C++' iostream-API ist eine absolute Frechheit. Sowohl weil sie zeigt, wie man Vererbung NICHT benutzt, als auch, weil sie nur aus einem riesigen unsortierten Haufen kryptischer Abkürzungen besteht. Davon abgeshen ist sie gnadenlos over-engineered (Wie war das mit EINER Aufgabe pro Klasse?), weshalb sie obendrein auch noch gnadenlos verfettet und ineffizient ist.

Re: Jammer-Thread

Verfasst: 03.09.2012, 13:52
von Biolunar
CodingCat hat geschrieben:C++' iostream-API ist eine absolute Frechheit. Sowohl weil sie zeigt, wie man Vererbung NICHT benutzt, als auch, weil sie nur aus einem riesigen unsortierten Haufen kryptischer Abkürzungen besteht. Davon abgeshen ist sie gnadenlos over-engineered (Wie war das mit EINER Aufgabe pro Klasse?), weshalb sie obendrein auch noch gnadenlos verfettet und ineffizient ist.
Hast du konkrete Punkte, die dich stören? Bevor ich verstanden habe wie die Lib funktioniert, habe ich nämlich ähnlich gedacht ;)

Re: Jammer-Thread

Verfasst: 04.09.2012, 15:16
von Artificial Mind
http://io9.com/5940036/how-copyright-en ... ugo-awards
Willkommen in einer dystopischen Realität ...

Re: Jammer-Thread

Verfasst: 04.09.2012, 19:49
von MoritzPGKatz
Artificial Mind hat geschrieben:http://io9.com/5940036/how-copyright-en ... ugo-awards
Willkommen in einer dystopischen Realität ...
Oha...

Zum Thema passend:
Ich war am Sonntag auf dem Barcamp der C3S - wen das Thema Urheberrecht/Lizensierung interessiert und nicht nur über GEMA & Co. meckern, sondern auch eine Alternative supporten möchte, sollte sich das unbedingt mal reinziehen.

Re: Jammer-Thread

Verfasst: 05.09.2012, 23:10
von antisteo
gwX muss die Voxel in Newton-Objekte umrechnen. Bis jetzt habe ich die Voxel als konvexe Hüllen erzeugt und als Objekte gespawnt. Das war zwar zur Laufzeit schnell, dafür aber für Änderungen der Landschaft irre langsam.
Die schnellere Variante ist, die Dreiecke des Marching Cube als TreeCollision zu erstellen. Allerdings hat Newton einen Bug, wodurch bei gewissen Eingabedaten Newton abschmiert.
Dass Newton bei falschen Eingabedaten abschmiert, ist nichts neues. Allerdings lasse ich mir die Dreiecke loggen und es sind valide Dreiecke. Kein NaN, kein Infinity, keine Dreiecke, bei denen die Eckpunkte aufeinanderliegen...
es ist zum heulen.

Re: Jammer-Thread

Verfasst: 06.09.2012, 21:47
von glassbear
Erfahrene Elektrotechniker schreiben Code wie ich vor vielleicht 6-7 Jahren. AAAAAAAAAAAAAAAAAAAAAAAH. Und ich soll das "mal eben" umarbeiten und auf Threading umstellen. AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAH. :twisted:

Re: Jammer-Thread

Verfasst: 06.09.2012, 22:01
von Jörg
Kannst denen ja mal zum Dank eine Schaltung entwerfen ;)

Re: Jammer-Thread

Verfasst: 06.09.2012, 22:57
von glassbear
Jörg hat geschrieben:Kannst denen ja mal zum Dank eine Schaltung entwerfen ;)
Machen die ja nicht mal. Die schreiben nur Code. Uebel :twisted:

Re: Jammer-Thread

Verfasst: 06.09.2012, 23:35
von kaiserludi
eXile hat geschrieben:
Krishty hat geschrieben:Eben angepackt (allerdings mit unsigned (normalized) int). Wie gut sich das anfühlt … den Quadranten eines Winkels für die eigenen trigonometrischen Funktionen bestimmen? Bloß die oberen Bits abfragen!
Das ist schön zu hören. :) Hast du dir neue Minimax-Polynome gebastelt, um die höhere Genauigkeit (in Vergleich zu float) zu nutzen?
Krishty hat geschrieben:Wo genau, außer bei Quaternion-Interpolation, ist das von Nutzen?
Naja, genau da. Und zwar sowohl beim SLERP mit Quaternionen wie auch der Konvexkombination von Quaternionen. Ich wollte eher davor warnen, im Bereich der Quaternionen auch nur in irgendeiner Weise mit Winkeln zu rechnen, genauso wenig wie man im Bereich der Rotationsmatrizen niemals plötzlich anfangen sollte, mit Winkeln zu rechnen.
glassbear hat geschrieben:AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAH. :twisted:
Du hast noch nie Code von Mathematikern gesehen. Ich sage nur: Jeder Variablenname ist maximal zwei Buchstaben lang. AAAAAAAAA!
Das geile ist: Die allersete Programmierpsrache, in der ich entwickelt habe, war damals TI-Basic, ein von der Syntax Basic recht nahe Interpretersprache für grafische Taschenrechner. Der Speicherplatz auf den Geräten war knapp und alle Programme wurden bei jedem Run komplett aus dem Source interpretiert, jeder Kommentar hat also den Bedarf an äußerst knappem Endbenutzer"-festplattenplatz" (ok, eigentlich ein Flashspeichership, aber eben als Dauerspeicher genutzt) erhöht. Um möglichst viele möglichst umfangreiche Games dort unterzubringen habe ich aberweitzige Codesizeoptimierungen betrieben und Spiele von 20k Sourcecode auf 5k optimiert. Das beliebteste nake auf dem System hatte, bevor ich mich daran gemacht habe, ca. 2k Code, nach meinen Optimierungen unter 200Bytes ohne Funktionseinbußen und lief dann auch doppelt so schnell. Null Kommentare und alle Variablennamen auf einzelne Buchstaben umbennen waren da noch die harmloseren Geschichten.

Re: Jammer-Thread

Verfasst: 07.09.2012, 17:49
von spobat
Schau an, was Visual Studio 11 mit meinem aus Visual Studio 10 headern macht:

Code: Alles auswählen

virtual virtual static static static void init();
Ich frage mich ja, was hier ein static *ueberhaupt* zu suchen hat. Ist wohl mehr als nur eine "wortverfielfachung".
Zum glueck laesst sich das aber mit einem "find-replace" durchgang beheben :)

Ist es eine gute Idee, die gleichen Funktionen in verschiedenen Menues zu haben?
"Run Code Analysis" findet sich beispielsweise sowohl unter "BUILD" als auch unter "ANALYZE".
Ich find es ne schlechte Sache, das muellt nur die Menues zu und sorgt fuer uneinheitliche Bedienung zwischen Entwicklern.