Rpcs3: Dead Island: Overbloom effect inside buildings

[Shoegzer]

This game looks fine when the character is outdoors; however inside any building, an overbloom effect is rendered, for example:

Tested with commit 31afd046b0b9b9fc8427b14a966299a2826087cf on Linux Mint 19.1 Cinnamon x64 with kernel 4.18, NVIDIA GTX 1070M 390.116

[RainbowCookie32]

Which is apparently the issue that makes it be marked Ingame instead of Playable. No need to open an issue for an ingame title, the problem is already reported on the compatibility report. Check the compat list on the site and the reports before opening issues

[Shoegzer]

I didn't realize that was the protocol and even then, wouldn't GH be a more "official" way to track issues like this? But okay, I'll close it.

[RainbowCookie32]

Opening an issue to track each games' problems would be inconvenient imo. There are 1722 not playable games in the database after all. GitHub issues are for regressions and feature requests mostly. Compatibility entries go to the forums

[Shoegzer]

That doesn't really make any sense though - ideally I would think any issues with RPCS3 or any of its software should be reported in one place only for ease of reference and so as not to cause headaches among the devs chasing issues that have been long since resolved and not reconciled between the two sources. I understand it's been established this way and so it continues to function as such; I just don't think it's ideal.

[Asinin3]

Game issues are typically only tracked when they are a regression and the PR that broke them is known. For just general "this game doesn't work" issues simply writing that they don't work isn't very helpful for a developer since it will require investigation but there was little info provided. At the very least for graphical issues a Render Doc/RSX Capture should be provided. But graphical issues are still rarely looked into specifically unless they're a regression. The vast majority of graphical issues are fixed incidentally by other general graphical improvements which is evident by people retesting games and finding out that old issues were already fixed even though the games issues were never looked into specifically.

As Rainbow Cookie said the game was reported to have this issue on the forums already. Ani has always closed issues like this that are considered more of a compatibility report rather than an issue report due to the information provided just being a report on what's wrong and not what's causing the issue. If we allowed everyone to create issues like this it would be a nightmare, the tracker would be full of things like: "Metal Gear Solid 4 doesn't boot" or "Red Dead Redemption has low performance" And for popular games their issues are already well-known. Just by looking at the tracker you can see that some of these types of issue reports already fell through the cracks and users sometimes leave them open for a few years without updating them so they all require rechecking anyway and the users are nowhere to be found and the reports on the forum are actually more recent.

This is why I think issues should only really be opened if you can go into more specific detail. For instance if it's a crash then how to reproduce it and making sure it's not a really hard to hit race condition and providing a log file. If it's a typical crash like Vulkan Device Lost or a mem access violation then it probably shouldn't be reported since that's the symptom of the error not the cause. If it's a regression and you know it worked previously then going back to find where it broke, potentially finding the direct commit that broke it etc etc.

[Shoegzer]

Thanks for your thoughts. I understand what you're saying and the way the system works today, I'm just not convinced it's the ideal condition. In my opinion there shouldn't need to be a line drawn where some issue types are repoted in GH, while others are reported on the compatibility forum. Again the way I see it, all issues, whether they be CPU-based, GPU-based, UI-based, non-regressions, regressions, high detail, low detail, or whatever, should ideally be centrally located, reported and tracked. GH seems to me an excellent resource for this purpose for many reasons - for example it permits easy linking of one issue to another, with auto-referencing, so that common symptoms can perhaps be found and examined with greater precision. This kind of information might be useful to a dev.

I do agree with you that issues declaring nothing new (duplicates), lacking sufficient detail to prove repeatability, etc. are likely useless and should be weeded out - though again I imagine it's easier to do that in GH (just close the issue) than on the forum. That said though, I think even issues that don't have helpful information such as logs are probably still worth being tracked on GH because you never know if it may wind up being useful at some point - and there are some cases where log collection isn't even possible. If the issue does lack detail, or isn't critical, rarely looked into, not worth immediate attention, etc., then fine, deprioritize it or tag it as such - and again GH provides excellent tools to do so that are absent on the forums.

To my mind a decent end-state would involve the compatibility forum simply listing the state of the software (ingame, intro, loadable etc.), with a reference to a GH issue report that provides further details for anything that isn't "playable" or whatever you might consider issue-free ("perfect" or "beatable"?). I realize GH is intended to be a coder's resource and not a free-for-all; however I just see value in forcing the collection of issue data, major or minor, to one focal point.

Don't get me wrong, I mean no disrespect: I realize you're an active member of the team and I'm simply doing some armchair quarterbacking. I just figured some healthy debate from a fresh perspective might shake some new ideas loose. Consider this too though: I posted the issue above unaware of the rules/protocol as you mention, and as a result we've wasted time with an issue that was already known. I've certainly learned something in the process, but I'm sure I'm not the first to have gone through that.

[elad335]

Just a reminder that none of what @Asinine said is not mrntioned anywhere on the on the guidelines for issue creation and that little less than a half of current issues we are having are not a regression report.
All of what this issue needs to follow the guildelines is log and rsx capture.

[Asinin3]

Then it should be added to the guidelines. Just look at https://github.com/RPCS3/rpcs3/issues?q=is%3Aissue+label%3A%22Meta%3A+Invalid%22+is%3Aclosed and you will find tons of other issues that were marked as invalid and closed for similar reasoning. And this is there too when you make a new issue.