[Andorra] Verschwindende Lücken zwischen Sprites

[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.

[igel457]

Hm, das wäre vielleicht wirklich sinnvoll...

Edit: Hmpf, wo war der rote Kasten...
Danke für die Lösungen, ich schreibe mir das auf und werde das in Andorra 2D einarbeiten sobald ich mich wieder daran mache (so in spätestens drei Wochen)

[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.

[blackfin]

Zitat:

-0.5 ist eigentlich sehr seltsam

Mhm, warum macht das dann jeder so?
Google mal ein wenig, in den Quellcodes wird es eigentlich immer abgezogen, nicht addiert.
Das Offset steht zwar auf +0.5, aber es wird von den TexCoordinaten immer abgezogen.

Ok, hier ist die Erklärung. Es liegt am Unterschied der Koordinaten von D3D-Surfaces und -Texturen:

Zitat:

...If you are using D3DTEXF_POINT (point filtering) to filter your texture, and you video card just happens to round the texture address in the right direction, it’ll work. But it won’t necessarily on every machine, and it won’t if you use bilinear filtering.

How can you tell it’s going wrong? Use a texture the same size as your render target, and observe the top row and left column of rendered pixels. It’s easiest if you use D3DTADDRESS_WRAP texture addressing.You’ll notice they aren’t quite right.

What’s going wrong? It turns out that DirectX addresses surfaces and textures a little bit differently. With a surface, the coordinate (0,0) (not considering any viewport transforms) lies directly in the center of the top-left pixel. With a texture, on the other hand, the coordinate (0,0) lies on the top-left corner of the top-left pixel. So what happens if you map (0,0) on the surface to (0,0) on the texture? You’re actually mapping the upper-left pixel of your rendering surface to a corner of the texture shared by 4 pixels–which means you may get an even blend of the 4 pixels, or if you use point filtering your GPU will choose one of those pixels for you. If you’re lucky, it’ll be the one you want.

How to fix it? Your texture coordinates need to be offset by half a pixel, so that the top-left pixel of the surface maps to coordinate (PWidth/2, PHeight/2), where PWidth and PHeight are the relative height and width of each pixel in texture space. You can make this correction in your vertex buffer’s UV coordinates, but personally I don’t like that solution since it doesn’t automatically scale to different-sized textures. You can also use a transform matrix to move your quad left and up half a pixel in surface space...

Das heisst also, wenn man 0/0 von einer D3D-Textur auf ein D3D-Surface mappt, entstehen links und oben Lücken von einer halben Pixel Breite, da die Grafikkarte sich einen Pixel von 4 Pixeln sucht, der passt. Durch das verschieben der Text-Koordinaten in den negativen Bereich, so dass die beiden wieder direkt aufeinander liegen, stimmts dann wieder.

[Medium]

Also ich habe in meinen Shadern bisher IMMER addiert, und da es dabei oftmals um GPGPU Krams ging, wäre das schon sehr aufgefallen, wenn das verkehrt gewesen wäre . Auf gamedev.net gibts dazu eigentlich auch immer mal wieder einen Thread (ist da schon fast sowas wie unsere Floatvergleiche, die alle paar Wochen wieder mal vorbei schauen ).

Sekunde! Ich mach es im Shader! Wenn man aber eine Textur so haben will, dass der Rand genau die Pixelmitten trifft, DANN muss man von den TexCoords im eigentlichen Programmcode 0,5 abziehen! Da kann es dann aber sein, dass durch Pointsampling irgendwo in der Textur eine Versatzlinie auftaucht.
Und das würde sich mit dem Fall hier decken: Der "Sprung" (der irgendwie durch VSync gelöst wurde!?) sah aus wie ein 1px Zusammenstauchen mit Pointsampling, was bei +0,5 passierte. Mit -0,5 sollte irgendeine Zeile/Spalte gedoppelt vorkommen. Da schlägt dann wieder die Indizierung zu, nur genau anders herum: Wenn man nun vorher irgendwo die Koordinatenmaxima auf Größe-1 gesetzt hat, landet man bei (-0,5; -0,5) bis (510,5; 510,5) bei einer 512x512px Textur, obwohl es bis (511,5; 511,5) sein müsste.

[Codewalker]

Fins Änderungen klappen wunderbar. Steht der Filter noch auf Point, dann entstehen aber die Verzerrungen an den Feldkanten, die ich weiter oben auf einem Screenshot gezeigt habe. Mit der geänderten DLL kann man den Filter problemlos auf linear setzen und es sind sowohl die schwarzen Linien verschwunden als auch die Verzerrungen.
Außerdem habe ich wieder eine Menge gelernt. Danke an alle für Zeit und Mühe