[Andorra] Verschwindende Lücken zwischen Sprites

[Codewalker]

So, habe das Demoprojekt fertig. Du brauchst natürlich noch die DirectX- bzw. OpenGL-DLLs aus dem Andorra-Paket (und Andorra selbst um es zu kompilieren). Ansonsten müsste alles dabei sein und ich habe versucht es auf das Wesentliche zu reduzieren.

Edit: Im Form-Create ist auch eine auskommentierte Variante für die OpenGL-DLL von Andorra. Wenn ich diese nehme, dann hagelt es Speicherfehler (ohne Exception). Wäre interessant, ob ihr das auch reproduzieren könnt

[blackfin]

Ok, läuft, und ich habe die Lücken auch!

Eine Frage: Wie bekomme ich die Bilder denn aus der .ail exportiert?
Ich würde die gerne exportieren, um sie mir an den Rändern mal und wegen der Bemaßung anzusehen.
(keine Sorge, ich brauch deine Bilder nicht! )

[Codewalker]

Theoretisch mit dem Andorra ImageEditor, aber der exportiert soweit ich weiß nur BMP kein PNG mit Alphakanal. Habe die Bilder mal angehangen.
Wenn es ein Fehler in der Bemaßung wäre, ist das zwar peinlich, aber der wäre ja noch verhältnismäßig leicht zu korrigieren.

[blackfin]

*wuselwusel*

Aaaalso....irgendwie liegt das an der Konstanten "AdTextureOffset", die von Andorra in der DX3DMain.pas plötzlich beim Initialisieren auf 0.5 statt 0.0 gesetzt wird und deswegen die Texturen "unsauber" skaliert / positioniert werden (in TAdCustomImage.SetSrcRegion)

Ich hab den Grund für das 0.5 Offset noch nicht gefunden, allerdings funktioniert es bei mir, wenn ich
AdTextureOffset := 0 ; nach
SpriteEngine.Zoom := 1.0; setze, also:

Delphi-Quellcode:

procedure TEditorForm.ResizeAndorra(Sender: TObject);
{ Wird ausgelöst, wenn die größe des Fensters verändert wird. Dann muss Andorra
 neu initialisiert werden, da sonst die Darstellung verzerrt ist }
begin
  if Draw.Initialized then
  begin
    Draw.Setup2DScene;
    Draw.Restore;
    SpriteEngine.Zoom := 1.0;
    AdTextureOffset := 0 ;  // <----------- HIER!
    Center := Point(ClientOrigin.X +
      (Width div 2), ClientOrigin.Y +
      (Height div 2));
  end;
end;

Ich glaube, für die Erklärung muss Igel sich zu Wort melden, warum in der DX3DMain das Texturen-Offset auf 0,5 gesetzt wird, statt auf 0.0, ich bin auch nicht so DirectX-firm :

Delphi-Quellcode:

function TDXApplication.GetTextureOffset: single;
begin
  result := 0.5;
end;

[Codewalker]

Fin, du bist ein Genie
Eine Ergänzung habe ich noch: Das ganze behebt den Fehler nur bzw. wird überhaupt berücksichtigt, wenn der Filter der ImageList auf adPoint steht. Setzt man ihn z.B. auf linear , dann bleiben die schwarzen Linien nach wie vor.

[blackfin]

Jaaaa, da haben wir eben diese netten Filtering-Fehler
Das ist fast klar, sobald du lineare/isotropische oder anisotropische Filterung einschaltest, bekommst du die ganze Wonne der Filtering-Fehler, die auf der ersten Seite besprochen wurden

Man bekommt sie etwas "milder", wenn du eben das Clamping bei TDXBitmapTexture.SetFilter() aktivierst und die DLL neu kompilierst, allerdings sind sie so noch nicht ganz weg.
Die inoffiziellen Lösungen für so etwas lauten, entweder mit dem (nervigen) Overlapping zu arbeiten, oder aber, was in deinem Fall wohl das bessere ist, beim Rendern von Tile-Sprites die Textur-Filterung abzuschalten. Viel bringen tut dir da (bi)lineare Filterung eh nicht und anisotropische gar nichts (ausser langsameres Rendern), da du ja direkt auf die Textur in einem 90°-Winkel schaust und somit der anisotropische Filter eh nichts machen würde (er muss ja keine verzerrte Poly-Form berechnen).

[igel457]

Das mit dem Texture-Offset auf 0.5 setzen behebt eigentlich Sampling-Probleme mit der Point-Filterung, die unter anderem bei Font-Texturen sichtbar werden. Dabei bin ich eigentlich einem Tipp aus der MSDN gefolgt:
http://msdn.microsoft.com/en-us/libr...=VS.85%29.aspx

Edit: Das hier ist das Wichtigste aus dem Artikel:

Zitat von MSDN:

The best approach is to use nearest-point filtering only when necessary. When you must use it, it is recommended that you offset texture coordinates slightly from the boundary positions to avoid artifacts.

[blackfin]

Das Offset für DX3D9 gilt aber soviel ich weiss in die negative Richtung, also -0.5 statt +0.5.
Würde auch mehr Sinn machen, da negative Tex-Coordinaten ja erstmal undeifiniert sind und der Rasterizer dann wirklich bei 0 anfängt anstatt aufzurunden. Aber das übersteigt nun mein DirectX-Wissen wirklich

Edit:
Gerade ausprobiert, mit einem Offset von -0.5 wird es auch richtig gerendert.


Edit II:
Mit -0.5 geht dann auch der bilineare und der anisotropische Filter ohne Lücken!
Allerdings nur, wenn man die Textur auch noch Clamped!

Also ist die Lösung wohl denke ich mal, die DX3DMain.pas folgendermaßen zu verändern und dann die DLL neu zu klompilieren:

I.

Delphi-Quellcode:

function TDXApplication.GetTextureOffset: single;
begin
  result := -0.5;
end;

II.

Delphi-Quellcode:

procedure TDXBitmapTexture.SetFilter;
var
  f: Cardinal;
begin
  f := D3DTEXF_POINT;
  case FFilter of
    atPoint: f := D3DTEXF_POINT;
    atLinear: f := D3DTEXF_LINEAR;
    atAnisotropic: f := D3DTEXF_ANISOTROPIC;
  end;

  FParent.Direct3DDevice9.SetSamplerState(0, D3DSAMP_ADDRESSU, D3DTADDRESS_CLAMP);
  FParent.Direct3DDevice9.SetSamplerState(0, D3DSAMP_ADDRESSV, D3DTADDRESS_CLAMP);

  FParent.Direct3DDevice9.SetSamplerState(0, D3DSAMP_MAGFILTER, f);
  FParent.Direct3DDevice9.SetSamplerState(0, D3DSAMP_MINFILTER, f);

  if FHasMipMap then
    FParent.Direct3DDevice9.SetSamplerState(0, D3DSAMP_MIPFILTER, f)
  else
    FParent.Direct3DDevice9.SetSamplerState(0, D3DSAMP_MIPFILTER, D3DTEXF_NONE);

end;

Dann braucht man das AdTextureOffset := 0; nicht mehr und man kann auch bilinear oder anisotropisch filtern.

[Medium]

Der Hintergrund ist dabei der, dass bei Texturen die Koordinate (0,0) den oberen linken Rand des oberen linken Pixels (Texels) bezeichnet, und nicht wie bei Bitmaps die Mitte dieses Pixels. Texturen können ja via floats indiziert werden, und dabei landet man (wenn man die Koordinaten auf die Größe in Pixel skaliert, normal sind die ja immer 0..1) mit (X,0; Y,0) bis (X,999...; Y,999...) auf dem selben Pixel.
Mit Pointsampling ist das immer die selbe Farbe, ab linear schon nicht mehr. Dort ist dann die "eigentliche" Pixelfarbe bei (X,5; Y,5), alles drum herum wird mit den angrenzenden Pixels verrechnet. Und tada, hier ist unser Offset von 0,5.

Roter Kasten: -0.5 ist eigentlich sehr seltsam. Spekulationen: Andorra verwendet irgendwo als Koordinatenbasis (1,1) statt (0,0) (unwahrscheinlich, aber so einen macht ja jeder mal), oooder die Obergrenzen sind falsch gesetzt:
Eine Textur der Größe 512x512 hat die (skalierten) Koordinaten (0,0) bis (512,512) ABER(!) letzterer ist der unterste rechte Rand vom untersten rechten Pixel! (Genauer genommen schon so gerade eben darüber hinaus, und daher schon vom Wrapping betroffen.) Die Mitte davon wäre bei (511,5; 511,5). Macht man da also nun den beliebten Fehler die Größenangabe mit der Pixelindizierung gleichzusetzen (ein 8x8 Bitmap hat den letzten Pixel ja bei (7,7), nicht (8,8)), kann das auch ein möglicher Grund sein. Sowas passiert mir auch immer mal wieder gern.