[DX9] Grafikfehler bei Release Kompilierung

[FunMaker]

Aloah!

Ich habe ein merkwürdiges Problem wo ich nicht weiß woran das Problem liegen könnte.

Ich habe eine Sprite Engine in DX9 geschrieben.
Als Textur verwende ich ein PNG(Teilausschnitt siehe unten[ist jpg da das PNG in einem Archiv-File drinne ist und ich es zur Zeit nicht extrahieren kann]) mit wo die Frames von einer Animation oder auch stillstehende Sterne drinne sind.
Ich habe für jede Textur einen eigenen dynamischen Vertexbuffer. Die grundsätzliche Positionierung/Orientierung der Sprites mache ich per Hand und schicke die dann in den VB. Somit muss ich für jede Textur nur einen Drawcall aufwenden und keine Matrizen neu setzen(ist nach mehrern Versuchen die schnellste Option die ich gefunden habe für viele Sprites auf dem Bildschirm). Die Transformation und das rendern ist hierbei in einem anderen Thread ausgelagert.

Jetzt zum Problem:
Ich benutze VS2008, im Moment die Release DX-DLLs und wenn ich mit Debug-Einstellungen kompiliere ist auch alles wunderbar(siehe unten). Wenn ich nun aber mit Release-Einstellungen kompiliere hat ein Stern Probleme mit seinen (Textur-)koordinaten und das noch viel merkwürdigere aus meiner Sicht ist:
Wenn ich 171 Sterne oder weniger darstelle passiert dieser Fehler nicht - ab 172 Sternen tritt dieser Fehler aber auf?! Wenn ich noch mehr Sterne nehme ist immer der letzte Stern hiervon betroffen, alle vorherigen aber nicht.
Einen zu kleinen VB kann ich ausschließen da dieser nicht an die Sternanzahl gekoppelt ist und ausreichend groß sein sollte. Ein Problem mit dem Multithreading kann ich nach aktuellem Erkenntnissstand auch ausschließen - selbst mit D3DCREATE_MULTITHREADED tritt dieser Fehler auf aber bisher gehe ich davon aus das ich den Multithreaded Parameter nicht brauche, deshalb lasse ich ihn weg.

Über Hilfe würde ich mich freuen :)

[Aramis]

Im Normalfall sind uninitialisierte Variablen beziehungsweise Speicherbereiche schuld wenn Programme in Release-Builds ein ganze anderes Verhalten an den Tag legen als in Debug-Builds. Grund ist, dass der Compiler in Debug-Builds Variablen stets initialisiert während ihr Inhalt in Release-Builds undefiniert ist.

[FunMaker]

Hatte ich auch schon überlegt aber weder bei der Initialisierung der Sterne oder Texturen noch bei der Animation werden irgendwelche Variablen nicht initialisiert auch die Oberklassen habe ich mir angeguckt. Hätte mich auch etwas gewundert das es erst ab einem bestimmten anfängt. Ich habe mir jetzt mal das Sprite was ich in den VB schreibe angeguckt, das ist auch in Ordnung. Ich werde noch einmal nen Blick auf die Anzahl an Primitiven werfen die ich aus dem VB zeichne - nicht dass er da auf irgendwelche Daten zugreift die zwar noch im Bereichs des VBs sind aber halt in dem Fall nicht beschrieben. Auch wenn ich nicht glaube dass es daran leigt weil es ja nur mit Release auftritt.

[kimmi]

Hast du das Warninglevel auf Anschlag gestellt? Da kriegt man je nach Compiler einiges an Hilfestellungen über Stellen, die als nicht sauber angesehen werden.

Gruß Kimmi

[Krishty]

Als Erstes sollte man immer D3Ds Debug-Runtime aktivieren, zur Not auch in der Release-Version.

Du liest/schreibst sicher irgendwo über eine gültige Puffergrenze hinaus. Würde hinkommen, wenn dein Vertex-Format ein Vielfaches von 12 Bytes groß ist, dann liegt das 171. Vertex gerade noch auf der Grenze einer Seite.

Vielleicht ist es aber auch ein Fencepost-Error? Irgendwo ein <, wo ein <= hingehört?

[FunMaker]

Danke für die Antworten - ich habe den Fehler gefunden auch wenn ich nicht genau weiß warum er in Debug Einstellungen nicht aufgetaucht ist und warum erst ab der entsprechenden Anzahl an Sprites. Zunächst musste ich feststellen das es das erste Sprite war was fehlerhaft angezeigt wurde - nicht das letzte.

Hiermit erzeuge ich die Indexeinträge für den Indexbuffer. 2 Dreiecke zum zeichnen des Sprites und 3 degenerierte um zum 2. Sprite zu kommen.

Code: Alles auswählen

for (int i = 0; i< 65535;i++)
{
	const int Degenerated[6] = {0,0,1,2,3,3};
	//0,1,2,3,3, 1. Sprite
	//4,4,5,6,7,7 2. Sprite
	//8,8,9,10,11,11 2. Sprite
	switch(i)
	{
	case 0: CurrentIndex = 0; break;
	case 1: CurrentIndex = 1; break;
	case 2: CurrentIndex = 2; break;
	case 3: CurrentIndex = 3; break;
	case 4: CurrentIndex = 3; break;
	default: CurrentIndex = 4 + (4 * ((i-5) / 6)) + Degenerated[(i - 5) % 6]; [color=#FF0000]break[/color];
	}

Wie ihr euch sicherlich schon denken könnt habe ich die breaks vergessen... somit waren die Indizes:

Code: Alles auswählen

-1,0,1,2,3,4,4,5,6,7,7,8,8,9,10 anstatt
0,1,2,3,3,4,4,5,6,7,7,8,8,9,10

Aber in DEBUG Einstellung müsste er doch die Breaks nicht automatisch setzen oder? Komisch ist noch das es erst ab einer gewissen Größe Probleme gab(wobei ich das noch verstehen könnte weil er dann den Index -1 mit irgendwelchen anderen Daten beschrieben hat vllt die dann zu den Problemen führten)

[Schrompf]

Im Debug-Modus umgibt die C++-Runtime alle Speicherallokationen mit einigen Sicherheitsbytes. Daher bekommst Du mit einem Arrayzugriff auf -1 im Debug verlässliche Werte, im Release dagegen liest Du zufälligen Unsinn. Das kann alle möglichen Auswirkungen haben.

Aber wo ich das gerade bei Dir sehe: Triangle Strips sind für'n Arsch, die kosten Dich nur Performance. Wenn Du sowieso einen IndexBuffer benutzt, dann benutzte lieber Standard-Dreiecke anstatt Triangle Strips oder Fans und lass alle degenerierten Zwischenflächen weg. Bei ein paar Hundert Partikeln wirst Du den Unterschied noch nicht messen können, bei mehreren zehntausend dagegen schon.

[FunMaker]

Im Debug-Modus umgibt die C++-Runtime alle Speicherallokationen mit einigen Sicherheitsbytes. Daher bekommst Du mit einem Arrayzugriff auf -1 im Debug verlässliche Werte, im Release dagegen liest Du zufälligen Unsinn. Das kann alle möglichen Auswirkungen haben.

Aber wo ich das gerade bei Dir sehe: Triangle Strips sind für'n Arsch, die kosten Dich nur Performance. Wenn Du sowieso einen IndexBuffer benutzt, dann benutzte lieber Standard-Dreiecke anstatt Triangle Strips oder Fans und lass alle degenerierten Zwischenflächen weg. Bei ein paar Hundert Partikeln wirst Du den Unterschied noch nicht messen können, bei mehreren zehntausend dagegen schon.

Gute Idee - ich hatte vorher User Pointer benutzt - da wollte ich nen bisschen schneller sein und indizierte+ Strips benutzen - so gesehen macht er das jetzt sehr unnötig :)