Descriptive Problem Summary:
Its now even worse lag - only 3 layer filters will now cause my whole system to lock up
Numbered Steps to Reproduce Problem:
1. Put 3 layer filters with transforms on something
2. watch as it lags to shit
Code Snippet (if applicable) to Reproduce Problem:
https://cdn.discordapp.com/attachments/517785193365504020/ 667486976391249970/map.zip
^^ press the FUCK button, type in "3" for 3 overlays and then start moving around (every move will cause it to stick some random overlays).
Expected Results:
not lagging
Actual Results:
lagging
Does the problem occur:
Every time? Or how often?
In other games?
In other user accounts?
On other computers?
When does the problem NOT occur?
Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)
Workarounds:
use overlays
ID:2537834
![]() Jan 16 2020, 2:57 pm
|
|||||||||||||
Resolved
| |||||||||||||
I would use BLEND_SUBTRACT or BLEND_MULTIPLY since in theory those shouldn't require expanding at all (since if it's past the edges, it's transparent there and there fore those two would do nothing), but those two blend modes straight up do not display when using a layer filter if theres more than one layer filter, and even then they still somehow manage to lag things to shit while not displaying anything.
|
Even if you can't fix this specific issue could you possibly make BLEND_SUBTRACT or BLEND_MULTIPLY work properly, and have it do no expanding at all?
|
For the expanding problem I could add a clipping flag, which would take care of it. I haven't figured out the BLEND_MULTIPLY issue yet.
|
That would work great for now, since I have no need to go past the edges at the moment.
|
Although a clip feature is still planned as a feature request, I discovered a problem with bounds calculations that was causing a lot of grief in your test project for a different bug. I believe said problem is the actual cause of the issue you're seeing here, so I'm closing this report based on my fix.
|
The change I made here was to prevent the creation of temporary surfaces in situations where, even though a transform might be in use, that transform didn't stretch the overlay beyond the existing drawing area. However if your transforms do push beyond the drawing area, and each one expands it a little more, that's a potential problem. So I could see where your test would have no improvement, but I'm not sure how it'd get worse.