Update framebuffer from memory when game manipulate framebuffer in memory(Open Season). #13326
Conversation
|
I guess this is similar case to DarkStalkers and many homebrew where we use software rendering. |
|
I've tested it on PC, and it has almost no effect on speed, but, yes, it is likely to affect low performance devices. |
|
If we can, it'd be better to hook the function that makes the change. The trouble with this change is that some games clear the screen using the CPU (which we may even hook and detect), and then draw on top. Hashing alone in that case would make the screen black. I realize the plan is to individually manage this flag for each of 1400+ games one by one. A lot of the time, games will modify and memcpy in data. We already detect this often, and many games will use the same memcpy signature. If the function that writes to VRAM fits in this category, we could hook its jr ra and upload to the GPU then. -[Unknown] |
|
@unknownbrackets The game seems to use this function to decode data, and it will call multiple times to complete the decoding. I agree that managing the flag for each games is unsatisfactory, is it better now? |
shenweip
changed the title
|
@hrydgard @unknownbrackets how about this now ? |
|
What's this func look like that you need to ignore some -[Unknown] |
|
It look like: |
|
But are those separate functions that we're just misdetecting as part of the function, or are they actually other valid exits? I'm worried that we might break an existing hook with this, since I remember at least one being a func that legitimately had two exits. But it's probably just that one and I think it was a leaf (no add sp.) -[Unknown] |
|
I think those aren't separate functions because some of them are located in front of the real exit. Um... do you mean having a func that pushes stack(has add sp) at the start of func but not pop stack(no add sp) at the exit? This is interesting, it seems likely to break the stack frame? |
|
No, I've seen cases where it does the add sp out of order when it has two exits. It's very uncommon, I just don't know if any of these hooked functions do it. I'm most worried about the simd optimized memcpys, but I think they are okay. It's likely not an issue. For clarity: out of order meaning i.e. the -[Unknown] |
|
Got it, so let's specify func exit in this case for the compatibility. |
|
@hrydgard how about this? ( allthough change need rebase) |
|
@hrydgard how about this? ( although change need rebase) |
|
Is this function called in a loop, or is it called separately? Wondering if we could combine into one upload. Also, rather than a new method on GPUCommon and using UpdateFromMemory, I recommend using Perhaps we could just do something like... static int Hook_openseason_data_decode() {
static u32 firstWritePtr = 0;
u32 curWritePtr = currentMIPS->r[MIPS_REG_A0];
u32 endPtr = currentMIPS->r[MIPS_REG_A1];
u32 writeBytes = currentMIPS->r[MIPS_REG_V0];
u32 startPtr = curWritePtr - writeBytes;
if (Memory::IsVRAMAdress(startPtr) && (firstWritePtr == 0 || startPtr < firstWritePtr)) {
firstWritePtr = startPtr;
}
if (Memory::IsVRAMAdress(endPtr) && curWritePtr == endPtr) {
gpu->PerformMemoryUpload(firstWritePtr, endPtr - firstWritePtr);
firstWritePtr = 0;
}
return 0;
}That would combine it into one upload, which should perform much better. Would that work? We wouldn't need to change any files other than Core/MIPS/MIPSAnalyst.cpp and Core/HLE/ReplaceTables.cpp this way either. No need to add extra methods when we already have code to do this for other games. -[Unknown] |
|
@unknownbrackets I don't understand what your last said.Can you make another pull request for me to test ? Thanks. |
|
Finally I figure that what is the @unknownbrackets chnage, |
Fix hrydgard#13252 original from hrydgard#13326
|
Closing in favor of #14192 . |
This will fix #13252 .Some games may write directly to PSP VRAM to update the framebuffer, but the virtual framebuffer will not be updated. Maybe the right thing to do is to use PSP VRAM instead of virtual framebuffers, but may need some refactoring.