Descriptive Problem Summary:
I sent a test project in private. The project is not doing anything terribly complex. Two users have reported the same issue:
After several minutes, sitting at the title screen, the screen freaks out and turns black.
I investigated this. There are no runtime errors, so it's not a code issue. The GPU looks like nothing happened, so it appears to still be rendering.
On my machine, it took upwards of 40 minutes for this to happen. Both other users are on low end laptops and have the problem appear within roughly 2 minutes.
I've included a test project. You can just open it and let it run. Eventually, the map element just stops updating.
Now, here's the weird part. Resize the window? You've got your rendering is right back how it was for a few more minutes before it quits again.
ID:2960774
![]() Jan 17, 11:53 pm (Edited on Jan 18, 12:28 am)
|
|||||||||||||
Resolved
| |||||||||||||
I'm running a 3060. I have a workable test case that shows that the engine cannot sustain rendering in relatively simple conditions for more than 40 minutes on even a reasonable GPU.
I hate to be a dick about this, but mid-range users are unable to use 516 in certain conditions for more than a minute or two at a time before black-screening. I was able to reproduce the issue reliably on a 3060ti. I'm sorry it's a wait, but it's absolutely a problem. |
The problem with the long wait is that it requires putting everything on hold while I wait for it to happen, and once it does happen I can't necessarily figure out where it triggered. Often debugging requires me to run an issue many times until I can catch it starting up, and then many more times while I try to solve it. So that's where I'm running into an issue.
I was kinda hoping there might be some way to speed it up by tweaking some aspect of the title screen. If it takes 40 minutes to happen on a 3060ti, it might take me upwards of an hour to trigger on a 4070. I did make an interesting discovery just now, however. When I change the menu so the faster animation is the only one that plays, I see a steady and pretty big memory leak. Big enough that Dream Seeker itself can't account for it. It's very strange. I'll see if I can get anywhere with that. |
Lummox JR resolved issue with message:
KEEP_TOGETHER groups with large boundaries were causing renderer exhaustion. This has been improved with better handling of offscreen surfaces. An additional workaround is to use BLEND_INSET_OVERLAY on any objects that are children of the group. |
Login to reply.
At a best guess, I think something might be breaking the DirectX rendering that gets fixed on resize because the window resize triggers a D3D device reset.
If you make the big green thing that wanders across the screen move a lot faster and do a lot more of the fast-moving meteors, does the problem trigger faster? Anything that might cause the problem to occur sooner would be helpful.