..:: PCSX2 Forums ::..

Full Version: Shadow of the Colossus !!!
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37
(06-22-2010, 04:01 AM)Urisma Wrote: [ -> ]spiritual successor, to be more exact. They share a few common themes, but they aren't the same story line or anything.

They are officially in the same universe though, the events at the end do have a correlation with Ico.
(06-22-2010, 09:22 AM)l[Shady]l Wrote: [ -> ]Thanks for the replies everyone.
I was checking a walkthrough, and I noticed in some areas I have a very bright light while the walkthrough doesn't have that much light.
Also, the grass was greener, the colors were more apparent (looked more colorful).
Anyone knows what that could be?

P.S. The person who made the walkthrough was also emulating the game.

This is exactly what my modded GSDX is all about... You may find more on this topic in this thread several pages before...
....Looks like I'am the only person here who like this HDR-like overbloom effect Tongue
Besides - progressive scan activation causes motion blur dissapear or work incorrectly Tongue
Thanks Eliot for fixed plugins, but I'am confused a little - you have two plugins in download directory:
sotc unbloom plugin and plugin with usual name, is this plugin with reduced bloom ?
(06-23-2010, 08:11 AM)Linear Wrote: [ -> ]....Looks like I'am the only person here who like this HDR-like overbloom effect Tongue
Besides - progressive scan activation causes motion blur dissapear or work incorrectly Tongue
Thanks Eliot for fixed plugins, but I'am confused a little - you have two plugins in download directory:
sotc unbloom plugin and plugin with usual name, is this plugin with reduced bloom ?

I would like this overbloom effect too only if objects had sharp edges... Now it causes half screen being white too often...

Sotc-fixed is the old version with very hack-ish approach which causes strong offset problem and works well only in native resolution...
SotC-unbloom - completely disables bloom... Less bugged...

I personally don't like the first one... Tried to debug overbloom again yesterday, no luck... Maybe, it's somewhere in packed GIFtag processing in GSState::Transfer or in the clamping routines of GSRenderer::GetTextureMinMax
Well, I see that this bug is not caused by video plugins.... ZeroGS also suffer from this.
But can you give your modified plugin with reduced bloom and correct offset ?Smile
I remember that you made it but can't find it in your download directory....

P.S. - interesting fact:
Dolphin video plugins also suffer from overbright shading problems in some games, but only with EFB-to-texture mode.
With EFB-to-RAM (like real console) mode - everything work correctly without overbright =) I wonder if this things are related somehow...
(06-23-2010, 12:38 PM)Linear Wrote: [ -> ]Well, I see that this bug is not caused by video plugins.... ZeroGS also suffer from this.
But can you give your modified plugin with reduced bloom and correct offset ?Smile
I remember that you made it but can't find it in your download directory....

P.S. - interesting fact:
Dolphin video plugins also suffer from overbright shading problems in some games, but only with EFB-to-texture mode.
With EFB-to-RAM (like real console) mode - everything work correctly without overbright =) I wonder if this things are related somehow...

There's no such plugin... My first attempt was about adding offset intentionally... Offset hack can't do anything with that... That version with offset hack fixed was only with bloom completely disabled...

Concerning your P.S., that's an interesting idea... That's what GSDX actually does in gstexturecache when processing bloom (0x03d00)... It creates new texture, copy FB there and renders it over the top of the screen (sometimes, with wrong offset)... Introducing something like EFB-to-RAM mode in GSDX may fix both offset problems and overbright bloom...
I'll try to dig some more info about EFB-to-RAM behaviour and inform you if something comes up Smile
P.P.S. - Dolphin D3D plugins (Dx9) also have some problems with textureMIN.MAX LOD parameters emulation.
And someone said that it can be fixed with DX11 API, due to more complex and powerfull abilities of this api....
You're just talking about framebuffer access from the CPU on the gc? The GS has no such thing, it supports transfers by DMA to and from, that's all. Should currently work about as well as anything else does in gsdx (as in I know some major issues) for framebuffers and only half work for depth buffers (fixable but not what I'm currently working on, if it takes much longer I guess I'll knock that out). This probably has nothing to do with the issue however. A likely candidate is that it's simply using a certain something I'm aware of but don't want to think about because of the performance hit for emulating it and the difficulty of tracking when it needs to be emulated...
Another investigation and another result:
I've combed whole GSState.cpp... Bloom processing takes ~256 GS operations... Above all, they do not depend on the type of renderer (SW/HW)... There's no GS -> EE transfers at all (That was my first thought)... All Bloom processing goes inside GS... Next up - actual Draw routines... I may be very stubborn at times...

PS: Do anyone have "Sony GS User's Manual"... I feel a strong lack of GS knowledge... I've found some info about some Regs it have, but that's not enough...
If it's what I think it is, this is not going to be something you can fix.
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37