gsdx - snowblind half screen info

[bigianb]

I had a quick look at this tonight given that Baldurs gate now plays. It would appear that the problem is scaling. Just looking at the menu screen, you have a 640 pixel wide texture that is drawn onto a 1024 wide render target texture. This is done with an x scale of 2 though, so pretty much all the right hand half is cut off. The 1024 render target (containing now the left hand side of the screen) is then rendered to the screen window with a scaling of 1/2 ... so you get the half screen effect.

I think it may be something to do with a TBW value of 20 being set in the texture along with a TW of 10 (so, one says 1280 wide and the other 640).

The hack below results in the full scene being displayed in half the window ... so, not a fix ... but at least you see the full scene. Unfortunately I don't know gsdx well enough to reason any more but hopefully this provide some info for someone more knowledgeable.

I know quite a bit about the innards of BGDA and the snowblind engine though... https://code.google.com/p/bgda-explorer/

Ian

Index: GSRendererDX.cpp
===================================================================
--- GSRendererDX.cpp (revision 5732)
+++ GSRendererDX.cpp (working copy)
@@ -186,7 +186,8 @@

GSDeviceDX::VSConstantBuffer vs_cb;

- float sx = 2.0f * rtscale.x / (rtsize.x << 4);
+ // IJB: BGDA half screen hack
+ float sx = (context->TEX0.TBW == 20 ? 2.0f : 1.0f)* rtscale.x / (rtsize.x << 4);
float sy = 2.0f * rtscale.y / (rtsize.y << 4);
float ox = (float)(int)context->XYOFFSET.OFX;
float oy = (float)(int)context->XYOFFSET.OFY;

---

I should also mention, that the following settings in gsdx.ini help illustrate the issue by dumping out the contents of the various render targets into c:\temp2

dump=1
save=1
saven=300
savez=0

[miseru99]

I'm not much usefull for fixing it, don't even have any game on this engine, but you could add yourself a key/combo to FrameForGS.cpp which will activate some custom offset screen function which you can add in GlobalCommands.cpp to center/stretch that "fixed half" as a full screen. And you would make it fully playable(well if that was the only problem;p) in fullscreen in a workaroundish way.

[refraction]

Interesting find, could help lead to a fix. Thank you

[bigianb]

Interesting find, could help lead to a fix. Thank you

Hopefully. It may of course be totally spurious, but I think the more info the better when tracking these things down. I'll keep investigating - but with a 2 week old baby and a 3 year old, quiet time is in short supply

BTW: There's a mistake in the original post - the TW of course represents 1024 and not 640 (The image data is 640 texels wide but the TW is a power of 2). The issue is the same though.

[refraction]

well fingers crossed you managed to track it down further or come up with a better hack, you will make many people happy! I don't know if any of us will have much time to see to this either.

[bigianb]

well fingers crossed you managed to track it down further or come up with a better hack, you will make many people happy! I don't know if any of us will have much time to see to this either.

I'm sure that once I figure out what gsdx is doing, the fix should not be too bad What I don't understand at the moment is the 2.0 multiplier on the scale. Can anyone shed some light on that...
The pixel shader just uses it directly, so any vertex positions > half the size of the render target will be clipped.

// Divide by 16 because vertex positions are in 12.4 fixed point format.
// Divide by rtsize to convert from texel positinos to 0 -> 1 space.
// Why multipy by 2?

float sx = 2.0f * rtscale.x / (rtsize.x << 4);

[refraction]

texture widths and height are 2*texw and 2*texh according to documentation, thats all i can think of ;p

[bigianb]

texture widths and height are 2*texw and 2*texh according to documentation, thats all i can think of ;p

I'll check the GS manual again, but I thought they were 1 << TW wide and 64 * TBW scan width. So, TW of 10 gives a width of 1 << 10, or 0x400, 1024. TBW of 20 is 64*20 ... which is 1280

[refraction]

Buffer width and texture width are 2 different things. the buffer width is multiplied by 64, texture sizes are in powers of 2.

[bigianb]

Yes, exactly what I was trying to say (in a rather more complex manner).
My point being that neither are multiplied by two as you first suggested.