-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Yu-Gi-Oh! DotR Camera Bug & Possible Fixes #3200
Comments
Do any of these issues persist when using software rendering on GSdx? These all seem like core issues, but it doesn't hurt to check. |
Yes I can confirm that the issue persists through all plugins. |
Does booth the rounding and the clamping are needed? Also, try various fixes such as EE Timing hack or FPU negdiv hack. |
Rounding and Clamping are the only settings I have found that effect those animations. Changing them individually all have an effect and using combinations of the two also have their own separate effects it seems. None of the hacks had any effect on the issue. I tried combinations but some hack combos crash PCSX2. |
To add to this issue, this doesn't just happen during battles. It also happens when you view the field from a certain angle (namely along a normal vector to the playing field no matter the height; use the left analog stick to adjust the camera angle) and when certain leader abilities or card effects happen. This is usually fine, though I have found at least one case where this completely breaks an actual gameplay mechanic, albeit a somewhat obscure one. The monster card Hiro's Shadow Scout has an effect whereby: "When this card is flipped face-up, identifies an opponent's face-down cards by type (MONSTER/MAGIC/POWER-UP/TRAP)!" Instead of actually doing this, all that happens is the camera cuts to that weird skewed angle for a few seconds and then never actually shows anything. I've never used this card on an actual PS2, so it's possible it doesn't work there either, but given its not working also coincides with this graphical glitch, it seems emulator-exclusive. |
Looks like some FPU inaccuracy, but i can't find why that happen. My only idea is that is something similar to that bug: https://forums.pcsx2.net/Thread-BUG-Tales-Of-Destiny-Director-s-Cut-NTSC?pid=28417#pid28417 I made better cheat using value given by Miseru99, because his patch apply only on vsync, which is too rarely to fully fix SPS. Code for NTSC-U.
Patch compare value from f01, and set it to 0,0000010 if 0. While this is better than original patch, i found that is still incorrect. Because if you move camera UP to the limit board should be displayed in direction that your card currently is, but instead it is going to left side (really minor issue tbh.). Bad value came from 00911D90, but game use that address for many things. So i wasn't able to figure out what exactly write 0 there that is later read as float. Also, if current clamping/rounding in db was meant to fix that issue, that just make issue different, don't fix it. |
I know this is an old issue, but i was wondering what value i need to change to flip the camera to the other side, because when initiating combat it flips, i have no idea what im doing but changing the numbers around i couldnt get it to the other side, thank you |
Here's a "new" savestate from 1.7.2352 for anyone who wishes to check on this without spamming X through a new game. Like before, single press away from a sample battle. AVX2 64bit btw. |
It's also important to note that it depends on how the battle starts, if a card is on the red side and attacks to the left, it will be a different angle, if it attacks forward it will be a different angle, etc |
Somebody want to retest this on 1.7? |
I tested this a week or 2 ago and it was still broken. |
I dream in the hopes of this getting fixed, i already fixed the misaligned textures if anyone wants snip |
@Pankeko no sharing texture packs on our github or any official channels, thanks. |
I wanted to point out something I found through testing in case it might help: The tile that's being blown up facing the camera is the middle tile of the board. You can test this because the game displays your selected row and column in a light red and the selected tile in a deeper red. If you move your row and column away from the center and try this glitch, it will show you a blown-up version of that tile. If you move your row or column onto the center but aren't on the center, it will show it with a light red. Finally, if you move your row and column onto the center (i.e. move over it directly), the glitch will show a tile with a deep red. Also of note is that while the main screen displays the center tile, the icon in the bottom right just displays a zoomed-in version of the tile your cursor is currently over. |
I can confirm this is still happening on both PCSX2 on Windows 11 and AetherSX2 on Android. I know AetherSX2 is a different project, but the fact it is happening on two different emulators on two different OSes and two different architectures could help locate the source of the issue. I don't know what the two share in common that would cause the issue. It could be that the game uses some kind of technique that is either undocumented, hacky or otherwise poorly understood. Edit: This patch appears to help: According to the source: "Soo if you don't understand those codes - the first line basically checks the address 0x21FE04F0 and when it stores 0 then it allows for second code to be patched and changes it to negative very close to 0(float). The rotation of the destruction animation is at 90° to the upright, but the spinning is fixed. Seems to be an FPU related issue. The programmers may have relied on something that never let the value go to 0 or some other peculiarity. |
AetherSX2 is still based on PCSX2, so makes sense it shares the same quirks. |
I tried the Play! ps2 emulator and the same issue can be found there, it also happened on ps3 emulation greatest hits thing on later models, never tried on the OG ps3 with a disk, but on later ps3 models +it was also emulated and had the same issue, my guess would be some hardware quirk of the ps2? |
Could be a quirk or a more sensitive part of the game. |
Ah. Ok, so that won't help.
I'd say both. It wasn't unusual for console programmers of that era and earlier to rely on quirks. It's just occurred to me that if changing a 0 to a tiny value close to zero fixes the issue, it may be a zero-divide related issue |
how is this on latest nightly? :) |
Issue is still there |
Very much still there on 5381. |
Are you by chance playing the all cards mod by Clovis? because the iso has a workaround for that, as you can see by the slight tilt instead of 90 degree top down angle, the base iso still has the camera bug so the issue still persists. probably because some negative number. |
PCSX2 version:
v1.5.0-dev-3342
Description
Camera Bug:
Expected behavior - When attacking cards the camera should zoom in on both players cards, flip cards to position, slash card, play burn card(s) animation, and return cards to home position.
Current Behavior - When attacking cards the camera incorrectly zooms in on what appears to be the map but the screen is split. The animation for the card(s) incorrectly skews and burns.
The incorrect animation for attacking:
The incorrect transition to attacking:
PCSX2 options:
On default options the game will exhibit the current behavior as stated.
Setting the EE/IOP Round Mode to Positive, Clamping Mode to Extra + Preserve Sign, and/or adding a PNACH file (07AD79C9.zip) that tries to correct the angle makes the animations play almost as the expected behavior should be but still exhibits flickering. The PNACH file with flip cards upside down as a side effect.
How to reproduce the issue:
Can be reproduced on any default setting with any plugin. Here is a save state just before a card attack. (SLUS-20515 (07AD79C9).00.p2s.zip)
Just press X and the animations will play.
Last known version to work:
Has never worked properly to my knowledge.
PC specifications:
Windows 10
Intel(R) Core(TM) i5-6402P CPU @ 2.80GHz
8GB RAM
GTX 960
Hopefully this information helps patch this game in the future.
The text was updated successfully, but these errors were encountered: