This repository has been archived by the owner on Aug 30, 2021. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 31
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
First pass at setting sz flags from result reg, not result
While digging in mednafen's source code to find any clues why we have bugs in Vertical Force and a couple other titles, I noticed that many arithmetic instructions will store the result of an operation to a register, then set the sign/zero flags from the value of the register. This is subtly different than much of our code, which sets _both_ the register value and the sign/zero flags based on the result of the operations directly, without going through the target register in the case of the sign/zero flags. This has a subtle implication that whenever r0 is used as the target of an operation, regardless of what its value gets set to, the sign/zero flags would be set/cleared based on the value of the _register_ (not the result that was just stored into the register necessarily), which would mean they would always be cleared. This commit changes our logic to match this, and even affects the bugs in Vertical Force that we're trying to nail down (powerups moving on a sine wave disappear for half the sine curve, and some other similar bugs), however, it didn't fix them. Now, when they disappear, they don't come back! After further digging in mednafen's source, I found that their ops will store to a register (even r0, incorrectly overwriting its always-0 value). To compensate for this, they set r0 to 0 before each instruction. This means their logic for these flags should match what we have _without_ the changes in this commit, so I don't think this code is valid, unless I've missed yet another detail here. :) What's particularly interesting, though, is that it _did_ affect the game logic we're trying to fix in some way, so we may still be on to something here, but I'm just going to stuff this on a branch for now until we have more info. Another interesting thing; while digging I _also_ found evidence that 6bdcae8 may be correct in mednafen's source, although their code is again subtly different. They do the -0 -> 0 rounding _only when setting flags_ for fp ops, and don't change the value they store in the target register. Also, they seem to be doing it for many more ops than just cmpf.s, addf.s, and subf.s. Strange!
- Loading branch information
Showing
1 changed file
with
54 additions
and
77 deletions.
There are no files selected for viewing
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