NSO Freezes on the loading screen, when using a new DisplayEx

As the result of this issue is not very distinct, I will put the details and context of this issue front and center.

This only happens with, and because of DisplayEx. And specifically with a new version of the mod and app. It can happen with any platform app, but I have seen it with SNES and NES for certain. SNES just because that is what I used to develop DisplayEx with.

Read the above before jumping on to claim a freezing at the loading screen issue is the same as this.

…

That out of the way… This issue is one I have seen since the inception of DisplayEx. I refer to it as something like “the makes no sense issue”. It rejects all direct efforts for me to debug and work around the issue. Hence the part about not making sense. I have only ever gotten past it… randomly. And Im still working with theories to try and explain it.

For my own benefit, I am going to detail some of the issue here for me to reference when trying to solve it.

{
    "id": "fd448078-2980-4205-9cb1-0a7b72bb329d",
    "data": {
        "path": "/sprites/colorhalftone_preview.png",
        "imageContentType": "IMAGE_TYPE_PNG"
    },
    "originalPath": "Sprites/ColorHalfTone_Preview.png",
    "type": "ImageResource",
    "groupId": "509"
},

"id": "cd7d84ab-5773-48b7-9b4d-d86e409c86a8",
"data": { "path": "/scenes/sys/sysdisplaymodelayout.scn" },
"originalPath": "Scenes/sys/SysDisplayModeLayout.scene",
"type": "Scene",
"dependencies": [
...                
    { "id": "fd448078-2980-4205-9cb1-0a7b72bb329d" },

The above are the key data involved in this issue. They reside in the resources.json. The first snippet is one of many resource entries I add to the resources file for use in DisplayEx. The second is a sub-section used for informing the options screen in the NSO app, about what resources to load for it to have access to. I omitted most of the data to focus on the reference to the resource in question.

The resource itself is a thumbnail for the stock NSO background. The id, path, originalPath, and groupId are all valid. As in, no typos, incorrect value, or unsupported characters. The remaining meta data is standard and fine as well. The image file itself is valid and fine. Even tested with different DPI’s and color counts.

The issue happens when the reference id is included in the second part. Not always of course. Often times things work just fine, including that. If you are using a working DisplayEx right now on any of the apps, its using this exact resource and metadata. Its just a issue when the app decides its an issue. When it is a issue, I have been able to 100% distinguish this issue from other loading screen freezes by reducing things down to… if that reference id is included there, it freezes, if not, it loads. That is it. Why is it an issue? I have no real idea. Just theories that don't hold up well.

Keep in mind, that when encountering this issue and testing it, I remove all other files from the equation. NSO will boot with just the resources json and these additions included. Or should, rather.

…

My best attempts at a theory for why this issue happens is… That the NSO app caches the resource json here and there. In doing so, it remembers all of the resource entries, their ids and groupId indexes. This issue seems to crop up when NERD changes the total number of resources, and specifically when the resource amount goes does. For example, in NES v6.8 there were 510 stock resources total, and in v6.9 it was reduced to 508. With DisplayEx, I think the caching causes it to see the first resource as something else that used to have that groupId previously.

…

How I have gotten past this issue in the past has felt random, to the extent that I am not able to define a procedure and reproduce it. But it feels like I’m just shaking something loose as it just suddenly decides to work.

I end up creating a VERY stripped down version if the options scene json, and try adding in one DisplayEx control at a time. Or to speed things up, I remove a group at a time until it works, or add a group until it fails. Over that process, things just start working as by the end of it… suddenly I am able to reference that resource id, and load all the controls.

…

I think that sometimes the issue first appears because I do make mistakes in the porting of the mod, by manually copying data around and forgetting to change some things. Doing so will certainly produce the same loading screen freeze result. But I have recently written code to programmatically generate these updates json files, and thus eliminate such human error going forward.

Comments (4)