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

[F3D] Material Overflow Preview Fix #335

Merged
merged 1 commit into from
May 20, 2024

Conversation

jesusyoshi54
Copy link
Collaborator

Redo of #313

Fixed the way overflow works on the color combiner.

  • Previous behavior was:
    • overflow [-0.5, 1.5) per cycle combined
  • New behavior is:
    • c overflows [-1.0, 1.0) on input
    • overflow [-0.5, 1.5) per cycle combined

On 2 cycle, the combiner doesn't actually do the special sign extension [-0.5, 1.5) on the first cycle's output unless it is for alpha compare, but since this will feed into inputs which are getting special sign extension on hardware it replicates the behavior properly.

and a response from the prev PR

to be clear,

overflow [-0.5, 1.5)

means "clamping into the [0, 1] range happens for values in range [-0.5, 1.5), values outside are not clamped properly" right? (not sure on the specifics of "not clamped properly")

Values are coming out of the combiner have a special sign extension and clamp happening at those values, you can see that from AL source here with the definition of the clamp here.

So this means the output has values clamped to [0-1), with the overflow happening on [-0.5, 1.5). Anything [1-1.5) = 1, anything [-0.5-0] = 0.

On 2 cycle, the combiner doesn't actually do the special sign extension [-0.5, 1.5) on the first cycle's output unless it is for alpha compare, but since this will feed into inputs which are getting special sign extension on hardware it replicates the behavior properly.

can you clarify what is fast64 nodes behavior and what is hardware behavior here

I'll just go over this in steps. First the actual N64:

  • Inputs receive the sign extensions they're assigned. e.g. A, B, & D get special sign extension, C gets normal one
  • First cycle goes through the normal equation, gets right shifted by 8 (so that it is a s1.15 number).
  • If there is no second cycle, this gets the special clamping described above, otherwise the number goes straight to cycle 2.
  • Second cycle's inputs get the sign extensions assigned.
  • Second cycle's output gets the special clamping.

For Fast64 both cycles use the same nodes, so the formula is as follows:

  • C input receives normal sign extension
  • Combiner equation is calculated
  • Output gets special sign extension
  • Value is clamped [0-1) heading into blender (which is just fog/no fog for fast64).

@jesusyoshi54 jesusyoshi54 added this to the v2.2.1 milestone Apr 21, 2024
Copy link
Collaborator

@Lilaa3 Lilaa3 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've seen this behavior before from constantly playing with overflow and underflow, it's nice to see an explanation and the fix aha.
The nodes are doing exactly what you described, so I will approve, I will let merging left to dragon since he discussed the pr with you first

Copy link
Contributor

@Dragorn421 Dragorn421 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice 👍
Lilaa approved some time ago so merging now

@Dragorn421 Dragorn421 merged commit 70e1e87 into Fast-64:main May 20, 2024
1 check passed
Dragorn421 added a commit that referenced this pull request May 20, 2024
Dragorn421 added a commit that referenced this pull request May 20, 2024
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

3 participants