I don't think I'd be much good at managing a team, I've a hard enough time organising myself!
I actually spent quite a lot of time trying to get good depth values out of games recently, the reason I didn't list it as an objective right now is I'm still not convinced it's possible to implement without game specific hacks.
At the moment I can extract per-vertex depth values from the GTE, but in most games those are not in the same space for all objects in a scene and some, like sky boxes or UI elements, have no depth at all. I can also get the position of whole primitives from within the ordering table which are all in the same space but have very low precision.
The per-vertex values are fine for perspective correct texturing because all the vertices in any single primitive are transformed in the same space (except for some patch edges in GT2). This gives OpenGL the gradient it needs to scale texture coordinates on a per-pixel basis. When they're used within a scene for depth testing then the different spaces being layered up clip into one another incorrectly.
I've tried enabling depth testing with these values and in most games elements like sky boxes or background sprites will draw over everything unless disabled, which then often disables UI elements too. I managed to get Vagrant Story displaying like this (with text breaking) but a lot of the lighting and shadows used by the game involve rendering meshes multiple times with offsets which lead to z-fighting.
In most cases I know the game will be scaling and averaging all the per-vertex depth values to find the correct entry in the OT and then to sort them within that entry (bucket sorting). It's just that PGXP isn't currently smart enough to find the those values before they're discarded and associate them with the relevant primitive or vertex. I'm not even sure all games do these calculations as some, like Crash Bandicoot, have precompiled ordering tables.
I'm not going to rule it out completely but at the moment I don't have a clear idea of what would be needed to implement depth buffering and thus techniques like SSAO, it's something I'm definitely keeping in mind as I improve other aspects of PGXP though.
This sounds like you might be running out of memory for upscaled textures as it is possibly generating a new texture for each frame of the cutscene, I don't know if the plugin avoids doing this. Does it happen with normal PCSXR and the version of the Tweak plugin from Tapeq's thread?
It should be possible but it depends on how the software renderer is designed as to how easy it would be. I'd expect perspective correct texturing would require substantial changes to implement in software.
