[Bug Report] Sonic Mega Collection Plus [NTSC-U]
Game renders correctly in 0.9.6 - but not in "0.9.7 r3878"
The main menus/animations all look good. Artifacts show once playing any of the games in the collection.

I've tried most of the settings in 0.9.7 - emulation settings, and GS selections and their settings. The only thing that makes 0.9.7 render correctly, it seems, is by putting EE into Interpreter mode.

The attached images show 0.9.6 on the top, and 0.9.7 on the bottom. Let me know if I can provide any more information.


Attached Files Thumbnail(s)

Sponsored links

not a valid bug report.
moved to general discussion.

does it happen in gsdx software mode too ?
CPU : AMD Ryzen 7 3800X
Mobo : Asus PRIME B450-PLUS
GPU : NVIDIA GeForce RTX 3070
RAM : 16 Go
I happens under all GS selections, using all their various individual GS config settings.

EE Interpreter mode is the only way I've found to make 0.9.7 render correctly.

Let me know if I can provide any additional information to make the bug report "valid".
# PCSX2 version: Official Beta 3878 (exhibits issue), Official v0.9.6 release (does not have issue)
# CPU options: Tried all of them, EE Interpreter mode causes correct rendering under 0.9.7
# Plugins used: All GS plugins, and their various settings, exhibit the issue under 0.9.7
# Description: Vertical artifacts as seen in captures.

The break in this game occurs at r2694 of iR5900Arit.cpp

Hopefully, devs that are familiar with that code can re-review the changes and fix my Sonic Sega classics Smile

Let me know if I can provide any more info - or try-out any iR5900Arit.cpp changes on the game.

I found the problem and a fix for it.
The bug is in void recXOR_(int) :
void recXOR_(int info)
    pxAssert( !(info & PROCESS_EE_XMM) );

    int rs = _Rs_, rt = _Rt_;
    if (_Rd_ == _Rt_)
        rs = _Rt_, rt = _Rs_;

    for (int i = 0; i < 2; i++) {
        if (rs == rt) {
//          oops, only 32 of 64 bits zero'd out
//          xMOV(ptr32[&cpuRegs.GPR.r[_Rd_]], 0);
            xMOV(ptr32[&cpuRegs.GPR.r[_Rd_].UL[i]], 0);
        } else if (_Rd_ == rs) {
            xMOV(eax, ptr32[&cpuRegs.GPR.r[rt].UL[i]]);
            xXOR(ptr32[&cpuRegs.GPR.r[_Rd_].UL[i]], eax);
        } else {
            xMOV(eax, ptr32[&cpuRegs.GPR.r[rs].UL[i]]);
            xXOR(eax, ptr32[&cpuRegs.GPR.r[rt].UL[i]]);
            xMOV(ptr32[&cpuRegs.GPR.r[_Rd_].UL[i]], eax);
One line fix:
// oops, only 32 of 64 bits zero'd out
//xMOV(ptr32[&cpuRegs.GPR.r[_Rd_]], 0);

xMOV(ptr32[&cpuRegs.GPR.r[_Rd_].UL[i]], 0);

Using XOR to zero out a register must not be that common....but hopefully it'll fix some other games too.

Just a little too late Tongue

[Image: ref_sig_anim.gif?ex=65f40671&is=65e19171...551a681a&=]

Nice! I think we did something similar ... I merged back in all the original code under compiler directives, turned them on one by one until recXOR_() proved to be the problem child Smile

Keep up the good work!

Alright, closed then.
Core i5 3570k -- Geforce GTX 670  --  Windows 7 x64

Users browsing this thread: 2 Guest(s)