Blackened Texture Issues and Documentation

[Kohryujin]

Title Information

• Titles: Otogi FS-002 [46530002]

• https://xemu.app/titles/46530002/

• Titles: Otogi: Hyakki Toubatsu Emaki FS-004 [46530004]

• https://xemu.app/titles/46530004/

Bug Description

Otogi 1: The only major issue I have encountered for the first game is a failure to load the character/weapon textures properly. Instead Raikoh has some sort of shadow texture over their model.

Steps to reproduce this issue:

1. Start the game.
2. Skip any cutscenes.
3. Start any stage and observe the main character.

https://cdn.discordapp.com/attachments/680221390359888154/856388676602298368/Otogi_1_1.png https://cdn.discordapp.com/attachments/680221390359888154/856388690561204244/Otogi_1_2.png

Otogi 2: The second game has more issues, starting with major slowdown in nearly every part of the game. The menus, saving, loading, all of it is locked at 5 fps. The only thing unaffected is the stage gameplay, which has normal slowdown similar to the first game.

The other major issue is some stages not loading environment textures properly, resulting in the entire level being covered in shadow textures. This can be observed in the starting stage... https://cdn.discordapp.com/attachments/680221390359888154/856389461860810762/Otogi_2_1.png

However, some stages load properly... https://cdn.discordapp.com/attachments/680221390359888154/856389890529558548/Otogi_2_2.png So I will be doing further testing to see which stages load and which don't to find out if there is any pattern. Also note that the character/weapon texture load fail from the first game has persisted.

Steps to reproduce these issues:

1. Start a new game, you will have to go through game, sound, and controls settings, then save before beginning gameplay.
2. Note the slowdown to 5 fps during these menus and the save process.
3. Skip any cutscenes.
4. Observe the first stage.

Expected Behavior

For Otogi 1, Raikoh and his weapon(s) should obviously have their textures.

For Otogi 2, there shouldn't be any slowdown in any of the menus. The menus in Otogi 1 worked fine, and I am fairly certain the games use the same engine, so I have no idea what could have been changed between games to be causing this problem. As for the missing textures, obviously the stages should all have their textures. I am not sure why some stages work and others don't, and plan to investigate further.

Version

• Version: v0.5.4-7-ga7f3f8f212
• Last-known Working: Unknown

System Information

Field	Value
OS	Windows 10 Pro
CPU	AMD FX(tm)-8350 Eight-Core Processor
Graphics Device	Radeon RX 580
Graphics Driver	Radeon 21.4.1

[Triticum0]

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.

[Kohryujin]

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.

[Kohryujin]

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

[Kohryujin]

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.

[Kohryujin]

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.

[Kohryujin]

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

[Triticum0]

Also affect Lakemasters: Bass Fishing Game menus

[Triticum0]

This also affects Trigger man

[NZJenkins]

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; }"

[abaire]

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 6f507c80af5 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.

[abaire]

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 https://github.com/mborgerson/xemu/issues/365#issuecomment-1101321547, -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.

[mborgerson]

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

[Triticum0]

@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.

[Triticum0]

You also did mention Magatama

[kendofriendo]

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

[hooby3dfx]

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 (https://github.com/mborgerson/xemu/pull/913). Hopefully this gets merged soon!

[Kohryujin]

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.

[washingleavesandthensome23-434]

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

[mborgerson]

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.

[Shfty]

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.

[real-guilty]

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.

[Shfty]

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.

[washingleavesandthensome23-434]

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

[real-guilty]

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.

[Ameiii]

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.

[IOTech17]

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

[darkfalzx]

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

[PukeGX]

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 ! ;)

[real-guilty]

@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!

[threenator]

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!

[Romano44]

I have noticed for Otogi 1,2 status in compatibility changed to "playable" recently. While it may be technically correct as it goes beyond "start", "playable" status is also misleading because its not really playable on default build due to unresolved black textures which are big deal. This positively inflate compatibility pool with false premise. I would suggest to either deal with this long standing issue for once, or revert compatibility status of all games where it matter.

[acsexton]

If we're assuming the "Playable" tag's definition is definitive: "This title is playable, with minor issues," then I agree with @Romano44.

Looking at the test details for Otogi 1, the poster says:

compat_comments: Graphics: Everything loads in correctly, apart from your character model having no textures. Charcter model has no textures and FPS is playable, unstable but you can work around it once you get into the swing of things Playability rating: 70%

And for Otogi 2:

compat_comments: Graphics: Textures and models all good, apart from all playable characters having all black texture. Also water seems to disappear based on viewing angles Playability rating: 68%

I'm not sure if there is a mathematical guideline for determining a game's "playability rating," but in this case there seems to be an intuitive gap between a game "functioning without crashing" and a game being "playable." Occasional framerate drops alone might be a "minor issue". But we can only "see" the main character in the same way that we "see" black holes, so I would say the games are still effectively broken.

[ghyujkilop]

Furious Karting - Blackened Textures around edges. Video. Images.

[DARKMAN-1987]

Dear developer brothers, please I want all the weapons and items for the game. otogi 1+2 trainer .exe