View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000099 | Software Renderer | [All Projects] Bug | public | 2017-01-21 17:34 | 2017-01-25 18:02 |
Reporter | InsanityBringer | ||||
Assigned To | |||||
Priority | normal | Severity | minor | Reproducibility | always |
Status | closed | Resolution | not fixable | ||
Summary | 0000099: Fuzz effect distorts more than typical | ||||
Description | In QZDoom (and later post-2.8.1 git builds of basic ZDoom before its discontinuation), fuzz distorts more than it did in the past. In the attached image, the left half shows the current effect, captured in the latest QZDoom git build (in 8-bit software, though the effect is the same in truecolor software). The right is how it looked in 2.8.1, which looks to be closer to vanilla in general. | ||||
Tags | No tags attached. | ||||
Yes - this is an issue with the multithreaded rendering. Unfortunately, I don't know of any easy way to fix it - because of the way the fuzzing works. | |
Does it help to turn multithreading off? (r_multithreading 0) | |
Okay, assuming the issue is the multithreading one, here's a technical explanation of what is happening and why it can't be fixed: The fuzz effect reads from pixels nearby in the frame buffer. For example, one frame it might read from a pixel offset (-1, -4) away. The next frame that pixel reads from offset (2, 5). And so on. For the effect to work, all pixels nearby must have been completely rendered at the point the fuzz column drawer runs - otherwise it might be reading old data from the previous frame. Multithreading in ZDoom works by splitting the work of drawing into equally sized jobs for each core. It does this by drawing the same thing on all cores, but assigning every N line to a particular core. For example, if we have 4 cores, then lines 0,4,8,12 will be drawn by core 0 and lines 1,5,9,13 will be drawn by core 1. So every 4th line will belong to a core. OpenGL works in a similar way, although the GPUs usually bin the work in blocks instead. The fuzz effect cannot read from lines that are done by other cores because it doesn't know if those cores are behind or ahead of its own rendering. This is also why the vanilla fuzz effect cannot be 100% replicated in OpenGL. What I did in QZDoom was to read only from lines belonging to the core drawing the fuzz. That creates an effect close to the original, although not entirely the same. The more cores you have, the further away from the original effect you get. With only 1 core, the effect should be identical. |
|
hmm, I had thought originally the fuzz only grabbed pixels vertically? Though I guess if your fuzz is vertical and said lines happen to be horizontal, then there's not a whole lot you can do. (ED: ok reading your description closer implies horizontal) And indeed, turning off multithreading does make it look right. I guess there's not a whole lot that can be done, then |
|
It happens also in GZDoom. | |
Date Modified | Username | Field | Change |
---|---|---|---|
2017-01-21 17:34 | InsanityBringer | New Issue | |
2017-01-21 17:34 | InsanityBringer | File Added: fuzzissue.png | |
2017-01-21 21:23 | Rachael | Status | new => confirmed |
2017-01-21 21:23 | Rachael | Note Added: 0000193 | |
2017-01-21 21:24 | dpJudas | Note Added: 0000194 | |
2017-01-21 21:47 | dpJudas | Note Added: 0000195 | |
2017-01-21 22:19 | InsanityBringer | Note Added: 0000196 | |
2017-01-21 22:22 | InsanityBringer | Note Edited: 0000196 | View Revisions |
2017-01-22 02:46 | Edward-san | Note Added: 0000198 | |
2017-01-25 18:02 | dpJudas | Assigned To | => dpJudas |
2017-01-25 18:02 | dpJudas | Status | confirmed => closed |
2017-01-25 18:02 | dpJudas | Resolution | open => not fixable |
2017-01-25 18:02 | dpJudas | Assigned To | dpJudas => |