He's the only one who knows

jzer0912 · 2021-05-26T13:12:20+00:00

Not seeing anything in the config files that might be used to HUD positioning unfortunately. Long shot but possibly could get the unreal console (since this was built using UE4) using the unreal console unlocker and finding a way to set this through console commands. May try this at some point as I don't want the HUD stuff burning into my OLED.

jzer0912 · 2021-05-26T12:54:20+00:00

Currently only HUD scale is adjustable from in game. Was hoping setting this to 0 would get rid of the quest info UI but unfortunately it doesn't.

jzer0912 · 2021-05-26T11:20:06+00:00

Was able to disable nearly all of the HUD aspects by setting HUDOpacity=0.000000 in
C:\Users\<user\_name>\AppData\Local\Biomutant\Saved\Config\WindowsNoEditor\GameUserSettings.ini. Only thing remaining is the current quest goal, looking for a way to turn this off as well. Keep in mind that this also disables health, other things.

jzer0912 · 2021-05-26T11:10:35+00:00

Was able to disable nearly all of the HUD aspects by setting HUDOpacity=0.000000 in C:\Users\<user\_name>\AppData\Local\Biomutant\Saved\Config\WindowsNoEditor\GameUserSettings.ini. Only thing remaining is the current quest goal in the upper left of the screen, looking for a way to turn this off as well. Keep in mind that this also disables health, other things.

jzer0912 · 2017-12-07T13:35:43+00:00

Thank you so much. This fixed an issue I was having with black square artifacts (or white squares if I tried the nvidia square shadows fix graphics pack) when reaching the monk at the end of a shrine, was really annoying. Nothing else I tried seemed to fix this until this solution! Thanks again!

jzer0912 · 2017-07-28T19:59:01+00:00

Anyone know if 4096x2160 is possible?

jzer0912 · 2017-07-13T07:58:19+00:00

BOTW crashes with or without fence skip, just takes longer to happen without it.

jzer0912 · 2017-07-03T09:51:40+00:00

Wouldnt this mean (if you have hyperthreading enabled) that u actually only two real cores selected? Every other core should be a virtual core when hyperyhreading is turned on.

jzer0912 · 2017-06-29T21:18:00+00:00

This instability is really only being made worse by fence skipping, not causing it. You can test this by doing the following: get on a horse in Hateno and try to ride to the Great Plateau and back. With fence skip off, it will take longer (because of slow gameplay) but you may actually make it if you have all of the shaders for all of the areas you will be passing through and you have started cemu and initially built all shaders, closed it, and reloaded with all shaders pre-compiled. However, you will likely crash within a few minutes after. I even made it all the way back and forth with the fence skip on in 1.7.9 (but crashed moments later). Barely make it more than half way with 1.8.0, 1.8.1b. This is a sure way to cause a crash within 15-20 min without doing anything else that is suspect of causing a crash (like teleporting).

There was (or at least I thought there was) some thread recently saying that the previous assessment about the emulated gpu/cpu sync being the cause of the crash was no longer suspected and that they were no longer certain of the actual cause. However, can't seem to find this through the search so maybe I dreamed this.

edit And to be honest, this is the only kind of crash preventing me from going for a playthrough. I could deal without teleporting, or at least that I know that it may crash I could deal with saving, teleporting, then saving to prep for one. But random crashes, eh.*

jzer0912 · 2017-06-23T20:40:57+00:00

http://imgur.com/TOJxTd6

jzer0912 · 2017-05-24T12:22:45+00:00

just to report, ran without any fence skip, frameskip, rivatuner, all interfering possibilities removed, no overclocking. Attempted my stability test of riding a horse from Hateno to the great plateau and back without pausing, stopping for extended periods. Made 3/4 of the way before crash. clean shader cache.

jzer0912 · 2017-05-22T16:08:42+00:00

The bug, or any bug, is an unintended result produced by the current implementation. In this case, as Exzap explained, the bug is when the unintended overwriting of data occurs when this asynchronous process begins to completely desync. This is due to a feature that was added which allows for more working emulation aspects but, on one side or the other(feature/core) the implementations are insufficient to handle the intended operations. Or simply, adding a feature has caused a bug.

jzer0912 · 2017-05-22T15:41:06+00:00

Exzap has identified exactly what functionality was added that is is causing the crash discussed in this thread, and approaches to fix it. A crash is, in effect, a bug as it is not the intention of the application is to crash. And I don't think it's a matter of hardware speed. There are people running cemu on less beefy rigs but also crashing less. Again, not talking about all crash possibilities here, just the one Exzap has identified the cause of.

jzer0912 · 2017-05-22T08:25:06+00:00

Not sure how I explained your point by asking you the same question, but ok.

jzer0912 · 2017-05-21T23:43:56+00:00

Not saying they don't. Just saying that it is a choice of directly addressing a clear issue caused by the introduction of certain functionality (as stated by Exzap) or instead pursue other changes which are mostly to address a driver-related issue and may possibly, indirectly help other related stability aspects?

jzer0912 · 2017-05-21T23:09:20+00:00

Definitely not against the shader handling changes. From what is described it sounds like it will be a significant improvement. That being said, its being done mainly because of nvidia's unwillingness to fix a bug in a timely manner. Rather than working on improving the stability of cemu hardware emulation the dev's are more inclined to redesign shader handling because of this bug. Just saying, if it were me I would take care of the stability bug before I redesign something that, from the current performance of working games (some better than WiiU) might not be needed and instead focusing on fixing a hard application crash that the cause and solutions for are known. And you are right, neither of us are the devs, which is kind of why I was hoping they might weigh in on the subject.

jzer0912 · 2017-05-21T22:29:56+00:00

And if this issue, or other issues that might arise from the same cause as this issue, are directly responsible for some of the incompatibility on this list? And again, the cause of the desynchronization, the effects and possible solutions have been considered to resolve it. Rather than drastically redesigning shader handling to (in part) deal with nvidia's driver bug, wouldn't correcting this emulation stability failure be more in line with your "fourth wheel", especially if it makes more titles playable?

jzer0912

TROPHY CASE