Posts: 46
Threads: 0
Joined: Mar 2010
Reputation:
0
(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.
Core i5-750 @ 2.67
4GB CORSAIR XMS3
SAPPHIRE Radeon HD 5770
Posts: 195
Threads: 0
Joined: Feb 2009
Reputation:
5
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...
Posts: 110
Threads: 2
Joined: Apr 2009
Reputation:
0
Location: Russia
06-24-2010, 03:35 PM
(This post was last modified: 06-24-2010, 03:37 PM by eliot_cougar.)
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...
Posts: 195
Threads: 0
Joined: Feb 2009
Reputation:
5
If it's what I think it is, this is not going to be something you can fix.