Madden NFL 13 [PCSE00084]

App summary

App name: Madden NFL 13
App serial: PCSE00084
App version: 1.00

Vita3K summary

Version: v0.1.6
Build number: 3040
CPU backend:  Dynarmic
GPU backend: Vulkan

Test environment summary

Tested by: Gerold55
OS: Windows 11
CPU: Intel Core i5-9300H
GPU: Nvidia GeForce GTX 1650
RAM: 8GB

Issues
When loading into the game Vita3k crashes before getting into Madden 13 right at the loading screen.
Screenshots
Log
vita3k.log
Recommended labels

Menu

It's getting in game now let's you go thru the menu select team to play them glitches can barely see the field n players but has definitely made progress

App summary

App name: Madden NFL 13
App serial: PCSE00084
App version: 1.00

Vita3K summary

Version: v0.1.8
Build number: 3194
Commit hash: https://github.com/vita3k/vita3k/commit/ca92b35e
CPU backend: Dynarmic
GPU backend: Vulkan
Test environment summary
Tested by: sam
OS: Windows 10
CPU: AMD 5500u
GPU: AMD Radeon Graphics
RAM: 6GB
Screenshots

Log
vita3k.log
Recommended labels
Ingame -
graphics bug

It's still not playable
On Fri, Jun 2, 2023, 1:08 AM tasle1001 @.***> wrote:

App summary

App name: Madden NFL 13
App serial: PCSE00084
App version: 1.00

Vita3K summary

Version: v0.1.8
Build number: 3194
Commit hash: @.***
https://github.com/Vita3K/Vita3K/commit/ca92b35e
CPU backend: Dynarmic
GPU backend: Vulkan
Test environment summary
Tested by: sam
OS: Windows 10
CPU: AMD 5500u
GPU: AMD Radeon Graphics
RAM: 6GB
Screenshots
[image: image]
https://user-images.githubusercontent.com/131510427/242789500-68ad608a-2ea6-4aa4-8b97-bc1676b9b8ef.png
Log
vita3k.log
https://github.com/Vita3K/compatibility/files/11631999/vita3k.log
Recommended labels
Ingame - https://github.com/Vita3K/compatibility/labels/Ingame -
graphics bug
https://github.com/Vita3K/compatibility/labels/graphics bug

—
Reply to this email directly, view it on GitHub
https://github.com/Vita3K/compatibility/issues/1328#issuecomment-1573155077,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A53FZESZ4Y5U4FQ7V3QCNCLXJFYNXANCNFSM6AAAAAAVP6WKIU
.
You are receiving this because you commented.Message ID:
@.***>

When loading into a game it crashes

I'm confused by this on certain version it will load thru the menu yes even
let you select teams but it has major graphics issues while actually
playing the game
On Fri, Jun 9, 2023, 10:14 PM Gerold55 @.***> wrote:

When loading into a game it crashes
—
Reply to this email directly, view it on GitHub
https://github.com/Vita3K/compatibility/issues/1328#issuecomment-1585426586,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A53FZEQLZNDBQ4DV2YIEWTTXKPJ73ANCNFSM6AAAAAAVP6WKIU
.
You are receiving this because you commented.Message ID:
@.***>

Still has graphics glitch even tho it loads and let's you select teams you can't see the field or players I think it has to do with the shading setting

Doing a great job in progressing im very appreciative of your time putting into this emulator

Definitely has progress since the last update in Oct still not playable just yet graphics has glitches in it let's you go thru the menu no problem edit rosters pick teams etc the only thing is graphics glitch believe it's a shader problem so close to be playable great job guys please keep working on this game thanks so much

It let's you get into a game and play but it's slow and has a low fps.

No the performance is smooth but it has graphical issues like the fans are
missing from the stands so our the players on the sideline and the players
faces are messed up but other than that it's fine
On Wed, May 15, 2024, 11:49 PM Gerold55 @.***> wrote:

It let's you get into a game and play but it's slow and has a low fps.
—
Reply to this email directly, view it on GitHub
https://github.com/Vita3K/compatibility/issues/1328#issuecomment-2113973405,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/A53FZESVAZWYWXEY3XACWCLZCQUDZAVCNFSM6AAAAAAVP6WKIWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMJTHE3TGNBQGU
.
You are receiving this because you commented.Message ID:
@.***>

Definitely has gotten better especially with turnip drivers has minor graphics issues you can play the game gameplay is smooth you can see the players well only the faces are a little drooped still no fans In stadium but you can play a whole game even a season no problems

Still same graphic issues plays smooth with drivers still no fans or players on sideline players faces are still drooped but can play a whole game/season without crashes

The only graphics glitch wrong everything is fine

Can you please fix the graphics issues it's almost there and fully playable

Please work on this game it's almost playable

Please don't forget to work on this game we need more sports titles on this emulator


Support varying colors in a PatchCollection

Previously all items would take the color of the first item.

Update also fixes the cmap coloring for PatchCollection, which was working in my setup but not your tests because I was calling plt.show() first, I think.

Looks like the reference files need another refresh.

Same problem as last time - the last digits of the reference output are different on my machine, and I have to remember not to commit them

Same problem as last time - the last digits of the reference output are different on my machine, and I have to remember not to commit them

I filed a bug for that on https://github.com/nschloe/tikzplotlib/issues/368. If this here turns out to be fiddly for you, I'll cook up something tomorrow that we can merge before this.

Tests now use only 8 digits, so hopefully this should help everyone get reproducible tests on any machine.


Add bash startup script and info on how to run it

Signed-off-by: Zingo Andersen<EMAIL_ADDRESS>

Hi tried your project and got it running without powershell (as I don't have it installed)
I tried to add the info I needed to do to the README.md so it would be easier for the next person to use it :) It's totally ok if you don't want this or want me to clean it up, just let me know if that is the case. I'm new to this node stuff so my readme changes could be a bit off depending on how you are supposed to do it :)

Ah yes, good call. I use PowerShell for a lot of my scripts and forgot to include a bash version. Don't feel bad about the node stuff, I don't really know it that well either. Just enough to make this, lol. What you added to the readme sums it up pretty well.
I never really planned for anyone else to use it, so a lot is quite specific to my needs, but I might go in and add a few config bools to allow enabling or disabling features (such as the MQTT stuff) so as not to cause any unnecessary errors or possible crashing if things are not used/filled out, such as the .env file for the MQTT server connection info. I will also add in dummy example of the .env in case someone does want to actually use it. At that point I can go back to the readme and try and give some more details on the features and how to use them.

I never really planned for anyone else to use it, so a lot is quite specific to my needs, but I might go in and add a few config bools to allow enabling or disabling features (such as the MQTT stuff) so as not to cause any unnecessary errors or possible crashing if things are not used/filled out, such as the .env file for the MQTT server connection info. I will also add in dummy example of the .env in case someone does want to actually use it. At that point I can go back to the readme and try and give some more details on the features and how to use them.

No worries about that, I assume you as my tread this a hobby freetime codeing and the code envolves depending on the need :)
If it's ok Ill start to configure some buttons on my side and I might change some code during the process, Ill try to keep your stuff in a good shape in my fork so we can pull between our  forks. I'm happy to share my changes and you can decide if you want to bother or not with them depending on the change or your time if/when they happen :) e.g. my mindset is that I don't expect you to do anything but are happy to share my stuff back when it makes sense :)


Close Lightbox Youtube video after has been playes with data-lity

Hi Guys,
I've used data-lity method to open the lightbox, like this
iFrame Youtube
But I haven't found the way to close the lightbox after the video has been played. Is there any way to get this done? I've seen another example related but only works when the instance is defined on JS.
Cheers guys

No one?

If I understand your question correctly, you’ll need to listen to the events emitted by the YouTube player within the iframe. Then you’ll be able to detect when the video has finished playing. See here for some examples: https://developers.google.com/youtube/iframe_api_reference#Getting_Started

It's pretty simple, I've done it with Vimeo using like this (I assume YT has something similar).
`

Here's the Youtube version:
HTML
<link href="/lib/lity/3.0.0-dev/lity.min.css" rel="stylesheet">

Play

JS

IMPORTANT NOTES

the enablejsapi=1 parameter is required.
Lity 3.0.0-dev or greater is required, as v2.4.1 (the currently "stable" one) has a weird QueryString handling feature that breaks the enablejsapi parameter while "forcing" the autoplay parameter, thus messing up everything. Luckily enough, v3.0.0-dev fixed such behavior.

For additional info & samples, read this post.
N.B.: If the author is up for it, I wouldn't mind add the Vimeo and Youtube APIs to the corresponding lity plugins to trasform these hacks into lity's legacy functions: drop a note if you're interested :)

Here's the Youtube version:
HTML
<link href="/lib/lity/3.0.0-dev/lity.min.css" rel="stylesheet">

Play

JS

IMPORTANT NOTES
* the `enablejsapi=1` parameter is required.

* Lity 3.0.0-dev or greater is required, as v2.4.1 (the currently "stable" one) has a weird QueryString handling feature that breaks the `enablejsapi` parameter while "forcing" the `autoplay` parameter, thus messing up everything. Luckily enough, v3.0.0-dev fixed such behavior.

For additional info & samples, read this post.
N.B.: If the author is up for it, I wouldn't mind add the Vimeo and Youtube APIs to the corresponding lity plugins to trasform these hacks into lity's legacy functions: drop a note if you're interested :)

Hi @Darkseal
how to get your version?


docs(python/adbc_driver_manager): improve docstrings for set_options

Add example usage for how to set options from the Python bindings.

That's certainly the biggest issue. The other issue IMO is that generally when I see **kwargs in the parameters I think of something I can call like this: some_function(arg1=value1, arg2=value2, ...), but this is a little different since most options have periods, so you HAVE to call it like some_function(**kwarg_dict). To me that feels a little non-standard in Python.


refactor: modify multiple classes to use Java records

The record keyword is a concise way to declare a class that is primarily intended to store data, leading to a significant reduction of boilerplate code.
In addition, I have updated Gson to version 2.10.1, as only versions >= 2.10 support the serialization and deserialization of Java records.
Finally, I have also applied code formatting with Spotless.

That's funny I submitted a couple of PRs last week for the very same.

That's funny I submitted a couple of PRs last week for the very same.

Ahhh, I might just close this pr...

See https://github.com/surrealdb/surrealdb.java/pull/20#pullrequestreview-1356648980


No stream found ( Vegamovies)

what show/movie is this

Every movies and tv shows

that was because they changed site domain should be working now

Check out the new update that fixes the issue more appropriately.

Yes. Working now


Update documentation for outlier detection

To more clearly call out that 5xx errors work for both HTTP and TCP traffic. Relevant issue: https://github.com/envoyproxy/envoy/issues/3058
Looks like documentation is versioned -- full transparency, I have neither run the website locally (haven't yet installed toolchain, etc.) nor do I quite understand if I need to repeat this documentation for all versions or if there was some automated system that did that for me 😅
But anyway wanted to put up a simple commit first to see what the maintainers thought!

EDIT: I guess I have some things to figure out; the preview suggests that something from the rst didn't make its way into the html

hi @chusteven the docs arent edited here - they are created from the main Envoy repo
could you open a PR there to update - ill close this one - let me know if you need any help figuring out where to make changes

hi @chusteven the docs arent edited here - they are created from the main Envoy repo
could you open a PR there to update - ill close this one - let me know if you need any help figuring out where to make changes

Thanks! Opened https://github.com/envoyproxy/envoy/pull/22909 -- still don't know if it's where I was supposed to put stuff but it's all I could find during greping :D


Suggestion: Optionally using whole viewport as single bounding box for layers

I recently made pull request to editor-layer-index about adding some new layers for Estonia. What I noticed, was that all layers there but one were based of WMS layers, that supported bounding boxes with any aspect ratio (not just squares). All these layers are built for web app, which native behaviour is to use on-demand rendering, where bounding box of requested layer is browsers viewport.
I understand that iD uses boundaries of tiles as bbox value for several optimisation reasons. For example, treating each tile as separate box reduces amount of code written and makes integrating such layers to rest of iD app easier. Loading tiles in smaller chunks allows user to see results quicker (single downloaded file is smaller) and server owners could set up caching to save time on rendering by sharing primarly standardized tiles.
Now problem is that some servers are designed from ground up to natively serve requests to render on demand (including primary Estonian tile server). They have highly optimized internal rendering and database query systems, but lack serving loads of parallel requests. Things can get worse. If each tile is rendered independently from vector-based text layer, things will get clogged. Picture of how iD-based tile testing app shows city name in middle of each tile (unwanted behaviour):

My suggestion to counter it is to choose big non-standard bounding box based on size of editor window. To avoid redownloading tile every time user moves map, box should have small buffer depending on size of viewport (100-300 px in each direction), screen resolution and prediction, in which direction map will be moved next.
Decision, whether to use tiles or full-size bbox should be made by end user or imagery index contributor.

Interesting. Do you know how widespread this pattern is? It'd be a lot of development work to build an alternative rendering flow and that screenshot doesn't really look that bad. The data is visible and the repeated labels seem like a relatively minor annoyance.
You might actually be able to tick iD into fetching bigger tiles by setting tile-size, but I'm not sure.

I honestly don't think it's common pattern/problem. It only applies to (some niche WMS) layers, where text is positioned on map tiles based on user's bounding box. Situation could look worse if there are longer text phrases, clipping could occur. Example from testing layer (not added to imagery index yet):

Using bigger tiles (1000x1000px) could be reliable workaround. Unfortunately, iD's UI doesn't seem to have such feature or does it?
PS on other loosely related note. Is iD hardcoded to use very limited set of global CRSs? I tried to understand code on my own, but no gain. Adding support for Estonian EPSG:3301 would allow use of 150+ more layers, mostly benefiting OHM project.

I honestly don't think it's common pattern/problem. It only applies to (some niche WMS) layers, where text is positioned on map tiles based on user's bounding box.

Okay, in this case I'm closing this issue as low-impact. We don't have the development resources to make every possible tile layer look perfect, unfortunately. Though if a volunteer contributor wants to take this on then that could be okay.

Is iD hardcoded to use very limited set of global CRSs?

Yes, and adding support for more would be non-trivial. iD would have to either warp raster tiles or project all vector data and neither sound pleasant if they're avoidable.


Update main.tf

what

Describe high-level what changed as a result of these commits (i.e. in plain-english, what do these changes mean?)
Use bullet points to be concise and to the point.

why

Provide the justifications for the changes (e.g. business case).
Describe why these changes were made (e.g. why do these commits fix the problem?)
Use bullet points to be concise and to the point.

references

Link to any supporting github issues or helpful documentation to add some context (e.g. stackoverflow).
Use closes #123, if this PR closes a GitHub issue #123

Ran Plan for dir: . workspace: default
Plan Error
running "/Users/yavuzdogan/.atlantis/bin/terraform1.3.9 init -input=false -upgrade" in "/Users/yavuzdogan/.atlantis/repos/yavuzd/terraform-aws-vpc/1/default": exit status 1
There are some problems with the configuration, described below.

The Terraform configuration must be valid before initialization so that
Terraform can determine which modules and providers need to be installed.
╷
│ Error: Argument or block definition required
│
│ On main.tf line 21: An argument or block definition is required here. To
│ set an argument, use the equals sign "=" to introduce the argument value.
╵

Ran Plan for dir: . workspace: default
Plan Error
Show Output
running "/Users/yavuzdogan/.atlantis/bin/terraform1.3.9 plan -input=false -refresh -out \"/Users/yavuzdogan/.atlantis/repos/yavuzd/terraform-aws-vpc/1/default/default.tfplan\"" in "/Users/yavuzdogan/.atlantis/repos/yavuzd/terraform-aws-vpc/1/default": exit status 1
╷
│ Error: Invalid provider configuration
│
│ Provider "registry.terraform.io/hashicorp/aws" requires explicit
│ configuration. Add a provider block to the root module and configure the
│ provider's required arguments as described in the provider documentation.
│
╵
╷
│ Error: configuring Terraform AWS Provider: no valid credential sources for Terraform AWS Provider found.
│
│ Please see https://registry.terraform.io/providers/hashicorp/aws
│ for more information about providing credentials.
│
│ Error: failed to refresh cached credentials, no EC2 IMDS role found, operation error ec2imds: GetMetadata, request send failed, Get "http://<IP_ADDRESS>/latest/meta-data/iam/security-credentials/": dial tcp <IP_ADDRESS>:80: i/o timeout
│
│
│   with provider["registry.terraform.io/hashicorp/aws"],
│   on <empty> line 0:
│   (source code not available)
│
╵


[production][freecen2_places#create] undefined method `[]' for nil:NilClass

See this exception on Errbit

Problem is caused by the failure to strip whitespace from the grid reference

Stripped white space applied to test3


support special meta-query of dns-sd

This is to issue #13 when a wildcard browsing _services._dns-sd._udp.local. did not work.
This is a missing feature. The spec is here: https://datatracker.ietf.org/doc/html/rfc6763#section-9.
Test and example code are added.

It is strange that the new test only fails in GitHub and succeeds in local macOS and Linux.


Pod traffic get interrupted when upgrading from 1.7.x to 1.8.x

Bug report
Symptoms
Tested that when upgrading from 1.7.4 to 1.8.2, Pod traffic will get interrupted for 1~10 seconds, or even longer.
Clarify that this does not relate to the NAT、CT configuration changes as specified in 1.8 upgrade guide.
Affected version
According to the code (see blow), we assume that upgrading from 1.7.x -> 1.8.x will encounter this problem.
Digging inside
Taking 1.8.2 and 1.7.4 implementation as references in the below.
1. Agent removes cilium_policy map on start, before cilium_call_policy is correctly setup
Endpoints rely on this BPF map for tail calls.
This map is renamed from cilium_policy (1.7.4) to cilium_call_policy (1.8.2), but this commit removes the old one on startup - before the new one correctly sets up. All endpoints on this node will get interrupted immediately.
As a quick test, reverting this commit could solve this interruption.
2. Agent created cilium_call_policy map before all endpoints' maps reloaded
There are two sequential steps in 1.8.2:

Reload BPF for host device (e.g. bond1 of the node, or cilium_host), this will create cilium_call_policy.
Reloads BPF for all the endpoints (pods) on this node. This will update the endpoint -> entrypoint of tail call mappings in cilium_call_policy.

As step 1 happens before step 2, cilium_call_policy will miss all the tail calls before an endpoint is reloaded, which is another reason that leads to pod traffic interruption.
We could see the drop types are indeeded Missed tail calls either in the metrics, or with cilium monitor --type=drop:
$ cilium monitor --type=drop
xx drop (Missed tail call) flow 0x0 to endpoint 0, identity 2->0: <IP_ADDRESS> -> <IP_ADDRESS> EchoRequest
xx drop (Missed tail call) flow 0x0 to endpoint 0, identity 2->0: <IP_ADDRESS> -> <IP_ADDRESS> EchoRequest
xx drop (Missed tail call) flow 0x0 to endpoint 0, identity 2->0: <IP_ADDRESS> -> <IP_ADDRESS> EchoRequest
...

where <IP_ADDRESS> and <IP_ADDRESS> are IP addresses of Pods running on this node.
CC @jaffcheng

Thanks for the report @ArthurChiao and @jaffcheng!
I think the issue is a bit more subtle than it appears. AFAIK, removing cilium_policy from the file system doesn't actually delete the map; the map will only be deleted once all references (including BPF programs) to it have been deleted.
However, in the time between the removal of that file and the reloading of all endpoints, the new cilium_call_policy map referenced by (among others) bpf_host (the program attached to cilium_host and native devices) will not have all entries for the endpoints, resulting in missed tail calls and packet drops.
I'm not sure what the correct solution would be. We may need to populate the new map with the content of the old before loading the base programs (i.e., bpf_host & co.).
It's also unclear why the upgrade/downgrade test missed this. It could be a matter of timing where most missed tail calls are coming from bpf_host because it is reloaded before the endpoints and the init.sh call. Then, since we have tunneling enabled in that test, maybe we don't have enough packets going towards endpoints via bpf_host to trigger a fail.

I think the issue is a bit more subtle than it appears. AFAIK, removing cilium_policy from the file system doesn't actually delete the map; the map will only be deleted once all references (including BPF programs) to it have been deleted.

I believe this is true for all other map types, but BPF_MAP_TYPE_PROG_ARRAY has special rules here which I believe is in fact the behaviour that Arthur and Jaff report above: Once it is unpinned, it is cleaned up immediately.
In this case, it would be I think a matter of deferring the deletion of the old map until we are sure that all base programs & endpoint programs have been successfully reloaded after startup.

Hi, about fixing this, what comes to our minds first is the same as @pchaigno

I'm not sure what the correct solution would be. We may need to populate the new map with the content of the old before loading the base programs (i.e., bpf_host & co.).

To prove our idea, we've made a quick try (introduces other problems but enough to prove the idea) that:

keeps old call map cilium_policy
makes the reload of per-endpoint tc-ebpf earlier than cilium-host/native-device tc-ebpf

The packet drops by ping -i 0.01 $ep_ip during cilium upgrade decreased from around 300 to 1, that is from about 3 seconds to 0.1 second. Just FYI.

I believe this is true for all other map types, but BPF_MAP_TYPE_PROG_ARRAY has special rules here which I believe is in fact the behaviour that Arthur and Jaff report above: Once it is unpinned, it is cleaned up immediately.

That is correct.
@jaffcheng @ArthurChiao have a chance to test fix in #13032 ?

@borkmann Hi Daniel, thanks for the quick fix! Haven't tested this fix, I think this fix keeps the old pinned tail call map, not sure if I'm right, but AFAIK, once new tc ebpf (1.8.x) is reloaded on cilium-host/native-device, tail calls to endpoints would look for elem at the index endpoint id from the newly created cilium_call_policy tail call map, which is still empty at this point.
https://github.com/cilium/cilium/blob/master/bpf/lib/l3.h#L136

#13051 should fix the drops due to missed tail calls on upgrades from v1.7 to v1.8. We will backport it to v1.8.
#13032 will fix another bug causing missed tail calls for a much shorter period of time. We will backport it to at least v1.8.
#13052 will fix the equivalent bug on downgrades from v1.8 to v1.7. It will be applied on v1.7 only.
#13097 extends an existing test to detect such issues going forward. We will backport it to v1.7 and v1.8.

These four pull requests should resolve the present issue. I'm hoping to get the upgrade path fixed in the next 1.8.4 release and the downgrade path in the next 1.7.10 release.

Hi @pchaigno, according to our discussion yesterday, we have tested #13051 and confirmed that it is able to eliminate the traffic disruption problem as described in the beginning of this issue.
Thanks a lot for your efforts! @pchaigno @borkmann

Closing this issue as both the 1.8 and the 1.7 fixes have been merged and backported. They will likely make it into Cilium 1.7.10 and 1.8.4.
Thanks for the help debugging and testing the fixes @ArthurChiao!


Black textures (incorrect lighting) since version 2.1

The game uses an overhead view to create a 2D map of the area around the player. The same technique is used to render a preview of the character's head on a 2D surface when starting a new game.
Since DXVK 2.1, both are completely black. The only exception is that the map is rendered correctly the first time when the game starts, but then is replaced by a black texture when loading a new area.
Working (version 2.0):

Not working (version 2.1):

Looks like DXVK might not be correctly keeping track of light changes.
In fact, the issue disappears if you remove the following loop in d3d9_stateblock.h:
        for (uint32_t i = 0; i < m_captures.lightEnabledChanges.dwordCount(); i++) {
          for (uint32_t consts : bit::BitMask(m_captures.lightEnabledChanges.dword(i))) {
            uint32_t idx = i * 32 + consts;

            dst->LightEnable(idx, m_state.IsLightEnabled(idx));
          }
        }

Note how the map surface is created first on frame 313 of the attached trace.
First, there's a call to SetViewport (256x256 for the map), then SetLight (index is 1), then LightEnable(1, TRUE).
The same light is not set again, a reference is kept and the game just enables/disables it to render the mini-map.
See frame 417, where a new map is rendered, and the same light is enabled again. The index of the light is always 1.
Does the driver lose a reference to this light? Maybe the first index is skipped by the loop above?
EDIT: Nothing to do with light index, see comments below.
Software information
Morrowind GotY (using D3D9 thanks to MGE XE).
Same issue on two completely different systems:
System 1 information

GPU: Intel A750
Driver: <IP_ADDRESS>23 (Windows), Mesa 22.3.5 (Ubuntu 22.04, kernel 6.2-rc7)
Wine version: 6.0.3
DXVK version: 2.1 (shows black textures) 2.0 (works fine)

System 2 information:

GPU: Radeon RX Vega M GL
Driver: 30.0.13025.1000, A03 (tested in Windows only)
DXVK version: 2.1 (shows black textures) 2.0 (works fine)

Apitrace file(s)

https://mega.nz/file/WVBkhLCa#FX3H2uPshwPsYT2nCI1wA0NAevQK_gAj4r08cFFP-oA

Log files

d3d9.log: https://mega.nz/file/WVBkhLCa#FX3H2uPshwPsYT2nCI1wA0NAevQK_gAj4r08cFFP-oA

Can you bisect it down to a specific commit?

You didnt even open the map in your apitrace.

Thanks for the generally well made issue anyway :slightly_smiling_face:

Yes, what Blisto said. :)

Apologies, I didn't think of doing that since the same issue is visible on the mini-map at the bottom-right of the screen 😄
Anyway, here's another trace, with the larger map open: https://mega.nz/file/GNRlTISR#tATB_0jfqFyyMFqK4Ew4Gr5YGoPiTfPtFWx3RGtXHYI
Thanks!

Ah missed the minimap part. The issue in the new trace is that it goes black after you press local right?

Both apitraces look identical when replaying them with DXVK and the Nvidia D3D9 driver as far as I can tell.

I wasn't sure i was able to reproduce the map issue ingame either, but i could reproduce the character creator issue so captured a trace of that instead.
https://mega.nz/file/dxQ2kDyZ#snLY2MItzinB0f0NixGzgDyDq853FLPV7pCWG9i_cLw
And regressing commit is https://github.com/doitsujin/dxvk/commit/4796eb0b0dfe1a932a6267c08e8c85831c476dd0

Thank you for that.
So nothing to do with light index, since a different one is used for the character creation preview.
I also noticed that the character's head preview is correctly lit just for one frame when it first appears, then it immediately turns black.
As a test, I compiled MGE XE with a little hack. Basically, it re-sets the directional light whenever the viewport for either the local map or the character preview is set. It shouldn't need to, because the pointer to the existing light should still be valid, as well as its last state; but with this hack, the issue disappears.
In MGE XE's d3d8device.cpp:
HRESULT _stdcall ProxyDevice::SetViewport(const D3DVIEWPORT8* a) {
    // Original code: return realDevice->SetViewport(a);
    HRESULT result = realDevice->SetViewport(a);

    if (a->Width == 256) {
        LOG::logline("*** Created viewport for local map.");
        D3DLIGHT9 light;
        light.Type = D3DLIGHT_DIRECTIONAL;
        light.Diffuse = D3DCOLORVALUE{ 0.7f, 0.7f, 0.7f, 0.0f };
        light.Specular = D3DCOLORVALUE{ 1.0f, 1.0f, 1.0f, 0.0f };
        light.Ambient = D3DCOLORVALUE{ 0.3f, 0.3f, 0.3f, 0.0f };
        light.Position = D3DVECTOR{ 0.0f, 0.0f, 0.0f };
        light.Direction = D3DVECTOR{ 0.707107f, 0.0f, -0.707106f };
        realDevice->SetLight(1, &light);
        realDevice->LightEnable(1, TRUE);
    }
    else if (a->Width == 234) {
        LOG::logline("*** Created viewport for character's head preview.");
        D3DLIGHT9 light;
        light.Type = D3DLIGHT_DIRECTIONAL;
        light.Diffuse = D3DCOLORVALUE{ 1.0f, 1.0f, 1.0f, 0.0f };
        light.Ambient = D3DCOLORVALUE{ 0.25f, 0.25f, 0.25f, 0.0f };
        light.Position = D3DVECTOR{ 0.0f, 0.0f, 0.0f };
        light.Direction = D3DVECTOR{ 0.655618f, 0.374607f, -0.655618f };
        realDevice->SetLight(88, &light);
        realDevice->LightEnable(88, TRUE);
    }
    return result;
}

If you want, here's a binary of the DLL with the above modification: https://mega.nz/file/fY43XKCI#ze0mRo2KAluURy2W_PmeAdP_cPVwQeAaXXC-V-x52Os

That PR fixes it.

Well, that was quick 😄 I gave it a go, and yes everything works fine with that.
Excellent work, thanks both.