[Andorra] Verschwindende Lücken zwischen Sprites

[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