Phobos-developers
Reduce floating point precision
Nightly build for this pull request:
- compiled-dll-1d1382bed3b816f232b1d493c059bdce55b938d6.zip These artifacts will expire in 90 days and will not be available for download after that time.
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.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
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
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
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?
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:
so far we don't have much odd occured when testing this. The above crashes didn't appear in later test either