ZFX + Developia

Saturate entweder nur <0> oder <1>?

Ne, A ist sowohl größer 0 als auch größer 1 (womit größer 0 gar nicht mehr explizit erwähnt werden müsste) laut dem Bild, es darf aber scheinbar unbegrenzt groß sein, weil die Spitze Klammer rechts in die falsche Richtung zeigt.

http://msdn.microsoft.com/en-us/library/windows/desktop/bb509645.aspx hat geschrieben:Clamps the specified value within the range of 0 to 1.

Also 0 ≤ A ≤ 1. Und nicht 0 < A > 1. Gibt auch nicht viele A, die letzteres können. Vielleicht war es auch vom Screenshot nicht ganz eindeutig zu sehen, dass das Größer/Kleiner-Zeichen sein sollen.

Neuestes Feature von Xcode 4: Sobald IRGENDEIN (egal, ob von der App genutzt, oder nicht) Provisioning File X Tage vor dem Auslaufen ist, bekommt man beim Bauen der App ein Compiler-Warning, das das Ding in X Tagen ungültig wird. Man kann es allerdings erst an dem Tag verlängern, an dem es tatsächlich ungültig wird.
Bis dahin wird man das Warning nicht los...
Hat bei euch noch nie jemand davon gehört, dass es Firmen gibt, die ihren Programmierern eine Zero-Warnings-Policy vorschreiben?

:twisted: :twisted: :twisted:

Anmerkung aus der Zukunft: PhysX 3.1 macht alles besser.

CodingCat hat geschrieben:

fu.png

:twisted: :twisted: :twisted:

wieso nicht einfach ../../../SDKs/PhysXAPI/* ?
dann sparst du schon mal einen Haufen Pfade ;)

Das habe nicht ich so konfiguriert, das war so beim SDK dabei. Korrekte relative Pade im Quelltext wäre ja wirklich zu viel verlangt - warum nicht gleich alles in einen Ordner? :evil:

Anmerkung aus der Zukunft: PhysX 3.1 macht alles besser.

Aero deaktivieren, und schon macht DDraw einen Sprung zehn Jahre zurück …

*Jammer* Windows 8 Rechteverwaltung..
Der Administrator ist nicht mehr Herr des Computers, sondern ein neuer Systemnutzer wurde darüber gesetzt. Ich darf keine system32-Dateien mehr manipulieren. DLLs werden auch nicht mehr vorrangig im lokalen Pfad gesucht, also alles in allem Aussichtslos, die neue opengl32.dll irgendwie eingesetzt zu bekommen.

Krishty hat geschrieben:Aero deaktivieren, und schon macht DDraw einen Sprung zehn Jahre zurück …

So wie hier?

Ganz genau … hach; wie wenig mein Gedächtnis doch zurückreicht …

Ich habe für breeze 2 das FX-Framework angepasst (ich konnte mir so einen großen Teil der Zustandslogik komplett ersparen), aber natürlich im SDK-Ordner belassen und entsprechend nicht eingecheckt. Nun teste ich seit einer halben Stunde auf meinem Laptop die Engine durch, und wundere mich, warum nur die Hälfte gerendert wird.

Diese räudige Dreckskirche zwei km Luftlinie von hier bimmelt mit ihrem scheiß Glockenzug jeden SO morgen um 9:18 meinen verkaterten Kopp aus dem Bett weil ich auch noch blöd genug bin, in frischer Luft schlafen zu wollen. Hoffentlich brechen die Scheißteile eines Tages ab und begraben dabei auch gleich noch die verdammten Hobbymissionare und Kindermöger unter sich … wie würde extra hinfahren um zu lachen.


P.S.: Wer die Quelle davon kennt – bitte her damit :3

Die verdammte Kirche hat mich schon wieder vollgebimmelt

Das ist doch die Twilight Zone

Die PhysX 3 Serialization bietet ein unglaublich flexibles Interface, mit dem fast sämtliche Einzelteile von Actors bis hin zu einzelnen Meshes gezielt gespeichert und geladen werden können. Mit etwas Kreativität bekommt man es sogar so hingebogen, dass man einzelne Shapes speichern und laden *könnte*, genau was ich brauche! Leider hat sich das Interface dann, wie so oft, als wesentlich flexibler als die darunterliegende Funktionalität erwiesen - am Ende kam ich nicht drumrum, doch ganze Actors zu speichern, und mit einigem Aufwand deren Shapes manuell auf neue Actors zu transferieren; ohne dass dabei die Source-Actors der Szene hinzugefügt werden. Das klappte dann auch schon in der sechsten Variante. :roll:

WebGL: Das bekanntermassen nervenschonende OpenGL in Kombination mit der beinamputierten Wollmilchsau JavaScript ergibt eine Mischung die vollstaendig dazu geeignet ist, selbst den staerksten Indianer zum Heulen zu bringen.

Aber davon abgesehen muss man es einfach lieben. Jedenfalls sofern der eigene Grafiktreiber auf Chromes und Firefox' Treiber-Whitelist drauf ist ;-/

Heilige Mutter meiner selbst!
Folgender Code stört den Visual Studio Compiler tatsächlich in keinster Weise; gibt nicht mal ein Warning:
Ist es vom Standard her tatsächlich erlaubt, delete auf einem Pointer to const aufzurufen? :shock:

Ja, und diese Antwort qualifiert sich schon alleine durch ihre traurige Aussage als Beitrag zum Jammer-Thread.

const bezieht sich auf den 'Inhalt' des Objektes, nicht seine 'Existenz' per se. Eine schreibgeschuetzte Diskette kann ich auch problemlos mit einem Feuerzeug vernichten.

Aramis hat geschrieben:Ja, und diese Antwort qualifiert sich schon alleine durch ihre traurige Aussage als Beitrag zum Jammer-Thread.

const bezieht sich auf den 'Inhalt' des Objektes, nicht seine 'Existenz' per se. Eine schreibgeschuetzte Diskette kann ich auch problemlos mit einem Feuerzeug vernichten.

Aber delete würde ich eher mit nem Format A auf der Diskette vergleichen und das geht ja auch nicht auf einer schreibgeschützten.
Hilfe, ich weiß, was eine Diskette ist, jetzt fühle ich mich alt ;)

Ich sehe da jetzt kein wirkliches Problem. Wieso sollte man delete bei const verbieten? Die Chance, delete versehentlich aufzurufen, halte ich für relativ gering (im Vergleich zu der logischen Veränderungen des Objekts, die const verhindert); wer mutwillig zerstören will, kann das sowieso immer per const_cast tun.

Tatsächlich ist delete auf const-Objektzeigern sogar von Vorteil, beispielsweise würde man bei Referenzzählung in der Regel nicht von einer logischen Veränderung des Objekts sprechen; ist die letzte Referenz freigegeben, muss das Objekt jedoch zerstört werden, auch wenn die Referenzzählung in einer const-Methode stattfindet. Wäre delete auf const-Zeigern verboten, müsste man hier stets const_cast bemühen.

CodingCat hat geschrieben:Ich sehe da jetzt kein wirkliches Problem. Wieso sollte man delete bei const verbieten? Die Chance, delete versehentlich aufzurufen, halte ich für relativ gering (im Vergleich zu der logischen Veränderungen des Objekts, die const verhindert); wer mutwillig zerstören will, kann das sowieso immer per const_cast tun.

Tatsächlich ist delete auf const-Objektzeigern sogar von Vorteil, beispielsweise würde man bei Referenzzählung in der Regel nicht von einer logischen Veränderung des Objekts sprechen; ist die letzte Referenz freigegeben, muss das Objekt jedoch zerstört werden, auch wenn die Referenzzählung in einer const-Methode stattfindet. Wäre delete auf const-Zeigern verboten, müsste man hier stets const_cast bemühen.

Wenn eine Methode ihren Parameter ohne expliziten Cast löschen darf, auch wenn sie es nur unter bestimmten Umständen tut, dann sollte der Parameter meines Empfindens nach nicht const sein, damit der Aufrufer auch ohne Blick in die Doku darauf vorbereitet ist.

Es mir doch hier nicht um Parameter. Referenzzählung läuft i.d.R. irgendwie so ab:

ref_counter *counter;
void add_ref() const { counter->add_ref(); }
void remove_ref() const { if (counter->remove_ref() == 0) delete this; }

Es kann durchaus sinnvoll sein, rein lesenden Nutzern Referenzierung zu ermöglichen, diese sollen deswegen aber nicht das ganze Objekt verändern dürfen. Wenn bereits alle schreibenden Nutzer ihre Referenzen aufgegeben haben, muss das Objekt also bei Aufgabe durch lesende Nutzer irgendwann entfernt werden.

Ich kann GTA III zehn Jahre nach Veröffentlichung immernoch nicht flüssig spielen, während Adaptive Anti-Aliasing aktiv ist … und ich dachte immer, dass man jede noch so brutale Vergewaltigung der D3D-API mit genügend Rechenleistung plätten könnte …

...und ich dachte immer, dass man jede noch so brutale Vergewaltigung der D3D-API mit genügend Rechenleistung plätten könnte …

Ich denke das kann man auch ;)
...warte mal weitere 10 Jahre oder so :D

Kaum sind die Semesterferien rum …



(Disclaimer: Nein, ich habe natürlich nichts dagegen. Ich wollte nur einmal auf diese Korrelation aufmerksam machen. ;))

Ich debugge seit über 2 Stunden einen Crash ganz am Ende beim letzten Release() des ID3D11Device irgendwo tief drinnen in DestroyDriverInstance() laut MS Symbol Files. Ich habe inzwischen alles ausgepackt von Application Verifier bis hin zu Page Heaps mit vollen Traces und Vorwärts-/Rückwärts-Checks. Absolut keine Zusatzinformation. Ich hatte diese Crahes schonmal vor ca. 2 Monaten, konnte sie dann aber bis heute nicht mehr reproduzieren. Nun sind sie wieder da, spontan und unerklärlich.

Crash hängt davon ab, ob ich im letzten Frame vor dem Beenden ein ganz bestimmtes Render Target setze oder nicht. Hoffentlich liegts am Treiber.

WOW, seit wann lassen sich Grafiktreiber ohne Neustart installieren?!

Zurück zum Thema: Nun sitzt der Crash noch tiefer, und lässt sich überhaupt nur noch mit dem App Verifier auslösen. Ohne Verifier läuft alles "korrekt" - ich mag gar nicht daran denke, was da alles nicht korrekt läuft, aber ich sehe auch keine Möglichkeit, daran noch irgendetwas zu ändern.

CodingCat hat geschrieben:Ohne Verifier läuft alles "korrekt"

Ich sehe da noch nicht unbedingt ein Hindernis.

http://blogs.msdn.com/b/davidklinems/archive/2005/07/12/438061.aspx hat geschrieben:Does a first chance exception mean there is a problem in my code?
First chance exception messages most often do not mean there is a problem in the code. For applications / components which handle exceptions gracefully, first chance exception messages let the developer know that an exceptional situation was encountered and was handled.

Leider ist das aber keine continuable Exception:
Ich habe das Problem inzwischen noch genauer analysiert und lokalisiert: Der Crash findet immer dann statt, wenn im letzten Frame dasselbe multisampled Render-Target zunächst mit und dann ohne Tiefenpuffer beschrieben wurde. :evil: