Descriptive Problem Summary:
I want to preface this report by saying that my setup is quite esoteric and is almost certainly the root cause of the problem. I don't expect this to be fixed, but I figured it can't hurt to make a report.
Due to problems with WINE, I run BYOND in a virtual machine under VirtualBox (currently version 6.1.16). This causes graphical glitches even on stable versions of Dream Seeker, but they can be fixed by reconnecting. I have yet to find any workaround for the glitches introduced by 1548.
https://i.imgur.com/vX3c2RJ.png
Numbered Steps to Reproduce Problem:
1. Grab a copy of https://filebin.net/v131tezxo9xgearb/testcase.zip?t=jcn3e1w1
2. Compile and run it
3. Click "Glitches Enabled" in the menu bar
Expected Results:
Things look normal
Actual Results:
Objects with overlays look wrong
Does the problem occur:
Every time? Or how often? Every time
In other games? Originally noticed on SS13
In other user accounts? Not tested. Clearing cache does not help
On other computers? On three VMs across two different physical machines with different graphics hardware.
When does the problem NOT occur? Unknown
Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? 514.1547
Workarounds:
Unknown
Edit 2: test case
ID:2662168
 Mar 8 2021, 3:27 am (Edited on Mar 12 2021, 6:16 pm)
|
|||||||||||||
| |||||||||||||
1549 looks exactly the same down to the pixel from what I can tell.
I'm going to try to get more details for you and hopefully put together a simple test case. My knowledge of DM is limited though. Thanks for looking into this. Edit: Setting affected objects' alpha to 254 fixes the transparent areas. However, this causes some objects to become bright, as shown in the issue you referenced. | |
Aahoen wrote:
1549 looks exactly the same down to the pixel from what I can tell. Are you certain it updated to 1549? I haven't had any reports of issues with alpha in 1549. | |
It's definitely 1549, straight from the ZIP file.
Edit: setting the alpha of the player mob does not help. | |
I guess the question now is if anyone else is having the same alpha issue, if 1549 might have missed something.
| |
Just tested this on two different VMs, still under VBox 6. One was running Windows 10 on my daily driver machine with AMD graphics. The other was running Windows 7 on a host with Intel graphics and a different distro. The issue was present in both cases.
| |
Is there any chance you could put together a simple test case and send it my way? If I end up seeing the same issue then it clearly transcends VirtualBox and I should be able to fix it.
| |
Here's a test case:
https://filebin.net/v131tezxo9xgearb/testcase.zip?t=jcn3e1w1 | |
It definitely looks like the problem is with VirtualBox itself because your test case produces no changes for me. The issue appears to be that the blend mode isn't changing when it's supposed to, so when the sprite blitter is flushed the flush isn't happening correctly.
Since this only started happening in 1548 I'll try to narrow down what might have changed, but it's gonna be a tough thing to figure out without being able to reproduce the issue on my end. I made multiple changes to the renderer but most of them were harmless, except a premultiplication issue. | |
I'm pretty sure I isolated the change that caused this problem, but the thing is it shouldn't have caused the problem and it's not a change I can revert without detriment to the render.
Specifically, I believe what's happening is that in SetBlendMode() the new blend mode is matching the old one and it's bailing out, whereas before it was calling the routines that changed blend settings whether it needed to or not. The only problem is, there is no possible way for the old and new blend mode values to match under these circumstances. VirtualBox shouldn't be capable of breaking in the way that this is breaking, so I think what must be happening is that it's breaking in a different way. It seems most likely to me that the way the graphics calls are handled is somehow different in this environment. The one change I think I can safely make is that there's a test against the current blend mode as to whether it should bother flushing the sprite blitter or not, and I see no harm in expanding that check even though the situation I'll be expanding to is one that should never have anything to flush. | |
Please let me know if there's anything I can do to help you troubleshoot. You can even remote in if necessary.
Again, thank you for looking into this. Even though it's apparently pretty broken, VirtualBox seems to be the best solution for running DS on a Free system without resorting to PCI passthrough. | |
I have a change in 514.1550 that may potentially fix this, so you can retest once I release that.
| |
This might not be fixable under VirtualBox, then. The behavior I changed that likely caused this isn't something I can reasonably revert.
However a future release moving away from the fixed function rendering pipeline might make it moot. | |
I'm getting some similar shading issues in 514.1584 with a VirtualBox Windows VM setup as well. Shadow overlays are appearing scrambled.
| |
However, some of what you're seeing appears related to id:2657357, and if that's the case then it's very likely this was resolved in 514.1549. Have you tested the new build?