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

Draft
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

@Coronia
Copy link
Contributor

Coronia commented Jun 9, 2025

so far we don't have much odd occured when testing this. The above crashes didn't appear in later test either

@chaserli chaserli marked this pull request as draft June 14, 2025 16:06
@Starkku Starkku force-pushed the develop branch 2 times, most recently from b429215 to 280b1c8 Compare June 29, 2025 19:13
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