Seite 40 von 255

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:

Re: Jammer-Thread

Verfasst: 30.09.2011, 00:30
von CodingCat
Woah. WOAH! Wenn ich den ROTZLÖFFEL erwische, der meinte, er müsse dem WICHTIGSTEN aller Schrottdialoge einen RIESIGEN MULTIMEDIASCHIRM vorschalten! Nur weil ich versehentlich rekursiv Graphikressourcen reserviere und dabei vergessen habe, den Debugger anzuheften, bringt es dieses Drecksteil nicht mehr fertig, seinen bunten niedrigprioren Megasicherheitsbildschirm in den von mir höchstpersönlich vollgestopften VRAM zu laden. KEINE CHANCE, das Ding abzuschießen, weil der Task Manager ja unerreichbar dahinter schlummert. Ich kann ZUGUCKEN, wie der Speicher überläuft. Und DAS DAUERT!


Re: Jammer-Thread

Verfasst: 30.09.2011, 03:03
von kaiserludi
CodingCat hat geschrieben: Ich kann ZUGUCKEN, wie der Speicher überläuft. Und DAS DAUERT!
Notfalls eben Stromzufuhr kappen, wenn das neu erstellen nicht gespeicherter Daten deutlich besser dasteht im Verhältnis zur Wartezeit ;)

Re: Jammer-Thread

Verfasst: 30.09.2011, 12:18
von Helmut
Oder einfach Strg+Umschalt+Esc drücken ;)

Re: Jammer-Thread

Verfasst: 30.09.2011, 13:42
von CodingCat
Du bist mein Held! Vielleicht sollte ich irgendwann mal einen Windows-Anfängerkurs besuchen.

Re: Jammer-Thread

Verfasst: 30.09.2011, 14:17
von j.klugmann
Oder einfach auf Linux umsteigen. :P

Re: Jammer-Thread

Verfasst: 30.09.2011, 15:01
von joggel
Auf der Hauptseite werden keine Thump-Nails mehr vom Showrom gezeigt.
Der Rest geht, also Tooltip wenn Maus darüber ist; man wird auch in den entsprechenden Post geleitet wenn man da etwas anklickt.
Mein Firefox hat gerade ein Update gemacht... ist es bei wem anders auch so?

Re: Jammer-Thread

Verfasst: 30.09.2011, 15:07
von glassbear
Jep, gleiches Problem hier mit Firefox 7.0.

Re: Jammer-Thread

Verfasst: 30.09.2011, 16:00
von Chromanoid
Sollte jetzt wieder gehen. Bei weiteren Problemen am besten bitte hier schreiben: http://zfx.info/viewtopic.php?f=9&t=1162

Re: Jammer-Thread

Verfasst: 30.09.2011, 16:48
von CodingCat
Ich habe meine gesamte Rendering Pipeline durchgemessen. Ich habe eine fixe Bildwiederholrate probiert. Ich habe einen dynamischen Frame-Zeit-Normalisierer gebaut. Hilft allex nix, ab einer bestimmten Renderlast streuen die Frame-Zeiten locker um 10 ms, gerne auch mal mehr, natürlich nur wenige Male in der Sekunde - die perfekten Ruckler, die selbst bei 100 Bildern in der Sekunde ein Gefühl von 15 oder weniger FPS vermitteln.

Die Lösung: Vista Aero Desktop abschalten. Plötzlich läuft alles wie geschmiert, selbst bei 20 Bildern in der Sekunde wirkt das noch butterweich, dank perfekt gleichmäßiger Frame-Zeiten.

Der Frame-Zeit-Normalisierer ist im Übrigen dennoch eine feine Sache, weil er bei punktuellen Abweichungen einzelner Frame-Zeiten verhindert, dass das darauffolgende (wieder schnell gerenderte) Frame aufgrund der überdurchschnittlich großen vorangegangenen Frame-Zeit in einem Sekundenbruchteil gleich nochmal einen riesen Satz macht. So hat man eine nahezu konstante Frame-Zeit, ohne sich gleich auf eine fixe Bildwiederholrate festlegen zu müssen:

Code: Alles auswählen

m_timeStep = 0.95 * m_timeStep + 0.05 * m_timer.seconds();
Um trotzdem der variablen Frame-Zeit gerecht zu werden, fülle ich die danach vom letzten Frame übrige Zeit im Moment mit Sleeps auf, so passt sich auch die tatsächliche Frame-Zeit bei starker Fluktuation der Renderlast schön gemächlich an.

Re: Jammer-Thread

Verfasst: 30.09.2011, 18:04
von eXile
Schnelle Frage: Ergibt die Aktivierung von V-Sync irgendeinen Unterschied?

Code: Alles auswählen

m_timeStep = 0.95 * m_timeStep + 0.05 * m_timer.seconds();
Sieht ja fast so aus wie ein gleitender Durchschnitt, welcher auch bei RTT-Messungen von van Jacobson vorgeschlagen wurde. Der wurde dann mit folgender Formel verbessert:

Code: Alles auswählen

SRTT(k+1) = (1-g) · SRTT(k) + g · RTT(k+1)
SERR(k+1) = RTT(k+1) – SRTT(k)
SDEV(k+1) = (1-h) · SDEV(k) + h · |SERR(k+1)|
RTO(k+1) = SRTT(k+1) + f · SDEV(k+1)

RTT round-trip time
SRTT smoothed round-trip time
SERR smoothed error
SDEV smoothed mean deviation
RTO retransmission timeout

g = 1/8, h =1/4, f = 4
Kannst ja mal schauen, ob das irgendwas bringt.

Re: Jammer-Thread

Verfasst: 30.09.2011, 18:21
von CodingCat
V-Sync ändert daran leider absolut gar nichts. Ja, das ist exakt die Formel mit 1/8 statt 1/20. Aber das ändert natürlich nichts an den kurzzeitigen Frame-Zeit-Peaks, die kommen schließlich nicht von mir.

Re: Jammer-Thread

Verfasst: 01.10.2011, 16:30
von Krishty
Ich habe zwei Tage damit verschwendet, herauszufinden, in welchem Format mir XAudio2 die Daten übergibt, wenn ich meinen eigenen Effekt schreibe. Die Dokumentation sagt keinen Pieps dazu (zumindest habe ich nichts gefunden) und sowohl in der Doku als auch im SDK gibt es kein Beispiel, was etwas anderes macht als memset() und memcopy() mit den Daten aufzurufen. Die IsInputFormatSupported()-Funktion, die man zu Verfügung stellen soll, wird niemals aufgerufen.

Jetzt weiß ich es immernoch nicht und schreibe es einfach so, dass es bei mir funktioniert.

Re: Jammer-Thread

Verfasst: 01.10.2011, 18:42
von Artificial Mind
Grade stellt man fest, dass man ne super coole Lösung hat (http://en.wikipedia.org/wiki/Multi-comm ... ow_problem) und dann ist die NP-vollständig *grrrr*

Re: Jammer-Thread

Verfasst: 01.10.2011, 18:56
von Krishty
Kaum wechselt man den Zufallszahlengenerator, geht alle Feinabstimmung in die Brüche. Ich habe langsam so die Vermutung, dass rand() in der MS-CRT weit von den durch den Standard vorgeschriebenen 15 Bits Entropie weg ist. Anders kann ich mir nicht erklären, dass durchschnittlich um den Faktor 10 größere Zahlen rauskommen, wenn ich für [0; 8191] den Mersenne-Twister benutze …

Re: Jammer-Thread

Verfasst: 01.10.2011, 21:37
von j.klugmann
Habe sich selbst-reproduzierenden Haskell-Code geschrieben. Der Compiler verfängt sich demnach in einer Rekursion, in der er endlos Code produziert.