Title Name: Elder Scrolls III, The Morrowind - Game of the Year Edition (USA)

[databoose]

Title

https://xemu.app/titles/42530005/#The-Elder-Scrolls-III-Morrowind-Game-of-the-Year-Edition

Bug Description

Cannot see anything in the game, audio is fully working, and the game is still otherwise running, but there is a black overlay with red corners (presumably the red edges are supposed to be when the player takes damage?)

As far as i can tell, this bug never goes away and remains the entire game, rendering it effectively unplayable.

Steps to reproduce :

1. Start a new game
2. Skip intro with start button
3. Bug will appear

Expected Behavior

Red corners are not supposed to appear at all, the screen is supposed to fade in from black from the video intro to fully visible (it is very quick but can be seen in the video below)

OG xbox footage for reference : https://www.youtube.com/watch?v=nhP49PlN6HY&t=45s

xemu Version

0.6.1-12-ga8c73197da

System Information

OS: Ubuntu 20.04.3 LTS 64 bit
CPU : i5 10600k 4.8GHz (stock clock)
GPU : GTX 1660ti
GPU Driver : 460.91.03

Additional Context

No response

[abaire]

I think the behavior may have improved a bit since this was filed, I can see the game world being rendered with some significant artifacts (a red poly instead of what I guess is a shadow / stencil buffer behind the NPC?)

OS: Kubuntu 21.04
CPU: i7 6700K @ 4GHz
GPU: GTX 1070
GPU Driver: 470.82.00

Version: 0.6.1-33-gc8c8cacc6e
Branch: fixes_yuv_colorspace_conversion
Commit: c8c8cac
Date: Tue Nov 9 08:45:20 PM UTC 2021

[Triticum0]

Yeah shadow / stencil buffer implementation is broken in a lot of games.

[Triticum0]

@abaire I asked OP to retest it on the discord and behave hasn't change so it might be version differences causing the bug.

[databoose]

@abaire I asked OP to retest it on the discord and behave hasn't change so it might be version differences causing the bug.

Yeah, i've recompiled from the latest git commit (as of the date of this post), tested the game and still having the exact same issues as the original post, i am now using the latest nvidia driver instead of the 460 driver.previously it seemed buggy but now at least in my experience it is quite stable.

Note: I use Ubuntu Mate distro, but it's basically just ubuntu with the DE replaced, so this might be the cause but i really doubt it.

[abaire]

Thanks for the info!

It's very strange; I'm also dubious that distro would have anything to do with it. I'd expect that if there's some weird difference in dependencies it'd almost certainly be video driver (or HW)-related.

I wonder if there's some interesting timing issue with the game code itself, like perhaps my system ran slower than yours and it ended up not flashing up the screen at all so then it doesn't get stuck?

If you're interested in debugging more, compiling with DEBUG_NV2A enabled will spit out a ton of information about the commands being sent to the graphics hardware which may be useful in tracking down what's going on.

[nalabrie]

If you're interested in debugging more, compiling with DEBUG_NV2A enabled will spit out a ton of information about the commands being sent to the graphics hardware which may be useful in tracking down what's going on.

@abaire I have done this. I take it you want my xemu.log file? Here you go.
xemu.log

I booted the game and played up until the keyboard appears to enter the player name and then closed xemu. I am running Windows 10 and the bug appears the same as shown in the original post, NOT like #469 (comment). It might be worth mentioning that we are using the same GPU but my CPU is a Ryzen 5 3600X. I built xemu from commit 758e36d

[abaire]

@nalabrie thanks, unfortunately the way to get full nv2a logs changed very recently, so this log file does not contain the interesting bits.

I believe you now need to do a debug build and pass --nv2a_pgraph_method as a commandline option to enable the log messages I'd need.
(I'm not entirely sure that's the right param; I haven't synced past the trace infra change yet, but I believe https://github.com/mborgerson/xemu/pull/696/files#diff-f42aff9cf12ffc71b5fcdae9b6109e119481ab3dba66eda94f5fa8bce1a047a1 has the list of options)

Alternatively, if you sync back to a13f3f48 it'll use the old DEBUG_NV2A-gated logging.

[nalabrie]

No problem, I went back to commit a13f3f4 to be safe. The log file ended up being about 150MB so I had to upload it to Google Drive. Hopefully that has the information you're after.

https://drive.google.com/file/d/11VXcr6bJodfgrOlY14UsETtec37uUuEP/view

[nalabrie]

I'm not sure how helpful this will be but I managed to play the game blindly up until the door that leads out of the ship and into Seyda Neen. I wanted to see what would happen when loading a new area. For a split second (probably a frame or two, by my eye) the problem goes away as the area is loading then comes right back. I made a save state right before opening the door. Would it be helpful if I turned DEBUG_NV2A back on while opening the door and posting the log file again? If there is a way I can send the save state for others to test themselves then let me know.

[abaire]

I'm not sure how helpful this will be but I managed to play the game blindly up until the door that leads out of the ship and into Seyda Neen. I wanted to see what would happen when loading a new area. For a split second (probably a frame or two, by my eye) the problem goes away as the area is loading then comes right back. I made a save state right before opening the door. Would it be helpful if I turned DEBUG_NV2A back on while opening the door and posting the log file again? If there is a way I can send the save state for others to test themselves then let me know.

The log could be useful; if it's not a big hassle for you it'd be great to attach it.

I think you're actually best off syncing back to master and using the new tracing functionality as you can turn it on via the monitor (under debug) just before you do the interesting thing to keep the size down. https://www.qemu.org/docs/master/devel/tracing.html#generic-interface-and-monitor-commands has the docs on how to enable the tracing.

You'll know you have the logging enabled if it outputs things like:
nv2a: pgraph method (0): 0x97 -> 0x0b0c NV097_SET_TRANSFORM_PROGRAM+0x0c (0x2070f848)
(The nv2a: pgraph method prefix is the key here, there should be tons of different commands)

Edit: And on save states, they're not easily portable as they're saved in your xbox HDD image.

I also just double checked my disc and realized I have the NTSC Platinum Hits edition of the game, so maybe this really is specific to the GotY build and my test is invalid?

[nalabrie]

@abaire I'd love to help but commit 517e4b3 coincidentally fixed this issue entirely lmao. Good work.
https://youtu.be/I034k44W9Mo
If there is still some usefulness to going back a commit and following your instructions then let me know, I'm happy to help.

Off topic, but it looks like the water rendering is bugged. You can see it in my video during the race selection section.

[abaire]

@nalabrie Awesome, no need for the log then :) Would you mind filing a new bug for the water rendering issue? I'm also curious if #720 will have any effect on that.

Hey @mborgerson or @databoose can we close this as fixed by #599 ?

[nalabrie]

Would you mind filing a new bug for the water rendering issue?

Sure thing, I can probably have that done sometime today or tomorrow. I'll also give #720 a try.

[nalabrie]

@abaire Before I make a new bug report I have a question. First off, I merged #720 with master and that did not fix the water. I'll still file a bug report for the water issue. I might have found another bug as well but I'm unsure if this is just xemu's intended behavior so I wanted to ask before posting two bug reports. If I play the game up until I can make a proper save (not a save state), restart xemu, then I am able to load the save. But if I make a save state, save the game properly, load the save state, then all the real saves are gone. Even after restarting xemu entirely, the saves are forever missing just because I loaded a save state. Is this intended behavior or specific to Morrowind? It doesn't seem intended to me.

[abaire]

@abaire Before I make a new bug report I have a question. First off, I merged #720 with master and that did not fix the water. I'll still file a bug report for the water issue.

Sounds good, hopefully it won't be too hard to track down. I'll keep an eye out for the bug report and will see if I can repro when I'm back with my machine.

I might have found another bug as well but I'm unsure if this is just xemu's intended behavior so I wanted to ask before posting two bug reports. If I play the game up until I can make a proper save (not a save state), restart xemu, then I am able to load the save. But if I make a save state, save the game properly, load the save state, then all the real saves are gone. Even after restarting xemu entirely, the saves are forever missing just because I loaded a save state. Is this intended behavior or specific to Morrowind? It doesn't seem intended to me.

I believe this is intended behavior. Think of a save state as a snapshot of the entire machine in time. This includes files saved to the hard drive (including the game saves in E:\UDATA). When you revert to a xemu snapshot, it's more or less like anything that happened after you took the snapshot never happened at all. It should not be specific to Morrowind, I'd expect that behavior to be the same for all games (or manual FTP-ing, etc, everything).

[nalabrie]

@abaire That makes sense, I'm glad I asked you first before bothering anyone with a false bug report. The water bug report is up at #725.