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

Difference between RCOS output on Nugget vs original PsyQ #1569

Open
5 tasks
gustavopezzi opened this issue Feb 17, 2024 · 2 comments
Open
5 tasks

Difference between RCOS output on Nugget vs original PsyQ #1569

gustavopezzi opened this issue Feb 17, 2024 · 2 comments

Comments

@gustavopezzi
Copy link

gustavopezzi commented Feb 17, 2024

Describe the bug

The rcos in the Nugget implementation outputs different values than the rcos function in the original PsyQ 32-bit. I am including in this submission:

  • A CSV file with the values of angles comparing the different output of RCOS from Nugget and PsyQ rcos.csv
  • A .zip file with the binaries generated by both the Nugget build and the binary generated with the 32-bit PsyQ binaries.zip

Both binaries were generated using the same code. They contain a simple for-loop iterating angles from -8192 to 8192 outputting their rcos.

for (a = -8192; a <= 8192; a++) {
  printf("rcos(%d) = %d", a, rcos(a));
}

Expected behavior

I would expect the output of both functions to output be the same values given the same input.

Steps to reproduce the bug

Compile and build two projects. One using Nugget with a modern toolchain and one using Windows XP 32-bit original PsyQ.

They run the same code:

for (a = -8192; a <= 8192; a++) {
  printf("rcos(%d) = %d", a, rcos(a));
}

Operating System

Windows 11

PCSX-Redux version

This is not emulator-specific.

CPU model

Intel Core i5 8th Gen

GPU model & Drivers

Integrated/On-Board Graphics

BIOS version

OpenBIOS

Options

  • Dynarec CPU
  • 8MB
  • OpenGL GPU
  • Fastboot
  • Debugger

Iso checks

No response

Logs

No response

Additional information

Hopefully, with both binaries provided, it will be possible to disassemble and see the cosine table offsets and check what is going on.

@nicolasnoble
Copy link
Member

So this is hopefully fixed with #1557, but (1) I need to regenerate all of the libraries, (2) verify any other potential breakage, and (3) manage to get in touch with @ABelliqueux in order to republish the regenerated library files.

@ABelliqueux
Copy link
Contributor

👏 Here I am !

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

No branches or pull requests

3 participants