| |
Glatzemann Member
Anmeldedatum: 24.07.2009 Beiträge: 3327 Wohnort: Leverkusen
|
Verfasst am: 22.07.2010, 22:08 Titel: [SOLVED] Sonderbares SpriteBatch Problem |
|
Hallo zusammen,
ich habe ein sonderbares SpriteBatch Problem mit XNA 4 und wollte mir vielleicht etwas Arbeit ersparen, weil's schon jemand kennt. Das Problem ist sonderbar, da es mit praktisch identischem Code in XNA 3.1 problemlos funktioniert. Hier erstmal der Screenshot, damit man leichter erkennen kann, worum es geht:
Der Zaun und der obere, offensichtlich fehlerhafte Bereich werden mittels SpriteBatch gerendert. Der Fehler im fehlerhaften Bereich ist, daß dort die Zauntextur verwendet wird, anscheinend mit Clamp. Der untere, 3D-Bereich wird von einem eigenständigen SpriteBatch gerendert (RenderTarget). Wenn ich den Zaun oder den fehlerhaften Bereich einzeln rendere, dann wird alles fehlerfrei angezeigt.
Den SpriteBatch starte ich mit:
| Code: |
spriteBatch.Begin(SpriteSortMode.Deferred, null, null, null, null, null, sbm);
|
aber auch ein
| Code: |
spriteBatch.Begin();
|
behebt den Fehler nicht.
Gerendert wird mit
| Code: |
if (op.operationType == RenderOperation.OperationType.SPRITE_BATCH)
{
spriteBatch.Draw(pass.Texture,
op.Center,
op.SourceRect.ToRectangle(),
op.Tint,
op.Orientation,
op.Origin,
op.Scale,
SpriteEffects.None,
0.0f);
|
Die Werte in pass.Texture, sowie in op sind auf jeden Fall korrekt, da diese aus einem vollkommen anderen Code-Bereich kommt, der sowohl unter XNA 3.1, XNA 4.0 und Silverlight gleich ist. Da bis auf XNA 4.0 alles funktioniert, schliesse ich falsche Werte in pass und op in diesem Bereich aus.
Hat jemand eine Idee, woran das liegen könnte? Ich habe bereits alle SpriteSortMode's ausprobiert, keiner bringt Besserung.
Besten Dank,
Glatzemann _________________ Twitter · YouTube · MotoX Racers
|
|
| Nach oben |
|

|
Glatzemann Member
Anmeldedatum: 24.07.2009 Beiträge: 3327 Wohnort: Leverkusen
|
Verfasst am: 22.07.2010, 22:37 Titel: |
|
Hab den Fehler gefunden und bin ziemlich verärgert über mich selbst...
Das war mal wieder ein Fehler der unnötigen Art der Stunden des Debuggens kosten kann
Problem war, daß meine Engine schön nach RenderStates, Texturwechseln usw. sortiert, so daß alles möglichst selten auftritt und schön schnell geht. Zur Unterscheidung verwende ich Hash-Werte und schreibe alles was gemacht werden muss in eine Queue. Diese Queue wird unter anderem nach Render-Pass sortiert. Die Passes werden, ganz vorbildlich, durch die ICompare-Methoden verglichen. Dabei wurde ein kleiner Fehler von mir gemacht: Ich habe nur den Index und das Parent-Objekt auf Gleichheit geprüft, nicht aber die verwendete Textur.
Warum hat das ganze jetzt in XNA 3.1 funktioniert und in 4.0 nicht?
In XNA 3.1 habe ich die beiden zu rendernden Objekte an ein Kind der Root-Scene-Node gehangen, weil ich dort bereits erweiterte Animationen mit Animationscontrollern und Physikobjekten getestet habe. Unter XNA 4.0 war ich noch nicht soweit und hatte dort beide Objekte direkt an die Root-Scene-Node gehangen. Dies führte dazu, daß das Parent-Objekt im Pass gleich war. Da der Index in diesem Fall immer 0 ist, da nur ein Pass verwendet wird, wurden beide, unterschiedlichen Passes als gleich erkannt. Dies führte dazu, daß das fehlerhafte Objekt mit den geclampten, eigenen Texturkoordinaten, aber mit der Textur des Zauns gerendert wurde. Dies führte dann zu dem "netten" fehlerhaften Bild.
Was lernt man daraus?
Hash-Werte und Comparable-Implementationen (und Equals usw.) sollten mit größter Sorgfalt implementiert werden und ausführlich getestet werden  _________________ Twitter · YouTube · MotoX Racers
|
|
| Nach oben |
|

|
|
|
|