Rpcs3: Sly 2 Continuous Bottle Crashes - BCES00968
VERSION: rpcs3-v0.0.5-7460-d56c85fe (latest master)
This issue can mainly be replicated by using the jump attack on the dinosaur skeleton/holding the main attack button
The black screen is immediate and Sly seems to be in a continuous falling state (you can tell by jump attacking, after a while you'll hear the bump)
Saving and reloading fixes this, but it makes completing the first level almost guaranteed to be impossible, and the game unplayable as a whole
rafael-57
All 55 comments
This is especially disturbing since the game looks like it might be completely playable with perfect graphics at max speed if not for this one issue
rafael-57
on 27 Oct 2018
It's a glitch that can be perfomed manually on the ps3 version of sly 2. We call it a "Bottle Crash", we don't know yet how it works, but there're some videos on yt showcasing it and how it would be helpful in speedruns.
NiV-L-A
on 27 Oct 2018
That's interesting, but this happens continuosly in the emulator, making it super hard just to clear the first room
rafael-57
on 27 Oct 2018
Ikr, it's interesting that rpcs3 forces a bottle crash in sly 2. Btw it happens throughout the whole game, not only on Cairo (the prologue)
NiV-L-A
on 27 Oct 2018
@rafael-57 Have you tried SPU LLVM with xfloat accuracy enabled? If not, give that a go.
HerrHulaHoop
on 27 Oct 2018
@HerrHulaHoop weirdly enough, the bug made the emulator crash completely with accurate xfloat
rafael-57
on 28 Oct 2018
Has anybody got a way to get around this? I've seen some people playing on further levels but I can hardly get past the first room
I've found a video on youtube: https://www.youtube.com/watch?v=z6g2HtqGPiA
rafael-57
on 25 Nov 2018
There's an ingame level-select cheat on the pause screen if you input the right buttons. That's what most people are doing. Also the issue doesn't just occur from the bottle's but it is one of the causes sure.
Asinin3
on 7 Dec 2018
Any ideas on what might fix this?
rafael-57
on 27 Feb 2019
In the log, did the emulator close after you caused the bottle crash? There are 44 errors or so before the emulator tries to shut down, 12 errors after trying to do so. I'm not a dev, but one of those surely would be related to what's happening here right? I also see multiple unloaded modules.
Osuology
on 21 Apr 2019
In the log, did the emulator close after you caused the bottle crash? There are 44 errors or so before the emulator tries to shut down, 12 errors after trying to do so. I'm not a dev, but one of those surely would be related to what's happening here right? I also see multiple unloaded modules.
As of the latest pr by Neko (the one I'm testing this with) the log is completely oblivious to the crash.
The crash seems kinda physics related but It triggers very randomly. Es. there's a high chance of getting it by jumping and attacking, or using the finishing move when sneaking on an enemy. Problem is you can very well get it when you're just walking
The other thing is that sometimes it will entirely crash the emulator (while not writing to the log), while sometimes it's completely recoverable by exiting and saving
Not really detailed since I'm not a dev, but I hope the issue gets investigated more
rafael-57
on 27 Apr 2019
It would definitely be a bottle crash then. Bottle crashes don't always crash the ps3, they can be recoverable sometimes, especially if you exit fast. It's very strange that it seems to happen everywhere on an emulator though. Hope it gets fixed soon, would be extremely nice to be able to investigate this glitch/entire game. Let me or NiV-L-A know if you need more details on bottle crashes or the game in general.
Osuology
on 27 Apr 2019
Same problem here, I tried multiple combinations on emulator settings in order to get a workaround but no luck
SZERO-1
on 28 Jul 2019
No luck on latest build
Is the cause known?
rafael-57
on 21 Oct 2019
People says that is a known bug that occurs even in the real PS3 because that is a problem from the game, but I seriously doubt it!
I've tested the PKG/ISO version on the following hardware:
PS3 Fat
PS3 Slim
PS3 Ultra Slim
After 2 Hours of straight gameplay on each console and each version I was not able to replicate this "bug".
SZERO-1
on 21 Oct 2019
Because you have to perform it manually, unlike RPCS3 which does it randomly. To perform it on real hardware, you need to use another glitch, which we call "Paraglide Clipping". Here's a video showing it: https://youtu.be/E-k3f0mTT5w - The video is mainly about "Mission Warping", which we can trigger by Bottle Crashing; so you only really need to watch the first 15 seconds of the video.
NiV-L-A
on 21 Oct 2019
So I've watched the video but since you have to perform manually on real PS3, it's a matter how RPCS3 are reproducing the code. At least is the way I see it. That glitch shows a similar bug which exists on The Crew, GTA V, Assassin's Creed... And a ton of other multi platform games that have out side of the map glitch, so I guess we can't point the problem to the game itself. More, if that was really a issue, Sony had created a patch at that time.
SZERO-1
on 21 Oct 2019
According to one of the sly 2 original devs (ps2 game), the glitch on ps3 (which he didn't worked on) it's because the ps3 is trying to emulate the MIPS of the ps2, causing the skeleton model of sly to break, or something along those lines. I think a very similar thing also happens in one of the Spyro games. It's really interesting how rpcs3 forces a BC in the game. One of the other theory is that it's a float calculation error. I looked at the sly's coords memory addresses to see what the value was when doing a BC, and they were "NaN" (Not a Number).
NiV-L-A
on 21 Oct 2019
@NiV-L-A I have to agree with the float calculation error which you mentioned. Because if non expected values are being used that can crash the graphic rendering during emulation (on my point of view). But i think that problem can be solved discarding no number or no float values.
I have to study the code a little because i didn't had the chance yet to read it properly.
SZERO-1
on 23 Oct 2019
Okay. If I may ask, the code of what?
NiV-L-A
on 23 Oct 2019
For what i understood the RSX is the GPU used by PS3 and one of the main components which RPCS3 emulates. So if some changes should be made is there, on another words, something on RSX has to be changed in order to discard this NaN values.
But as i said i need to know the architecture of RPCS3 better.
SZERO-1
on 23 Oct 2019
something on RSX has to be changed in order to discard this NaN values.
No, games rely on this behavior so we preserve it. The real PS3 GPU also preserves any NaNs. Ofc all this is about the Fragment Shader engine, its much harder to inspect the vertex processing engine, especially when it comes to positional output, since you cannot get any feedback from the hardware in such a situation if it actually generates NaN.
kd-11
on 23 Oct 2019
But in teory that NaN values are used or they just crash?
SZERO-1
on 23 Oct 2019
They're actually used. They're easy to test with a simple if (x != x) and games do rely on this behavior sometimes to detect zero in previous passes. if rcp(value) is not equal to itself, a different path is taken. The NaNs are also usually present on realhw (I don't mean in this game, just in general) and therefore should not be removed.
kd-11
on 23 Oct 2019
This bug also effects Skate 2 [BLES00461]. But it is more random. (You have to respawn repeatedly for it to occur.)
jeremybris
on 8 Nov 2019
It seems this is still producible on 0.0.8-9454. Are there any updates on research of this? The MIPS emulation causing Sly's skeleton model to break sounds like it's the best lead we have. If the skeleton breaks the physics would completely erupt, probably sending Sly somewhere far off the map. It probably explains why it is easily reproducible on the dinosaur skeleton at the beginning of the game.
Drakonas
on 29 Jan 2020
It seems this is still producible on 0.0.8-9454. Are there any updates on research of this? The MIPS emulation causing Sly's skeleton model to break sounds like it's the best lead we have. If the skeleton breaks the physics would completely erupt, probably sending Sly somewhere far off the map. It probably explains why it is easily reproducible on the dinosaur skeleton at the beginning of the game.
Once everything points to a problem with the game itself we should be able to modify the EBOOT.bin in order to mess with the MIPS Emulation. But this kind operation is out of RPCS3 scope.
SZERO-1
on 31 Jan 2020
It seems this is still producible on 0.0.8-9454. Are there any updates on research of this? The MIPS emulation causing Sly's skeleton model to break sounds like it's the best lead we have. If the skeleton breaks the physics would completely erupt, probably sending Sly somewhere far off the map. It probably explains why it is easily reproducible on the dinosaur skeleton at the beginning of the game.
Once everything points to a problem with the game itself we should be able to modify the EBOOT.bin in order to mess with the MIPS Emulation. But this kind operation is out of RPCS3 scope.
I see. Well thanks for the clarification.
Drakonas
on 31 Jan 2020
It seems this is still producible on 0.0.8-9454. Are there any updates on research of this? The MIPS emulation causing Sly's skeleton model to break sounds like it's the best lead we have. If the skeleton breaks the physics would completely erupt, probably sending Sly somewhere far off the map. It probably explains why it is easily reproducible on the dinosaur skeleton at the beginning of the game.
Once everything points to a problem with the game itself we should be able to modify the EBOOT.bin in order to mess with the MIPS Emulation. But this kind operation is out of RPCS3 scope.
I remember someone saying that the issue was fixed on PCSX2, does anybody know how?
rafael-57
on 1 Feb 2020
It seems this is still producible on 0.0.8-9454. Are there any updates on research of this? The MIPS emulation causing Sly's skeleton model to break sounds like it's the best lead we have. If the skeleton breaks the physics would completely erupt, probably sending Sly somewhere far off the map. It probably explains why it is easily reproducible on the dinosaur skeleton at the beginning of the game.
Once everything points to a problem with the game itself we should be able to modify the EBOOT.bin in order to mess with the MIPS Emulation. But this kind operation is out of RPCS3 scope.
I remember someone saying that the issue was fixed on PCSX2, does anybody know how?
What issue? Bottle crash is not present on ps2
NiV-L-A
on 1 Feb 2020
It seems this is still producible on 0.0.8-9454. Are there any updates on research of this? The MIPS emulation causing Sly's skeleton model to break sounds like it's the best lead we have. If the skeleton breaks the physics would completely erupt, probably sending Sly somewhere far off the map. It probably explains why it is easily reproducible on the dinosaur skeleton at the beginning of the game.
Once everything points to a problem with the game itself we should be able to modify the EBOOT.bin in order to mess with the MIPS Emulation. But this kind operation is out of RPCS3 scope.
I remember someone saying that the issue was fixed on PCSX2, does anybody know how?
Yeah this black screen problem this thread is talking about only happens on the PS3 version. It is nonexistent on the PS2, so I'm unsure what you're referring to.
Drakonas
on 2 Feb 2020
It seems this is still producible on 0.0.8-9454. Are there any updates on research of this? The MIPS emulation causing Sly's skeleton model to break sounds like it's the best lead we have. If the skeleton breaks the physics would completely erupt, probably sending Sly somewhere far off the map. It probably explains why it is easily reproducible on the dinosaur skeleton at the beginning of the game.
Once everything points to a problem with the game itself we should be able to modify the EBOOT.bin in order to mess with the MIPS Emulation. But this kind operation is out of RPCS3 scope.
I remember someone saying that the issue was fixed on PCSX2, does anybody know how?
Yeah this black screen problem this thread is talking about only happens on the PS3 version. It is nonexistent on the PS2, so I'm unsure what you're referring to.
Oh I see, guest I must have misremembered what I heard on some forums
rafael-57
on 2 Feb 2020
It seems this is still producible on 0.0.8-9454. Are there any updates on research of this? The MIPS emulation causing Sly's skeleton model to break sounds like it's the best lead we have. If the skeleton breaks the physics would completely erupt, probably sending Sly somewhere far off the map. It probably explains why it is easily reproducible on the dinosaur skeleton at the beginning of the game.
Once everything points to a problem with the game itself we should be able to modify the EBOOT.bin in order to mess with the MIPS Emulation. But this kind operation is out of RPCS3 scope.
I remember someone saying that the issue was fixed on PCSX2, does anybody know how?
Yeah this black screen problem this thread is talking about only happens on the PS3 version. It is nonexistent on the PS2, so I'm unsure what you're referring to.
Oh I see, guest I must have misremembered what I heard on some forums
Well, actually...Bottle Crash is possible on ps2, it just doesn't give you bottles. On the PAL and NTSC versions it can only be achieved by doing a Table Clip, tho it's very rare (again, on ps2 it doesn't give you bottles). On the Japan release of the ps2 version, tho, you can use the same technique as on ps3, and so "Paraglide Clipping" into a tight corner, but again, it doesn't give you any bottles, just a black screen. This would prove that, when Sanzaru ported sly2 on ps3, they probably grabbed the japan version, since it was released after all the other ps2 versions, and it had some fixes for some bugs.
NiV-L-A
on 2 Feb 2020
It seems this is still producible on 0.0.8-9454. Are there any updates on research of this? The MIPS emulation causing Sly's skeleton model to break sounds like it's the best lead we have. If the skeleton breaks the physics would completely erupt, probably sending Sly somewhere far off the map. It probably explains why it is easily reproducible on the dinosaur skeleton at the beginning of the game.
Once everything points to a problem with the game itself we should be able to modify the EBOOT.bin in order to mess with the MIPS Emulation. But this kind operation is out of RPCS3 scope.
In that case, who might be able to take care of it? The modding server for the PS2 games?
Mann-Nova
on 21 Feb 2020
It seems this is still producible on 0.0.8-9454. Are there any updates on research of this? The MIPS emulation causing Sly's skeleton model to break sounds like it's the best lead we have. If the skeleton breaks the physics would completely erupt, probably sending Sly somewhere far off the map. It probably explains why it is easily reproducible on the dinosaur skeleton at the beginning of the game.
Once everything points to a problem with the game itself we should be able to modify the EBOOT.bin in order to mess with the MIPS Emulation. But this kind operation is out of RPCS3 scope.
In that case, who might be able to take care of it? The modding server for the PS2 games?
Well, the patching would need to be done to the PS3 game. While the issue reportedly happened on the PS2, reproducing the same issue as what happens on PS3 isn't guaranteed to net the same results. There's too much guessing going on here. Modifying something in the emulator is one thing, but modifying a single-generation-old platform's game is a whole other beast. I had hoped this was fixable with an emulator update, but now I'm not so sure as it seems to be amplified by the already broken emulation of the PS2 data in the PS3 versions code. This means we'd have to achieve perfect emulation of the PS3 game to hope that the glitch will act the same way as an actual PS3. (In which it rarely happens except when performing the glitch manually)
Drakonas
on 21 Feb 2020
I don't know if it's a good help for the emulator developers but at least we have some more images of the Bottle Crash.
Edit: This always happen if on the Dimitri level right on the start, before the 1st level we use the (Jump + Triangle). 6-7 Bottles gets instantly broken as on the screenshot!
SZERO-1
on 21 Feb 2020
Thanks to Whatcookie and FabianPaw who developed and compiled a special build, you can play the game without these crashes:
https://drive.google.com/file/d/1a7VywZBGTvMC5jze-HpcmT0ozPnoOt6h/view
I don't understand it fully, but it improves the accuracy of vrsqrtefp, fixing some floating point variables that aren't accurate enough right now, leading to this crashes.
This doesn't work universally for both AMD and Intel, and it's still a work in progress. Perhaps you guys can test it and report it. It works for me on Windows and with an i5 7600k
(you need to clear the PPU cache to try)
rafael-57
on 2 May 2020
Thanks for sharing the information, i'm glad to see people interested solving this as i :)
Can you please tell us where to find the source code of that build ?
SZERO-1
on 2 May 2020
There is a one line changed in PPUTranslator.cpp made by Whatcookie that seems to fix this issue.
void PPUTranslator::VRSQRTEFP(ppu_opcode_t op)
{
const auto result = m_ir->CreateFDiv(ConstantVector::getSplat(4, ConstantFP::get(GetType<f32>(), 1.0)), Call(GetType<f32[4]>(), "llvm.sqrt.v4f32", GetVr(op.vb, VrType::vf)));
SetVr(op.vd, result);
}
is changed to
void PPUTranslator::VRSQRTEFP(ppu_opcode_t op)
{
SetVr(op.vd, Call(GetType<f32[4]>(), "llvm.x86.sse.rsqrt.ps", GetVr(op.vb, VrType::vf)));
}
Fabianpaw
on 2 May 2020
Also, for those that want to use the build linked above, you only need the custom build to build PPU Cache, after building the Cache with it you can play on the Master Builds again.
Fabianpaw
on 2 May 2020
Many thanks! I will compile it on my side and will test, I think 2 days is enough to complete the game and after that I will be posting the results from my side 馃槈
SZERO-1
on 2 May 2020
Played to 100% with 0 black screens, I can confirm it works!
LeParadoxHD
on 6 May 2020
Hi there,
Sorry a little bit more than just 2 days, but nevertheless i was able to finish the full game without any issue at all!
@kd-11 Can you please validate how critical is this change on the master branch ? I've tested with other games also and didn't noticed any difference despite the Sly 2 without the so called bottle crash.
The test playtrough was performed on the following way:
- For each chapter the cache was flushed in order to generate again.
- All the game was fully completed, bottle, safes, missions and trophies.
SZERO-1
on 17 May 2020
If whatcookie did not submit the code change as-is he must have a good reason for that. He is a contributor to the project, so it probably means it breaks something else otherwise it would have been in master already.
kd-11
on 17 May 2020
Would it be possible to get the custom build for Linux? Or would it somehow be possible to maybe create the PPU cache in RPCS3 under Windows, and move the cache to an installation under Linux?
Thank you!
YoakeAmai
on 18 Sep 2020
Thank you for getting this sorted out I have been able to complete a full playthrough with no crashes and running smoothly 1440p 60 fps!
https://www.youtube.com/playlist?list=PLUj-13jxI3XYVTyVzCyAiPs__uB289_9E
If you guys want to see it in action^
ThatAlexKid
on 1 Dec 2020
The "fix" doesn't work anymore, because the shader cache was renamed recently. :(
jeremybris
on 1 Dec 2020
Added the code change to master, you can grab the build for Windows or Linux here. Should work, I think
RainbowCookie32
on 1 Dec 2020
I generated a fresh PPU cache with the latest master (0.0.13-11336) and I'm still having this issue. Are you sure you added the code in? The old custom build fixes the issue, latest master doesn't.
SlyCooperReloadCoded
on 2 Dec 2020
Yup, it's there
RainbowCookie32
on 2 Dec 2020
Well I don't know what to say. Fresh PPU cache, fresh SPU cache, fresh shader cache, default settings, latest master - still getting constant bottle crashing. If I set up the old custom build, no bottle crashing.
SlyCooperReloadCoded
on 2 Dec 2020
Wait, did you use latest master, or the one I linked above? The changes are not in master itself, but rather I grabbed master and added the changes in my fork.
RainbowCookie32
on 2 Dec 2020
Whoops, I wasn't using your build. Any reason why finding a more permanent, all-inclusive solution is hard? Is it just because of the no per-game treatment strategy or something that's really hard to implement?
SlyCooperReloadCoded
on 2 Dec 2020
Someone has to figure out exactly what the game wants, while not breaking others. I've seen some cases here where results were too accurate and some games would break, it's a messy bussiness
RainbowCookie32
on 2 Dec 2020
Someone has to figure out exactly what the game wants, while not breaking others. I've seen some cases here where results were too accurate and some games would break, it's a messy bussiness
Could the more accurate calculations be enabled only with a menu setting?
The explanation could be like "Needed for Sly 2 and ..., leave off for other games"
rafael-57
on 3 Dec 2020
Related issues
xiangzhai
路
3Comments
Emulator-Team-2
路
3Comments
AniLeo
路
3Comments
AniLeo
路
3Comments
xddxd
路
3Comments
Most helpful comment
Thanks to Whatcookie and FabianPaw who developed and compiled a special build, you can play the game without these crashes:
https://drive.google.com/file/d/1a7VywZBGTvMC5jze-HpcmT0ozPnoOt6h/view
I don't understand it fully, but it improves the accuracy of vrsqrtefp, fixing some floating point variables that aren't accurate enough right now, leading to this crashes.
This doesn't work universally for both AMD and Intel, and it's still a work in progress. Perhaps you guys can test it and report it. It works for me on Windows and with an i5 7600k
(you need to clear the PPU cache to try)