Skip to content
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

Increase read delay cycles for Kingdom Hearts II #248

Merged
merged 1 commit into from
Apr 9, 2020
Merged

Increase read delay cycles for Kingdom Hearts II #248

merged 1 commit into from
Apr 9, 2020

Conversation

tobiasjakobi
Copy link
Contributor

@tobiasjakobi tobiasjakobi commented Apr 8, 2020

The initial version of KH2 has some timing issues with disc reads
which leads to a game lockup when entering the gummi ship menu.

A patch applied by the ee_core exists since quite some time, but
probably because of improvements to the rest of the project, the
original delay cycles count is no longer sufficient to prevent
the game from locking up.

Some bisection has shown that increasing the value from 0x100000
to 0x110000 is sufficient. For reference, a value 0x10c000 already
fails to work.

Also note that there are multiple critical transitions the game does.
One is the obvious transition from the overworld map to the gummi
menu. Another one is the transition from the gummi stage back to the
gummi menu. E.g. with a value of 0x10c000 the former one works, but
the latter fails.

All tests were done using SMB mode and the SLUS_210.05 release. It
seems plausible that the other language release suffer from the same
issues, so apply the new value to all of them.

Pull Request checklist

Note: these are not necessarily requirements

  • I reformatted the code with clang-format
  • I checked to make sure my submission worked
  • I am the author of submission or have permission from the original author
  • Requires update of the PS2SDK
  • Requires update of the gsKit
  • Others (please specify below)

Pull Request description

The initial version of KH2 has some timing issues with disc reads
which leads to a game lockup when entering the gummi ship menu.

A patch applied by the ee_core exists since quite some time, but
probably because of improvements to the rest of the project, the
original delay cycles count is no longer sufficient to prevent
the game from locking up.

Some bisection has shown that increasing the value from 0x100000
to 0x110000 is sufficient. For reference, a value 0x10c000 already
fails to work.

Also note that there are multiple critical transitions the game does.
One is the obvious transition from the overworld map to the gummi
menu. Another one is the transition from the gummi stage back to the
gummi menu. E.g. with a value of 0x10c000 the former one works, but
the latter fails.

All tests were done using SMB mode and the SLUS_210.05 release. It
seems plausible that the other language release suffer from the same
issues, so apply the new value to all of them.
@ElPatas1
Copy link
Contributor

ElPatas1 commented Apr 9, 2020

@tobiasjakobi, this changes affects only the game Kingdom Hearts II or can it affect other games?

Best regards.

@tobiasjakobi
Copy link
Contributor Author

Due to how the ee_core patch system works, this can only affect the corresponding game IDs. I'm not sure if I understand your question?

@ElPatas1
Copy link
Contributor

ElPatas1 commented Apr 9, 2020

@tobiasjakobi, i mean, the changed delay cycles it is specificic only for the Kingdom Hearts II,
not for all the games right? different games which are not Kingdom Hearts II.
From your answer y understand yes this cycles changes are only for Kingdom Hearts II.

And also, this is only tested loaded with SMB, but could it break the game when it
is loaded with the internal HDD or by USB?

Best regards.

@tobiasjakobi
Copy link
Contributor Author

Well, you should see for yourself, apply_patches() @ ee_core/src/patches:880, you only enter the switch statement if the game ID and the game mode matches. Since game mode is ALL_MODE it also affects HDD and USB mode.
However (!) the game locks up if the delay cycles count is too low. I wouldn't know about any phenomena that happens when you wait longer. Except for loading time becoming longer. We're talking about microseconds here though.

@ElPatas1
Copy link
Contributor

ElPatas1 commented Apr 9, 2020

@tobiasjakobi, thank you very much for your detailed explanation and for your work,
it is merged.

Best regards.

@ElPatas1 ElPatas1 merged commit 259246c into ps2homebrew:master Apr 9, 2020
@tobiasjakobi tobiasjakobi deleted the fixes branch April 9, 2020 13:32
Jay-Jay-OPL pushed a commit to Jay-Jay-OPL/OPL-Daily-Builds that referenced this pull request Apr 18, 2020
The initial version of KH2 has some timing issues with disc reads
which leads to a game lockup when entering the gummi ship menu.

A patch applied by the ee_core exists since quite some time, but
probably because of improvements to the rest of the project, the
original delay cycles count is no longer sufficient to prevent
the game from locking up.

Some bisection has shown that increasing the value from 0x100000
to 0x110000 is sufficient. For reference, a value 0x10c000 already
fails to work.

Also note that there are multiple critical transitions the game does.
One is the obvious transition from the overworld map to the gummi
menu. Another one is the transition from the gummi stage back to the
gummi menu. E.g. with a value of 0x10c000 the former one works, but
the latter fails.

All tests were done using SMB mode and the SLUS_210.05 release. It
seems plausible that the other language release suffer from the same
issues, so apply the new value to all of them.
AKuHAK pushed a commit that referenced this pull request Sep 30, 2021
The initial version of KH2 has some timing issues with disc reads
which leads to a game lockup when entering the gummi ship menu.

A patch applied by the ee_core exists since quite some time, but
probably because of improvements to the rest of the project, the
original delay cycles count is no longer sufficient to prevent
the game from locking up.

Some bisection has shown that increasing the value from 0x100000
to 0x110000 is sufficient. For reference, a value 0x10c000 already
fails to work.

Also note that there are multiple critical transitions the game does.
One is the obvious transition from the overworld map to the gummi
menu. Another one is the transition from the gummi stage back to the
gummi menu. E.g. with a value of 0x10c000 the former one works, but
the latter fails.

All tests were done using SMB mode and the SLUS_210.05 release. It
seems plausible that the other language release suffer from the same
issues, so apply the new value to all of them.
citronalco pushed a commit to citronalco/OPL-Daily-Builds that referenced this pull request Sep 10, 2023
The initial version of KH2 has some timing issues with disc reads
which leads to a game lockup when entering the gummi ship menu.

A patch applied by the ee_core exists since quite some time, but
probably because of improvements to the rest of the project, the
original delay cycles count is no longer sufficient to prevent
the game from locking up.

Some bisection has shown that increasing the value from 0x100000
to 0x110000 is sufficient. For reference, a value 0x10c000 already
fails to work.

Also note that there are multiple critical transitions the game does.
One is the obvious transition from the overworld map to the gummi
menu. Another one is the transition from the gummi stage back to the
gummi menu. E.g. with a value of 0x10c000 the former one works, but
the latter fails.

All tests were done using SMB mode and the SLUS_210.05 release. It
seems plausible that the other language release suffer from the same
issues, so apply the new value to all of them.
citronalco pushed a commit to citronalco/OPL-Daily-Builds that referenced this pull request Sep 10, 2023
The initial version of KH2 has some timing issues with disc reads
which leads to a game lockup when entering the gummi ship menu.

A patch applied by the ee_core exists since quite some time, but
probably because of improvements to the rest of the project, the
original delay cycles count is no longer sufficient to prevent
the game from locking up.

Some bisection has shown that increasing the value from 0x100000
to 0x110000 is sufficient. For reference, a value 0x10c000 already
fails to work.

Also note that there are multiple critical transitions the game does.
One is the obvious transition from the overworld map to the gummi
menu. Another one is the transition from the gummi stage back to the
gummi menu. E.g. with a value of 0x10c000 the former one works, but
the latter fails.

All tests were done using SMB mode and the SLUS_210.05 release. It
seems plausible that the other language release suffer from the same
issues, so apply the new value to all of them.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants