Skip to content

Reduce floating point precision #1572

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

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from

Conversation

chaserli
Copy link
Contributor

@chaserli chaserli commented Mar 11, 2025

Do you really need that precision?

@chaserli chaserli added Minor Documentation is not required Needs discussion labels Mar 11, 2025
Copy link

Nightly build for this pull request:

This comment is automatic and is meant to allow guests to get latest nightly builds for this pull request without registering. It is updated on every successful build.

Copy link
Member

@Metadorius Metadorius left a comment

Choose a reason for hiding this comment

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

This just needs testing. No idea about consequences.

@Coronia
Copy link
Contributor

Coronia commented Mar 17, 2025

with nightly from this pull request we've experienced 6 crashes so far, while 4 of them are sudden quit that didn't generate anything other than debug.log. Uploaded these logs here, not sure if it's related to the floating point change

Version: MO 3.3.6 + edits for new Phobos logic testing
Fatal Errors.zip

@chaserli
Copy link
Contributor Author

This just needs testing. No idea about consequences.

I am simply asking about which /fp option to use. As far as I know, there are not a great many FP operations in the current Phobos. However, if someone intends to rewrite some low level features, it could be an important factor. Although I've been using this option over the last 2 years, I'm not sure about its potential risks. Therefore, I am raising this question in advance to see if anyone has an answer. Before that, just hold this for a while. I compiled ddraw with avx and /fp:fast to take some advantage of simd operations, yet the effect is limited because of its narrow application scope.

with nightly from this pull request we've experienced 6 crashes so far, while 4 of them are sudden quit that didn't generate anything other than debug.log. Uploaded these logs here, not sure if it's related to the floating point change

Alphaimage/blitter crashes should already be present before

@mevitar
Copy link

mevitar commented Mar 25, 2025

with nightly from this pull request we've experienced 6 crashes so far, while 4 of them are sudden quit that didn't generate anything other than debug.log. Uploaded these logs here, not sure if it's related to the floating point change

I did few games against AI and didn't encounter any crashes. Also tried MO and no crashes either (although i will still try to play the campaign more).
Perhaps those crashes are caused by ddraw.dll?

@mevitar
Copy link

mevitar commented Apr 13, 2025

SCRN 20250413-152906-00737

Had this graphical problem when loading a MO campaign save. It fixed itself only when i loaded the game again. Not sure if it's related to ddraw i'm using or because of this build.
That game also crashed to desktop when i was close to finishing the mission. Only syringle.log and debug.log were created, as except.txt got dumped into syringe.log:

250413-todesktop_b1572.zip

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants