Seite 40 von 252

Re: Jammer-Thread

Verfasst: 15.09.2011, 16:00
von CodingCat
Aramis hat geschrieben:Nun, ich wuerde einfach praeventiv fuer die naechsten 5 Jahre > > schreiben. Man will ja als braves kleines Programmierlein nicht anecken.
Ja, sehe ich genauso ... NO_RVALUE_REFERENCES, STATIC_ASSERT(false, "C++11 ftw!", Y_u_no_Cxx11_8C) ... :(

Re: Jammer-Thread

Verfasst: 18.09.2011, 00:10
von eXile
MAX_PATH ist sowas von 80er, da kann man sich stattdessen auch direkt eine Vokuhila-Frisur wachsen lassen.

Re: Jammer-Thread

Verfasst: 18.09.2011, 12:54
von Krishty
I lol'd; so true.
————
Audioprogrammierung ist immer wieder ein Krampf. Zum einen ist sie asynchron – aber nicht auf die GPU-Art und -Weise, dass man immer rüberschaufelt und die rendert dann; sondern man muss richtig synchronisieren, unterbrechen, etc. – und zum anderen ist dieses Hintereinanderschalten von Filtern und Stufen der Horror. Insbesondere, wenn das – wie bei XAudio2 – pervers über Prioritätszahlen geschieht statt durch Funktionsaufrufe.

Re: Jammer-Thread

Verfasst: 18.09.2011, 21:36
von Krishty
Deadlock in XAudio2SourceVoice::DestroyVoice(). Wenn man mit dem Rest von DirectX hantiert, weiß man erstmal, wie gut es einem mit Direct3D geht.

Und Google ist scheißerer denn je – in der Suchleiste taucht oft kein Text auf; Vorwärts und Zurück zeigen mir dieselbe Ergebnisseite an; blabla. Echt toll, wie sie die Suchmaschine in den letzten fünf Jahren systsematisch kaputtgemacht haben.

Edit: Error: this method is not valid for mastering voices.
WTF?! Warum packt ihr sie dann in die Schnittstelle rein?!
Zum besseren Verständnis: Die _haben_ Mastering Voices bereits in eine _eigene_ Schnittstelle verfrachtet weil sie sich so von den anderen unterscheiden … m[

Edit 2: Nach fünf Minuten endlich Unhandled exception at 0x00e5c3be: 0xC0000005: Access violation reading location 0xdeadd055. Na dann war es ja doch kein Deadlock. Mann, bin ich beruhigt!

Edit 3:
http://msdn.microsoft.com/en-us/library/microsoft.directx_sdk.ixaudio2voice.ixaudio2voice.destroyvoice hat geschrieben:DestroyVoice waits for the audio processing thread to be idle, so it can take a little while (typically no more than a couple of milliseconds).
Eine Handvoll Milisekunden … eine Handvoll Minuten … wo ist da der Unterschied. Klar; ist mit an Sicherheit grenzender Wahrscheinlichkeit meine Schuld. Was erdreiste ich mich auch, zu erwarten, dass man mich darauf hinweist, wenn ich die API missbrauche. Also, wie kriege ich den Thread jetzt idle? Alle Objekte außer der Mastering Voice sind gestoppt, geflusht und zerstört …

Re: Jammer-Thread

Verfasst: 22.09.2011, 00:06
von CodingCat

Code: Alles auswählen

#include <cstddef>
 
template <class Size> 
struct uint_test 
{ 
     static_assert( static_cast<Size>(-1) > static_cast<Size>(0), "VC10, Y U NO TEMPLATES! :-((" ); // error C2338: VC10, Y U NO TEMPLATES! :-((
};
 
int main()
{
   uint_test<size_t> abcd;
   return 0;
}
Ich bin es SO leid.


Re: Jammer-Thread

Verfasst: 22.09.2011, 15:42
von CodingCat
Was zur Hölle tut Thunderbird, dass Fraps meint, eine Framerate darübermalen zu müssen?
mailfps.png
mailfps.png (7.97 KiB) 3023 mal betrachtet

Re: Jammer-Thread

Verfasst: 22.09.2011, 15:52
von eXile
Direct2D. Kriegt man wohl weg, indem man gfx.direct2d.disabled auf true stellt. Oder ein Update von Fraps (siehe hier).

Re: Jammer-Thread

Verfasst: 24.09.2011, 10:59
von Jonathan
Für einen der noch nie static_assert benutzt hat: Was genau passiert da und warum ist es falsch?

Re: Jammer-Thread

Verfasst: 24.09.2011, 11:22
von CodingCat
static_assert() ist ein assert(), welches bereits zur Compile-Zeit ausgewertet werden muss. Der Compiler stellt sicher, dass der geprüfte Ausdruck zur Compile-Zeit auswertbar und wahr ist. So lässt sich beispielsweise wie oben testen, ob ein bestimmer Typ unsigned ist. -1 ist für unsigned Integers über Kongruenz stets als der größte durch diesen Integer-Typen darstellbare Wert definiert, somit muss static_cast<UInt>(-1) > static_cast<UInt>(0) gelten. Leider versäumt es der Visual C++ Compiler an dieser Stelle jedoch, den Cast korrekt auszuwerten.

Ist die Bedingung eines static_asserts nicht erfüllt, so gibt der Compiler eine Fehlermeldung aus, die den im zweiten Argument gegebenen Fehlertext enthält.

Re: Jammer-Thread

Verfasst: 24.09.2011, 13:01
von Aramis
Moment, aber das gilt auch nur wenn die Architektur die Komplementdarstellung von vorzeichenbehafteten Integern nutzt.

Re: Jammer-Thread

Verfasst: 24.09.2011, 13:19
von CodingCat
§4.7.2 hat geschrieben:If the destination type is unsigned, the resulting value is the least unsigned integer congruent to the source
integer (modulo 2^n where n is the number of bits used to represent the unsigned type). [ Note: In a two’s
complement representation
, this conversion is conceptual and there is no change in the bit pattern (if there
is no truncation). —end note ]
Nein, immer.

Re: Jammer-Thread

Verfasst: 24.09.2011, 17:33
von Aramis
Gut zu wissen, danke :-)

Re: Jammer-Thread

Verfasst: 24.09.2011, 18:00
von Krishty
Das ist übrigens auch der Grund, warum Schleifen mit signed int als Zählertyp u.U. besser optimierbar sind als Schleifen mit unsigned int als Zählertyp – bei vorzeichenlosen Typen sind Über- und Unterläufe wohldefiniert; die Invariante x + 1 > x gilt dann nicht mehr und die Schleife muss potenziell unendlich oft ausgeführt werden. Auch (x * y / y) kann mit unsigned int aus diesem Grund u.U. nicht zu (x) optimiert werden.

Re: Jammer-Thread

Verfasst: 25.09.2011, 10:59
von Krishty
if(__readeflags() & 1) { // fatal error C1001: An internal error has occurred in the compiler.
// (compiler file 'f:\dd\vctools\compiler\utc\src\p2\main.c[0x57E6957B:0x00000020]', line 183)
// To work around this problem, try simplifying or changing the program near the locations listed above.


Funktionieren ja toll, eure Intrinsics

Re: Jammer-Thread

Verfasst: 25.09.2011, 15:14
von Krishty
float lengthOf(
    Vector3D const & v
);


macht mir

template <
    typename Element,
    Size arraysSize
> Size lengthOf(
    Element const (&)[arraysSize]
) {
    return arraysSize;
}


kaputt, weil der Compiler bei der Namensauflösung Template-Funktionen benachteiligt. Bei Vektoren ist es ja nur halb so schlimm, weil man da mathematisch korrekt von Betrag statt Länge sprechen und ich das entsprechend zu absoluteOf() ändern muss. Aber sobald ich Strecken einführe, wird wieder alles kaputtgehen … Ich glaube, dass ich mal wusste, warum, und dass ich das dann auch total rational fand. Jetzt gerade ist es mir aber entfallen … ehrlich jetzt: Überladungen verbieten? Das ist doch C-Level … und darum: absolute Rage!

SFINAE gilt immer nur, wenn man es nicht braucht …


Ups, das war garnicht die Überladung … eher ADL, wenn die in unterschiedlichen namespaces liegen … danke, Cat. Daraus ergibt sich dann auch die Lösung: Das lengthOf aus dem äußeren namespace via using ins innere importieren.

Re: Jammer-Thread

Verfasst: 26.09.2011, 10:00
von Thoran
Hab grad gemerkt, dass ich dieses Jahr nicht zur Devmania kann, wegen des Termins. :cry:
Vielleicht nächstes Jahr.

Thoran

Re: Jammer-Thread

Verfasst: 27.09.2011, 15:00
von Schrompf
Maaaaaaannnn... GIMP ist doch der reine Hass für einen Programmierer.

"Entferne Alphakanal" bedeutet nicht etwa, den Alphakanal zu entfernen, sondern auch, alle Farbwerte mit irgendner wahlfreien Farbe zu überblenden. "Alphakanal fixieren" bedeutet durchaus "Alphakanal fixieren", aber nur bei bestimmten Werkzeugen und nicht etwa auch beim Ebenen-Vereinen oder Einfügen einer Auswahl. Es hat sich als absolut unmöglich herausgestellt, die Farbwerte einer NormalMap mit den Alpha-Werten einer normalen Grafik zu vereinen. Jetzt schreib ich mir ein gottverdammtes Tool dafür!

[edit] Hab ihn doch überrumpelt! Zum Glück gibt es als Bildeffekt auch die Faltungsmatrix, die man auch mit einem Bias versehen und nur auf bestimmte Kanäle beschränken kann. Nimm das, Workflow!

Re: Jammer-Thread

Verfasst: 27.09.2011, 17:20
von Dirk Schulz
Schrompf hat geschrieben:Maaaaaaannnn... GIMP ist doch der reine Hass für einen Programmierer.

"Entferne Alphakanal" bedeutet nicht etwa, den Alphakanal zu entfernen, sondern auch, alle Farbwerte mit irgendner wahlfreien Farbe zu überblenden. "Alphakanal fixieren" bedeutet durchaus "Alphakanal fixieren", aber nur bei bestimmten Werkzeugen und nicht etwa auch beim Ebenen-Vereinen oder Einfügen einer Auswahl. Es hat sich als absolut unmöglich herausgestellt, die Farbwerte einer NormalMap mit den Alpha-Werten einer normalen Grafik zu vereinen. Jetzt schreib ich mir ein gottverdammtes Tool dafür!

[edit] Hab ihn doch überrumpelt! Zum Glück gibt es als Bildeffekt auch die Faltungsmatrix, die man auch mit einem Bias versehen und nur auf bestimmte Kanäle beschränken kann. Nimm das, Workflow!
Warum nicht eine neue Ebenenmaske erstellen, die den Inhalt des Alphakanals bekommt?

damit kannst du dann alles machen, was du willst, unter anderem einer anderen Ebene diese Maske übergeben. :!:

sry, dass ich nix zu meckern hab. ;)

Re: Jammer-Thread

Verfasst: 27.09.2011, 20:16
von joggel
:o
Kriiiieeeeshty, Dirk jammert nich!!!

Ich hasse PHP... sehr gewöhnungsbedürftig!

Re: Jammer-Thread

Verfasst: 28.09.2011, 01:04
von CodingCat
Von wegen gewöhnungsbedürftig - Schrottsprache ist noch geschönt.
--
Es ist SO schwer eine einigermaßen ansprechende Umgebung zu generieren. Besonders, wenn alles SO flach aussieht, keine Schatten, keine Raumwahrnehmung.

Re: Jammer-Thread

Verfasst: 28.09.2011, 06:56
von Artificial Mind
Ogre und Mogre und MOIS und MyGUI x64, anscheinend brauchte in deren Community _NIEMAND_ x64-Dlls. Sämtliche Linker/Compilerpaths falsch, zlib-Eintrag in cmake fehlte. Inkremental build funktionierte angeblich auch nicht. 15h lang builden und konfigurieren, herrlich.

Re: Jammer-Thread

Verfasst: 28.09.2011, 14:50
von eXile
Artificial Mind hat geschrieben:Ogre und Mogre und MOIS und MyGUI x64, anscheinend brauchte in deren Community _NIEMAND_ x64-Dlls. Sämtliche Linker/Compilerpaths falsch, zlib-Eintrag in cmake fehlte. Inkremental build funktionierte angeblich auch nicht. 15h lang builden und konfigurieren, herrlich.
Mein Herr, sie haben noch nie versucht, OpenSG zu kompilieren. Da wäre man über 15 Stunden noch froh.

Re: Jammer-Thread

Verfasst: 28.09.2011, 22:28
von Krishty
Gute float-Tests auf NaN, Unendlichkeit usw. sind echt schwer zu kriegen. Entweder wird teuer die FPU zum Vergleichen genutzt (bei den meisten Makros), oder es wird eine kostspielige Konvertierung zu double durchgeführt (eingebaute isnan-Routinen) oder die Funktion ist zwar super optimiert, steckt aber hinter einem indirekten, nicht inline-baren Funktionsaufruf (Microsoft-CRT). Und dauernd munkeln Leute was davon, dass die Hardware den Vergleich superschnell durchführen könnte; in Aktion gesehen habe ich das aber noch nirgends.

Noch dazu hasse ich doppelte Negation in Programmen: Funktionen sollen nicht testen, ob etwas keine Zahl ist, sondern ob es eine ist. Dann heißt es statt if(!isNaN(x)) („falls x nicht keine Zahl ist“) nämlich if(isAN(x)) („falls x eine Zahl ist“).

Das lässt sich auf Unendlichkeit, die ja eigentlich die Negation von Endlichkeit ist, auch noch anwenden. Allerdings muss man sich da auf Grundlage von etwas anderem entscheiden: Auf Endlichkeit testen unterscheidet sich von auf-Unendlichkeit-testen insofern, als dass man mit dem ersten auch direkt NaNs aussortiert, mit dem zweiten nicht. Oder doch nur, falls man erstere Funktion isFiniteNumber() statt isFinite() nennt? Ich weiß es nicht. Genug Programmierphilosophie für heute.

Re: Jammer-Thread

Verfasst: 29.09.2011, 00:51
von kaiserludi
Krishty hat geschrieben:Auf Endlichkeit testen unterscheidet sich von auf-Unendlichkeit-testen insofern, als dass man mit dem ersten auch direkt NaNs aussortiert, mit dem zweiten nicht. Oder doch nur, falls man erstere Funktion isFiniteNumber() statt isFinite() nennt? Ich weiß es nicht. Genug Programmierphilosophie für heute.
Ich vermute, ob NaN eine endliche Nicht-Zahl oder eine unendlich Nicht-Zahl ist, ist undefiniert.

Re: Jammer-Thread

Verfasst: 29.09.2011, 07:31
von glassbear
Krishty hat geschrieben:Noch dazu hasse ich doppelte Negation in Programmen: Funktionen sollen nicht testen, ob etwas keine Zahl ist, sondern ob es eine ist. Dann heißt es statt if(!isNaN(x)) („falls x nicht keine Zahl ist“) nämlich if(isAN(x)) („falls x eine Zahl ist“).
Das ist übrigens nur bei uns so. Die japanische Logik ist standardmäßig negativ, die prüfen seeehr viel mit if(!.... Sehr beliebt auch if(!something != false) :?

Re: Jammer-Thread

Verfasst: 29.09.2011, 08:30
von joggel
Mich würde mal interessieren, wie so ein NaN oder Unedlichkeitstest (positiv oder negativ) auf Bit-Ebene aussieht...
Also, wie werden die Binär dargestellt?

@Jammern
Ich bin mit der Gesamtsituation unzufrieden..

[Edit]
Ah, hab gerade mir meine Frage selber beantwortet:
http://de.wikipedia.org/wiki/NaN

Re: Jammer-Thread

Verfasst: 29.09.2011, 13:08
von CodingCat
Oh the merits of being close to the metal ...

Code: Alles auswählen

id = lean::push_sorted(m_identifiers, name.to<utf8_string>()) - m_identifiers.begin(); // id == undefined

Re: Jammer-Thread

Verfasst: 29.09.2011, 19:46
von Krishty
kaiserludi hat geschrieben:Ich vermute, ob NaN eine endliche Nicht-Zahl oder eine unendlich Nicht-Zahl ist, ist undefiniert.
Ja, denke ich auch. Wahrscheinlich sollte man nach dem Anwendungszweck gehen – und meist wird man die Funktion brauchen um herauszufinden, ob eine Zahl einen Wert hat, mit dem man rechnen kann. Wenn man speziell an der Unendlichkeit interessiert ist, will man wahrscheinlich auch gleich wissen, ob positiv oder negativ.
glassbear hat geschrieben:Das ist übrigens nur bei uns so. Die japanische Logik ist standardmäßig negativ, die prüfen seeehr viel mit if(!.... Sehr beliebt auch if(!something != false) :?
Eeeeeeeewwwww!
joggel hat geschrieben:Mich würde mal interessieren, wie so ein NaN oder Unedlichkeitstest (positiv oder negativ) auf Bit-Ebene aussieht...
Also, wie werden die Binär dargestellt?
[…]
[Edit]
Ah, hab gerade mir meine Frage selber beantwortet:
http://de.wikipedia.org/wiki/NaN
Jopp … hier sind ein paar Tests; Microsofts CRT führt sie so ähnlich durch:

Code: Alles auswählen

bool isNaN(float const & value) { // by reference: Visual C++' code generation is buggy with local floats
	// Fast with Visual C++; with GCC, you may want to use 'union' instead of 'reinterpret_cast' because of strict aliasing rules.
	return 0x7F800000 < (reinterpret_cast<unsigned int const &>(value) & 0x7FFFFFFF); 
}

bool isFiniteNumber(float const & value) { // by reference: Visual C++' code generation is buggy with local floats
	// Fast with Visual C++; with GCC, you may want to use 'union' instead of 'reinterpret_cast' because of strict aliasing rules.
	return 0x7F800000 > (reinterpret_cast<unsigned int const &>(value) & 0x7FFFFFFF);
}

// isInfinite(): Dasselbe mit ==
Beachte, dass die unter x86 langsam sein können, weil die Werte dort erst von der FPU zurück in die CPU geholt werden müssen. Ob sie langsamer als die Alternativen sind, kA. Aber man geht halt immer irgendwo Kompromisse ein.
joggel hat geschrieben:Kriiiieeeeshty, Dirk jammert nich!!!
joggel hat geschrieben:@Jammern
Ich bin mit der Gesamtsituation unzufrieden..
Ich bin weder die Mutter, bei der du petzt, noch der Vater, vor dem du dich fürchtest ;)

Re: Jammer-Thread

Verfasst: 29.09.2011, 20:52
von kaiserludi
Krishty hat geschrieben:Ich bin weder die Mutter, bei der du petzt, noch der Vater, vor dem du dich fürchtest ;)
Aber dafür der OP :P

Re: Jammer-Thread

Verfasst: 29.09.2011, 21:12
von Chromanoid
Bei Naruto laufen momentan echt die schlechtesten Filler überhaupt :evil: