The same issue that affect otogi 1, also affect the first level of Magatama, with the main character and most of the texture being black or really bright yellow depending of the camera angle. It most likely stems from the same issue but I'm not sure.

After more testing I have follow-up info about these and other possible issues.

First off, stage textures. I'm going to go from least broken to most, with relevant screen shots and videos as needed.

In stages 2-6, 8-11, and 13-27 I couldn't find any missing/blackened textures.

Stage 7 (Fire Mountain) fails to properly load or display some textures but part of the level is legible. To be more specific, the enemies, wooden arches, insides of caves, torch sconces, and some patches of lava are blackened. It should be noted that the flames from the torches work, and that on other levels spider enemies display properly.

And here is a video showing how this level should look...
https://www.youtube.com/watch?v=atT-9tkA3Hg

Stages 1 and 12 are completely broken, with near everything except flames and some particle effects being blackened.

There is a stage 1 (A Peaceful Grave) screen shot in the original documentation above, but here is a video of how the level should look...
https://youtu.be/4N1jr8Y3zxk&t=237

Stage 12 (Inner Sanctum) is no better and has less torches, making it almost impossible to tell where you are at the beginning of it.

And here is a video of the level...
https://www.youtube.com/watch?v=3bZrJhKzVC0

In the course of testing the stages I also came upon some other errors, the first of which I think is related to this blackened texture issue. The stage select (not cleared stage select) is almost completely black.

The first and third videos above show the proper stage select screen that should be seen at the beginning.

The next issue I found was a "see-through" error on some platforms, mostly bridges and the stone platform in stage 22 (The Frozen Lake).

Here is a video with the stage 22 platform...
https://youtu.be/9uPW4sLMf3E&t=106

Some water textures seem to be reflecting certain lights oddly? Would have to grab a video to show this properly.

The lower skybox(?) on stage 20 (The Golden Sea) isn't displaying properly (blackened texture error?).

Stage 20 video...
https://www.youtube.com/watch?v=U0ne0Jxi8ik

And finally, the upper skybox in the final stage (27, Full Moon Rising) is broken.

Here's the video...
https://www.youtube.com/watch?v=zd87g5ehWbI

That is everything I've been able to find regarding the missing/blackened textures, as well as other issues.

Found a stage in Otogi 1 with the same blackened texture issue, stage 10 The Green Cave.
Should look like this video...

https://www.youtube.com/watch?v=fjFP0LFSJUk

Stage 19 (Golem's Ravine) of Otogi 1, which reuses the map from stage stage 10 has the blackened textures, as well as stages 22 (Lair of Fire) and 25 (Spirit Tower). On all stages mentioned very little is visible, usually projectiles and particle effects and nothing else.

Circus Maximus: Chariot Wars EC-001 [45430001]
This game displays a very similar texture error, as such I've renamed the documentation and will be putting any others games I find with this issue here.

Thanks to user JasonJaystar we now know that Galleon AT-004 [41540004] has the blackened textures on some npcs.

https://cdn.discordapp.com/attachments/680221390359888154/862136700560867328/unknown.png

Also affect Lakemasters: Bass Fishing Game menus

This also affects Trigger man

Assuming the constant values appearing in CXBXR are correct, the Otogi black character issue appears to be mis-handling of NaN.
On hw, when passed from the VS to PS, it appears +NaN becomes 1, and -NaN becomes 0.
Otogi uses -NaN in an oFog calculation - it seems like as soon as -NaN is operated on, it becomes +NaN.
The character appears to be fixed by tacking a check onto the end of the vsh.c:

"  if (!(oFog.x < 0 || oFog.x > 0 || oFog.x == 0)) { oFog.x = 1; }"

Assuming the constant values appearing in CXBXR are correct, the Otogi black character issue appears to be mis-handling of NaN. On hw, when passed from the VS to PS, it appears +NaN becomes 1, and -NaN becomes 0. Otogi uses -NaN in an oFog calculation - it seems like as soon as -NaN is operated on, it becomes +NaN. The character appears to be fixed by tacking a check onto the end of the vsh.c:

"  if (!(oFog.x < 0 || oFog.x > 0 || oFog.x == 0)) { oFog.x = 1; }"

If this is fog-component related it might be worth re-testing with PR #677 to see if there's an effect.

Testing Otogi 1 on an M1 mac w/ a build at 6f507c8 I can't immediately repro the issue (character model renders fine in the first stage and in the 3rd where I happen to have an old save), so I can't confirm whether 677 does anything or whether this bug is GPUI/driver specific.

The tests from @NZJenkins show that there are some additional nuances to the way nv2a works as compared to my GTX1070.

0 * (inf | -inf | -nan | nan) always == 0. In xemu on my particular HW, this is not the case and the exceptional value "wins" (e.g., 0 * inf = inf)

Assuming the test is correct, very small +/- fractional values also act like 0

As pointed out in #365 (comment), -NaN and NaN both seem to be converted to 1 anytime they are involved in a calculation, except in cases where they're multiplied by zero or something practically zero. Raw -NaN is treated as a 0.

There are multiple reasons why textures might appear blackened, and some of them were fixed recently. Can we please get a quick re-test of the other games mentioned here (Trigger man (Broken, NaN), Lakemasters (Broken, NaN), Galleon (Fixed), Circus Maximus (Fixed)) to see if they are resolved on master (v0.7.19) before more PRs are merged. cc @Triticum0 @Kohryujin

@mborgerson who tested lakemaster and trigger man Johngodgames? Also, I forgot to mention Drake of the 99 Dragons had this issue back in 2020 but it seemly fixed as someone retested it today.

You also did mention Magatama

Has this still not been merged? Issue is still present in the latest release?

I swear I tested Otogi on a previous official release where this issue was fixed, but on the latest version (0.7.71) the issue is preset.
However I think my memory is failing me... I definitely did however test this branch with Otogi and the issue was resolved (#913).
Hopefully this gets merged soon!

Yes, as far as I know test branches with a fix for this have been made and tested, but nothing has been merged or added into the master version yet. Nothing to do but wait or grab a test branch for now.

Hope this gets merged then asap with master, want my perfected otogi2 gameplay

The enthusiasm is nice, but please keep the discussion technical and substantive. You can show support for something in the form of a thumbs up reaction on a comment, and chat generally on the Discord server.

I've been tinkering with this - machine details:

CPU: AMD Ryzen 9 5950X 16-Core Processor            
OS_Version: Artix Linux
GL_VENDOR: AMD
GL_RENDERER: AMD Radeon RX 6900 XT (navi21, LLVM 15.0.7, DRM 3.49, 6.2.1-zen1-1-zen)
GL_VERSION: 4.6 (Core Profile) Mesa 22.3.6
GL_SHADING_LANGUAGE_VERSION: 4.60

My nxdk_pgraph_tests Float Attr output is as per the golden reference images, except all NaN columns are black.

In Otogi 1, the character is all-black in-game. Applying @NZJenkins' NaN check doesn't work on my hardware, but modifying it to the following does:

diff --git a/hw/xbox/nv2a/vsh.c b/hw/xbox/nv2a/vsh.c
index 87318419c9..c3ad53411e 100644
--- a/hw/xbox/nv2a/vsh.c
+++ b/hw/xbox/nv2a/vsh.c
@@ -859,6 +859,7 @@ void vsh_translate(uint16_t version,
              * can't multiply by W because it could be meaningless here */
         "    oPos.w = 1.0;\n"
         "  }\n"
+        "  if (oFog.x != oFog.x) { oFog.x = 1; }\n"
     );
 
 }

This is on the v0.7.84 tag (master at time of writing). I ended up going on a wild git bisect goose chase after having both non-working and working shaders retained across the wrong versions by the shader cache, so that's worth bearing in mind for anyone trying to repro. The above change should be sound in that respect - after realizing my error, I made sure to blow away ~/.local/share/xemu, build and dist before each test.

I've been tinkering with this - machine details:

CPU: AMD Ryzen 9 5950X 16-Core Processor            
OS_Version: Artix Linux
GL_VENDOR: AMD
GL_RENDERER: AMD Radeon RX 6900 XT (navi21, LLVM 15.0.7, DRM 3.49, 6.2.1-zen1-1-zen)
GL_VERSION: 4.6 (Core Profile) Mesa 22.3.6
GL_SHADING_LANGUAGE_VERSION: 4.60

My nxdk_pgraph_tests Float Attr output is as per the golden reference images, except all NaN columns are black.

In Otogi 1, the character is all-black in-game. Applying @NZJenkins' NaN check doesn't work on my hardware, but modifying it to the following does:

diff --git a/hw/xbox/nv2a/vsh.c b/hw/xbox/nv2a/vsh.c
index 87318419c9..c3ad53411e 100644
--- a/hw/xbox/nv2a/vsh.c
+++ b/hw/xbox/nv2a/vsh.c
@@ -859,6 +859,7 @@ void vsh_translate(uint16_t version,
              * can't multiply by W because it could be meaningless here */
         "    oPos.w = 1.0;\n"
         "  }\n"
+        "  if (oFog.x != oFog.x) { oFog.x = 1; }\n"
     );
 
 }

This is on the v0.7.84 tag (master at time of writing). I ended up going on a wild git bisect goose chase after having both non-working and working shaders retained across the wrong versions by the shader cache, so that's worth bearing in mind for anyone trying to repro. The above change should be sound in that respect - after realizing my error, I made sure to blow away ~/.local/share/xemu, build and dist before each test.

Did this fix the texture issues in both O1 and O2? I tried applying this when compiling my own and it didn’t seem to take. Curious if your compiled exe is sharable.

Did this fix the texture issues in both O1 and O2? I tried applying this when compiling my own and it didn’t seem to take. Curious if your compiled exe is sharable.

I don't have a copy of O2 to test with at the moment, but it fixes O1's texture issues on my machine - played up to the last few stages and had no further problems.

What OS / GPU / etc are you running? Sharing a binary is likely to confuse the issue unless you're on a comparable machine, so if pulling v0.7.84, pasting that line into vsh.c, and blowing away / disabling your texture cache doesn't work, then you've probably uncovered a new vendor-specific facet to the bug.

A good way to test is by overwriting the contents of oFog with constant values in the same place in vsh.c, ex:

oFog.x = 1;
oFog.y = 1;
oFog.z = 1;
oFog.w = 1;

If you add that in and also test with 0 instead of 1, you should be able to get some visible change during gameplay (i.e. full-bright / full-dark fogged textures). It won't be correct unless you can figure out what kind of NaN check behaves properly with your driver, but it will at least prove that oFog is working and provide a basis to work from.

Yup ....ditto would be nice to have this finally fixed

What OS / GPU / etc are you running? Sharing a binary is likely to confuse the issue unless you're on a comparable machine, so if pulling v0.7.84, pasting that line into vsh.c, and blowing away / disabling your texture cache doesn't work, then you've probably uncovered a new vendor-specific facet to the bug.

Win 11, 11900K, 3080 Ti.

Tested this today on Otogi1 with help from Kohryu. I had less visual issues than most people in the past, but this fix did resolve the entire stage being pitch black on level 10 & 19.

W10, 3950x, 3080.

@mborgerson Have the fix for the black texture for both Otogi been commited in the main branch?

Black textures still present in both Otogi 1 and 2 as of 12/12/2023

The Black textures still present for Otogi 1 and 2 on 0.7.122

But I manage to apply the patch @Shfty wrote (just one line !), re-compiled an exe for Windows, and removing the cache in /user/AppData/Roaming/xemu/xemu/
And then, the 2 games works perfectly ! :)
So the patch is still good !
I try some other games, and I see no negative change !

I do not really understand why this little fix isn't merge to master, since the time it is known.
The Otogi games are great Xbox exclusive ! These games should be played on SteamDeck ! ;)

@PukeGX Can you send me a copy of that compiled exe? I've attempted compiling my own before and wasn't exactly successful, but I'm eager to thoroughly test this build out, as well as try to examine the audio issues. I'm "realguilty" on Discord if you're willing to look me up!

The Black textures still present for Otogi 1 and 2 on 0.7.122

But I manage to apply the patch @Shfty wrote (just one line !), re-compiled an exe for Windows, and removing the cache in /user/AppData/Roaming/xemu/xemu/ And then, the 2 games works perfectly ! :) So the patch is still good ! I try some other games, and I see no negative change !

I do not really understand why this little fix isn't merge to master, since the time it is known. The Otogi games are great Xbox exclusive ! These games should be played on SteamDeck ! ;)

Can you please send me a copy of this compiled exe? Thanks!