You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Compare these two images (e.g. by opening them into two tabs and switching between those tabs):
The pixel history tab shows identical shader output for both images, but different blend results. This is because the second output alpha value differs between the two images (it's 0 in the first, and 1/255 in the second), but that's not visible in the pixel history tab. This confused me for a bit, and although in my case the output for several primitives in a row has an alpha of either 0 or 1/255, this would make debugging cases where the alpha (or color) varies more considerably.
One possible fix would be to replace the "Tex After" column with the second shader output, which would work for my case since only one primitive touches the pixel per event, but would reduce information if multiple primitives touch the same pixel in the same event. Perhaps an additional row could be added between each pair of primitives, showing the before/after colors (this could be skipped after the final primitive). An alternative fix would be to just add another column, but that might make the pixel history tab wider than it needs to be (unless that column could fit in the unused space next to the "primitive 1" text, but I'm not sure how easy something like that would be to do with Qt; I think its tables support colspan, but I'm not sure).
For context as to why Dolphin uses two alpha outputs in the first place: the GameCube/Wii only supports 6 bits of alpha data in the framebuffer (and in fact, if alpha in the framebuffer is enabled, the framebuffer only supports 6 bits for all channels, though Dolphin has an option to still use 8-bit colors), but alpha for blending still uses 8 bits (regardless of how the framebuffer is configured). Here's some of the relevant code.
Environment
RenderDoc version: 1.17
Operating System: Windows 10
Graphics API: Vulkan, but this would apply to all APIs (dual-source blending is supported by OpenGL and by D3D11, and I don't think any API supports more than two channels for blending, though maybe they support more for other purposes?)
The text was updated successfully, but these errors were encountered:
Description
Compare these two images (e.g. by opening them into two tabs and switching between those tabs):
The pixel history tab shows identical shader output for both images, but different blend results. This is because the second output alpha value differs between the two images (it's 0 in the first, and 1/255 in the second), but that's not visible in the pixel history tab. This confused me for a bit, and although in my case the output for several primitives in a row has an alpha of either 0 or 1/255, this would make debugging cases where the alpha (or color) varies more considerably.
One possible fix would be to replace the "Tex After" column with the second shader output, which would work for my case since only one primitive touches the pixel per event, but would reduce information if multiple primitives touch the same pixel in the same event. Perhaps an additional row could be added between each pair of primitives, showing the before/after colors (this could be skipped after the final primitive). An alternative fix would be to just add another column, but that might make the pixel history tab wider than it needs to be (unless that column could fit in the unused space next to the "primitive 1" text, but I'm not sure how easy something like that would be to do with Qt; I think its tables support colspan, but I'm not sure).
For context as to why Dolphin uses two alpha outputs in the first place: the GameCube/Wii only supports 6 bits of alpha data in the framebuffer (and in fact, if alpha in the framebuffer is enabled, the framebuffer only supports 6 bits for all channels, though Dolphin has an option to still use 8-bit colors), but alpha for blending still uses 8 bits (regardless of how the framebuffer is configured). Here's some of the relevant code.
Environment
The text was updated successfully, but these errors were encountered: