New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Test Drive Unlimited, really slow (30%~40%) #7347
Comments
Hmm, a bezier and then immediately two prims. I wonder if we end up messing anything up after drawing a bezier? -[Unknown] |
Does turning off "Simulate block transfer" improve speed in-game? |
Turning off "Simulate block transfer",the game would be just black. |
No changes in 1.0. Direct3D9 and Auto Frameskip seems to help the game run faster but Fullspeed (100%) is not possible yet. |
Does it help the speed to set the bezier quality to "Low"? Are we increasing / should we be increasing the vaddr after drawing beziers? And by "are we?" I mean "we are not." -[Unknown] |
Low bezier did not help. |
Since #8259 |
Only at 1x? Can you log like before with that code? This is even with the fix for outside range, right? -[Unknown] |
Yes,only 1x,it's the latest build,an the log only happen at 1x
|
No compression here, so this shouldn't be a concern.
Both textures ought to be complete, I think... and no reason they wouldn't be at 1x but would at 2x+.
These should both match as well. So apparently, it's a reason outside the documentation? Or I'm wrong in the above. Hmm. I've tested and it works to do a copy from/to the same buffer (not overlapping.) Maybe these overlap... If you log src->fb_address and dst->fb_address (both -[Unknown] |
src->fb_address and dst->fb_address are the same. this is not changing resolution,and add log 2 Variables.
|
Block transfer is also broken in Sora no Kiseki HD,ikuze gensan at 1x. |
Yes, this function is used to handle block transfers. So it's blitting from itself to itself? That should simply do nothing. How does it even work at 2x? If we skip Do all of these blit with src and dst that have the same fb_address? -[Unknown] |
Yes,they are the same. |
Okay, try this: if (gstate_c.Supports(GPU_SUPPORTS_ANY_COPY_IMAGE)) {
// glBlitFramebuffer can clip, but glCopyImageSubData is more restricted.
// In case the src goes outside, we just skip the optimization in that case.
const bool sameSize = dstX2 - dstX1 == srcX2 - srcX1 && dstY2 - dstY1 == srcY2 - srcY1;
const bool srcInsideBounds = srcX2 <= src->renderWidth && srcY2 <= src->renderHeight;
const bool dstInsideBounds = dstX2 <= dst->renderWidth && dstY2 <= dst->renderHeight;
const bool xOverlap = src->fb_address == dst->fb_address && srcX2 >= dstX1 && srcX1 <= dstX2;
const bool yOverlap = src->fb_address == dst->fb_address && srcY2 >= dstY1 && srcY1 <= dstY2;
if (sameSize && srcInsideBounds && dstInsideBounds && !(xOverlap && yOverlap)) { -[Unknown] |
Yes,it works, and that Sora no Kiseki is other bug. |
Just to confirm, what about this? if (src == dst && srcX == dstX && srcY == dstY) {
// Let's just skip a copy where the destination is equal to the source.
WARN_LOG_REPORT_ONCE(blitSame, G3D, "Skipped blit with equal dst and src");
return;
}
if (gstate_c.Supports(GPU_SUPPORTS_ANY_COPY_IMAGE)) {
// glBlitFramebuffer can clip, but glCopyImageSubData is more restricted.
// In case the src goes outside, we just skip the optimization in that case.
const bool sameSize = dstX2 - dstX1 == srcX2 - srcX1 && dstY2 - dstY1 == srcY2 - srcY1;
const bool srcInsideBounds = srcX2 <= src->renderWidth && srcY2 <= src->renderHeight;
const bool dstInsideBounds = dstX2 <= dst->renderWidth && dstY2 <= dst->renderHeight;
const bool xOverlap = src == dst && srcX2 > dstX1 && srcX1 < dstX2;
const bool yOverlap = src == dst && srcY2 > dstY1 && srcY1 < dstY2;
if (sameSize && srcInsideBounds && dstInsideBounds && !(xOverlap && yOverlap)) { I realized my previous change was not checking X2/Y2 properly, and was also breaking resize blits. -[Unknown] |
Didn't work. |
So, to get back to the speed issues, I got some information on this game. I may have to refer to it as "the spawn of Sonic Rivals 2". Apparently the game does something that involves downloading slices of the active framebuffer, doing something to them, uploading those slices back... once slice at a time. I'm not clear on how many slices, but it's at least a few, and so this is painful for modern GPUs. So I guess something similar to Sonic Rivals 2, but instead of depal, block transfer. -[Unknown] |
Graphical glitches fixed in #8689 |
Just a reminder for users being linked to this issue without looking into game's thread - even if performance of the effect used in this game would be solved, it would still render at x1, so a complete removal of the effect via hack like this might overall give better experience. |
It seems this game requires simulated block transfer effects to be turned on, if you turned off simulated block transfer effects the the whole game is black screen. |
@LunaMoo what does that patch out? Although I'm generally against game specific hacks, I do support them for surgical ways to enable enhancements. I just don't like them for fixes. So in this case, maybe we could make > 1x work by default without requiring any cheats. -[Unknown] |
This game is unplayable when simulated block transfer effects is not turned on |
@unknownbrackets the effect is using DRAW PRIM RECTANGLES: count= 2 and as far as I know nothing else in this game did, so the cheat just 0's that out on boot when it's set. |
I had a look at this a while ago and I believe it may be possible to make this work at higher resolutions with reasonable performance using similar tricks like when we automatically created a copy target framebuffer in Digimon Adventures. That potential method will require some possibly game specific heuristics to size the new targets though. |
It is similar to Sonic (with the RGB depal lookups) except that instead of doing it from one framebuffer to another, it copies each tile to a small temporary space and textures from there, to save space. Fortunately at least the tiles are a lot bigger so there's not that many of them. I've got this fully working at high resolution and fast in a branch (on desktop, at least) except a stripe at the bottom of the screen, where it switches from 32x128 to 256x16 tiles but textures using the wrong one since they are from the same address in VRAM. Unfortunately the code to choose a framebuffer is a bit of a mess so I'm going to clean that up before I make a PR. |
|
Yeah it's still a heavy game, but the big performance killing problem is gone. Closing. Fixed by #13355. |
Tested this game today and seems alright, doesn't crash anymore on cutscenes, it's playable too. AdHoc also works fine.
However, the game is locked at 30% speed in the menus and 40% speed in-game, which also affect the game sound, cutscenes audio is fine. There are also a couple of minor graphical glitches on some buildings in the island and the post-processing shaders don't work for some reason, even in OpenGL Backend.
This is on v0.9.9.1-1505-gcf577e9.
The text was updated successfully, but these errors were encountered: