GSdx
(04-14-2010, 11:42 PM)pseudonym Wrote: SOTC overbrightening is likely texture cache related.

OMG... I have ignored all the "cache" files before, because I thought, you know, it's just cache... Now I see how hackish and incomplete it is... Well, I'll try it...
Reply

Sponsored links

There seems to have a graphical bug in Xenosaga 1 with the latest beta gsdx plugin r2693.

Using dx10 hardware mode there are some parallel shadow lines, and when I switched to r2404, the lines disappeared.

The scaling of both plugin were set at 2x, and everything else is set at default with mVU off. Is it some known issue?


Attached Files Thumbnail(s)
       
AMD Athlon II 245 @ 3.55ghz, 9600GT @730mhz 1115mhz, vista sp2 32bit
Reply
(04-16-2010, 08:00 AM)CKL Wrote: There seems to have a graphical bug in Xenosaga 1 with the latest beta gsdx plugin r2693.

Using dx10 hardware mode there are some parallel shadow lines, and when I switched to r2404, the lines disappeared.

The scaling of both plugin were set at 2x, and everything else is set at default with mVU off. Is it some known issue?

It's a scaling issue. Last time I checked it was appearing/disappearing randomly so it should still be there even with 2404.
[Image: newsig.jpg]
Reply
(04-15-2010, 09:34 AM)eliot_cougar Wrote:
(04-14-2010, 11:42 PM)pseudonym Wrote: SOTC overbrightening is likely texture cache related.

OMG... I have ignored all the "cache" files before, because I thought, you know, it's just cache... Now I see how hackish and incomplete it is... Well, I'll try it...

Well... Not too much, but I've checked all the functions in there...
The Bug does not seem to be related to GSTextureCache::LookupSource or GSTextureCache::LookupTarget, or GSTextureCache::CreateSource.
it's not any of the game-specific hacks in GSTextureCache::InvalidateLocalMem,
It's not related to maxage=400 either.

It may be related to GSTextureCache::Target::Update and even more likely GSTextureCache:WackoourceMap::Add (btw, you have TODO there, that IF is triggered a lot)

I don't fully understand what each function does, I simply checked which parts of the code (especially game-specific IFs) are triggered in the Intro and Main Menu...
Reply
eliot_cougar:
Thanks for trying to get into the source of GSdx, but you have a lot of work ahead of you yet Tongue2

The Xenosaga 1 issue is indeed scaling related, so also try the GSdx hacks targeted at that.
(The offset hack fixes the problem Tongue2 )
Reply
(04-16-2010, 01:50 PM)rama Wrote: eliot_cougar:
Thanks for trying to get into the source of GSdx, but you have a lot of work ahead of you yet Tongue2

I do realize, really...
Here, first result - no bloom at all, quite dim picture...
   

At least I've found TEX0.TBP0 where the game renders it's "bloom" (well, not only)...
Reply
do u having a dark bloom problem with shaodw of colouses??
Reply
No, he does not; he's just testing a few hacks on PCSX2 source to test how's it working by himself.
Intel C2D E6550 2.33GHz ([email protected])
Corsair CM2X1024 4GB (4x1GB) DDR2 DRAM
ASUS P5K
XFX Radeon HD 5770 1GB

Running on Windows 7 Home Premium 64-bit.
Reply
(04-16-2010, 06:01 PM)k1net1cs Wrote: No, he does not; he's just testing a few hacks on PCSX2 source to test how's it working by himself.

Indeed... The only thing I found so far is how to COMPLETELY disable all bloom (and make all indoor scenes unplayable, due to "lightshaft rays" textures are black/missing too)

In the beginning of GSTextureCache::CreateSource I check for special TBP0, PSM and TBW, and then halt the function:
Code:
if ((TEX0.TBP0 == 0x02a00) && (TEX0.PSM == 0) && (TEX0.TBW == 8))
{
     return NULL;
}
Now GSDX skips 4 function calls at each frame... I didn't find any means to skip only one (bloom) call, they all have the same Regs...

PS: Good night to me... Maybe my small research will help somehow...
BTW, How does user skip hack work?.. I mean, what does that magic number mean?..
Reply
Okay, that was hard... Update on Shadow of the Colossus overbrightening bug:

I made some changes (wild guess) in gstexturecache.cpp... You can easily find this block of code... Take a look:
Code:
GSTexture* st = src->m_texture ? src->m_texture : dst->m_texture;
        if (TEX0.PSM < 48) //to prevent Z-garbage
        {
            w += 1;
            h += 1;
            printf("Modified width and height by 1. \n");
        }
        GSTexture* dt = m_renderer->m_dev->CreateRenderTarget(w, h, false);

Hardware mode, original GSDX:
   
Hardware mode, hacked RenderTarget resolution:
   
Compare to Software mode:
   

But now I have slight problems with shadows and DoF effect positioning...
Here's what I think:
It seems that SotC NEEDS thin black border around the screen (RenderTarget) which takes part in this "whole screen bloom" calculation by... hmmm... I don't know how exactly... Maybe you will be able to find correct solution...

UPDATE: Now I do this "hack" only for TEX0.TBP0 == 0x03d00
Here's the result:
   

No problems with shadows, blur, DoF or screen border... Much less overbrightening... The game looks almost fine... The only problem is Bloom misplacement, because I've added pixels to the right and bottom sides...

I think that if you manage to add black border (all four sides) to the TEX0.TBP0 == 0x03d00, the "overbrightening bug" will be fixed...

UPDATE2 (last one for today):
Those "shadow creatures" seem to be rendered in TEX0.TBP0 == 0x03d00 too... Very consistent bug I have with my Hack... But everything else seems to be fine now...
   

This hack does not seem to work in Progressive mode at all... I guess it has a bit different TBP0 to fix...
Reply




Users browsing this thread: 6 Guest(s)