Emulator Issues #4661
closed
New Super Mario Bros. Low FPS
Added by mavil2k over 13 years ago.
Relates to performance:
No
Relates to maintainability:
No
Description
What's the problem?
Since in the graphics plugin the efb copy options were changed "new Super Mario Bros." runs with really low FPS. Before i had stable 60FPS and now in game ~31.
Dolphin version with the problem (as it appears in the title bar, Ex.: "R
4779" or "R 6403M"):
I realized it with R7634 and in R7654 still there.
(optional) Dolphin version that does not have the problem:
Versions before R7629 seem OK.
Operating system and version:
32-bit or 64-bit:
Win 7 SP1 x64
Game ID (as it appears in game properties, Ex.: "GZ2P01" or "RSBE01"):
SMNP01
Build command-line (not on Windows):
Was the ISO a plain dump from disc, compressed and/or scrubbed?
Dumped from Disc and compressed now.
Please provide any additional information below.
This is due to the texcache rewrite merge that doesn't work vey well with NSMB Wii: the game is very slow even using only EFB to texture and furthermore with EFB copy to RAM ticked you don't see anymore the brown platforms.
I don't have slowndown with EFB to ram (but a fast PC : Phenom ii 4ghz)
Disapearing brown platform (confirmed but post 3.0 that was working) is annoying since EFB to RAM solved a glitch stated on the wiki page of NSMBW : "Blue coins will be invisible unless EFB Copies to Ram is enabled. Coins can still be collected despite being invisible. "
To confirm, I'm running a Sandy CPU,and before I could run this game with full everything (EFB>Ram, LLE, etc) and now I can barely run just EFB>Ram. Definete big performance hit and one that can hopefully be recovered.
Same problem here, Opensuse 11.4 x64, AMD Phenom II X4 955 3.2 Ghz
Issue 4776 has been merged into this issue.
- Status changed from New to Fixed
Why is this marked "fixed"?
texcache-rewrite got moved back to a branch.
Ok, that's what I suspected. But shouldn't we still track issues with these branches so issues can be investigated prior to integration into Main? I think we should merge all issues with a particular branch into a single bug for tracking. I already opened one up for new texcache rewrite issues that should should probably be merged into. Maybe these could be a practice moving forward as I assume people will be testing branches as well (they should be at least). Sorry not sure what your guy's plans are for handling all this branch stuff. :)
nope, if anything one issue for branches is enough.
Otherwise we'd need to keep track of bugs in dolphin-qt and shadercache-optimized as well and those two definitely aren't ready, yet.
Also available in: Atom
PDF