Reimplement Zelda HLE #2846
Merged
Reimplement Zelda HLE #2846
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
LGTM! Ship it. |
| m_Mails.push(_Mail); | ||
| if (interrupt) | ||
| { | ||
| if (m_Mails.size() == 0) |
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
This change is meant to solve the following problem: how to translate the
following snippet to DSPHLE:
SendInterruptAndWaitRead(MAIL_A);
SendAndWaitRead(MAIL_B);
SendInterruptAndWaitRead(MAIL_C);
This should cause the following actions on the CPU side:
---> Woken up by interrupt
Reads MAIL_A
Reads MAIL_B
<--- Exits interrupt handler
---> Woken up by interrupt
Reads MAIL_C
<---
But with the current DSPHLE mail support, the following would happen because
the "AndWaitRead" part is not supported:
---> Woken up by interrupt
Reads MAIL_A
Reads MAIL_B
<--- Exits interrupt handler
[Never gets the second interrupt since it was triggered at the same time as
the first one! Misses MAIL_C.]
This changes fixes the issue by storing two values in the mail queue on the DSP
side: the value of the mail itself, and whether a read of that mail should
trigger a DSP interrupt. If nothing is in the queue yet and an interrupt is
requested, just trigger the interrupt. In the present example, the queue will
look like this:
Mail value Interrupt requested
MAIL_A No <-- Interrupt was triggered when
pushing the mail to the queue.
MAIL_B Yes
MAIL_C No
When the CPU will read MAIL_B, this will cause MailHandler to trigger the
interrupt, which will be handled by the CPU when coming back from the exception
handler. MAIL_C is then successfully read.
Push the mail at UCode boot time, not after the first update. This avoids a lot of crazy busy-looping on the CPU side while waiting for the DSP to be initialized.
Now accurate control flow for DAC. Voice rendering is not implemented yet, but framing seems correct. Not expected to work for anything than DAC UCode games.
Now renders some of the cutscene audio in Zelda TWW. Most of the work around sample sources is in a good enough state, even though it is still missing features like Dolby mixing, IIR, etc.
Also fix Windows build.
While these are not really unrecoverable errors, while Zelda HLE is in a testing / development phase it is useful to notice these "unexpected" cases (or expected without known ways to reproduce) by making them as hard as possible to ignore.
Zelda TWW magic meter works properly now.
Fixes issue 7961.
I was under the wrong impression that std::array's default constructor performed value initialization. Turns out it does not, so an array of POD will not be initialized.
Reorder some things in the source code to match the sample source definition order. Add and remove some TODOs.
Zelda Twilight Princess (GC) seems to push null words into the command buffer. The command handler in the UCode ignores initial command mails that do not have the MSB set.
Very close to the TWW version of the UCode, haven't determined any differences yet (but I'm sure that will come soon). Works well enough to reach ingame without any errors other than a few volume issues.
Just 4 different versions of the same sample source, using a different constant pattern uploaded to the DSP during command 01.
Also fix an inconsistency in the spelling of "coeffs".
SMG1 boots but quickly PanicAlerts due to an unimplemented sample source.
Now also handles PCM16, and works for longer sounds. SMG1 main menu outputs some sensible audio now, though volume seems slightly off.
MAKE_DOLBY_LOUDER solves some of the volume issues that were happening in Zelda Twilight Princess and SMG1.
Typos and stupid mistakes + untested code = dirty Git history.
…ersions. On older versions there is no such concept of a "back buffer" since positional audio is not supported. These buffers are just used for temp mixing, and while it would be really nice if we could support more of that inter-buffer mixing (TODO :) ) it does not warrant a PanicAlert at this time.
It kind of sucks that we don't emulate some behaviors properly, but there is very little ROI for some of these features and I'm not going to spend time implementing them any time soon. Making the PanicAlerts optional allows for more testing of the core features on more games while "just" breaking less important features like reverb.
Didn't test if SMS sounds right (travelling with no headphones \o/) but the waveform looks ok and the mails are flowing as expected.
On at least one version (AC/Pikmin 1 NTSC) it doesn't even send a sync mail and just reloops to the dispatcher.
Shouldn't really matter -- these NOP commands aren't really used, but since it reads an argument it's probably better to explicitly NOP it for safety.
…n light protocol, just never used.
…'t ever happen on light protocol UCodes.
…y the light protocol. Logs, but doesn't crash anymore.
…ing GBA crypto code from the separate UCode.
This time tested by comparing pattern indexes across LLE and HLE with the same inputs. Matches on the 3-4 test cases I made.
|
Yup, lgtm. |
|
LGTM code-wise (not tested) |
|
Looks good style-wise. |
| case 0x42f64ac4: // Luigi's Mansion - US | ||
| case 0x56d36052: // Super Mario Sunshine - US | ||
| case 0x6c3f6f94: // Zelda TP Wii - US | ||
| case 0xeaeb38cc: // Pikmin 1/2 New Play Control Wii - US |
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It is finally there. Now that all the priority high/critical bugs have been fixed, I think this is ready for review.
Here are the known remaining bugs:
There are two remaining bugs that only appear in "strict" mode, which don't seem to have noticeable impact on the games.
I'll let @JMC47 describe how much NZHLE fixes and improves. I don't play games so it's hard to say :)