Skip to content

Conversation

@Dragorn421
Copy link
Collaborator

@Dragorn421 Dragorn421 commented Jun 8, 2025

This is a suggestion allowing to merge assets xmls for different versions into one

With this,

  1. resource elements can be wrapped in <Version> nodes making them version-specific
<Version Pattern="ntsc-.*">
    <Resource .../>
</Version>
  1. offsets can be omitted: a resource will start where the previous one ends

  2. offsets can be relative: for example Offset=".+0x10" will make a resource start 0x10 bytes after the end of the previous one

This is not incompatible with #2613 but I guess we'd want to do it one way or the other, not both?

Advantages:

  • no need to specify offsets for resources that just get shifted due to the presence/absence of other resources before them
  • less duplicate info, most of the resource info (name and any other attributes) is in the same resource element unless said resource is moved between versions then it's duplicated still

Disadvantages:

  • need to specify all resources, and even padding, for things to line up. For example in gkeep we'd need to add resources for animations FrameData and JointIndices no longer the case with relative offsets (Offset=".+0x10")

@fig02 fig02 added the Needs discussion There is a debate or other required discussion preventing changes from being made label Jun 8, 2025
@Dragorn421
Copy link
Collaborator Author

Working on this some more since it seems more popular than the other (Anghelo and cadmic seemed to prefer it)
I added relative offsets in xmls, that is Offset=".+0x10". See the updated PR description or the updated xml spec.md for details

@fig02
Copy link
Collaborator

fig02 commented Jun 11, 2025

Im on board with this idea.
Will offsets be removed en-mass after they are allowed to be implicit? I feel like having a mix of implicit, relative, and explicit will be pretty confusing but idk what the plan is here

@Dragorn421
Copy link
Collaborator Author

I would much prefer keeping explicit offsets as much as possible since they're very useful for hacking the game (and there's no downside for decomp to do so),
and only use implicit and relative offsets where necessary to accommodate for version differences and avoid duplicating xmls/resources

But that's just my opinion

Copy link
Collaborator

@fig02 fig02 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

alright!

@Dragorn421 Dragorn421 changed the title Assets system: reconcile xml versions using implicit offsets Assets system: reconcile xml versions using implicit and relative offsets Jun 11, 2025
@Dragorn421
Copy link
Collaborator Author

I pushed more xmls being reconciled

Also added Tlut="gNameTLUT" to make texture resources refer to tluts by name rather than by offset, which is a change I wanted to make anyway and is needed here because the TlutOffset can change across versions in some objects

Comment on lines +3 to +18
<Version Pattern="ntsc-.*|gc-jp.*|gc-us.*|ique-cn">
<Animation Name="gSheikPlayingHarpAnim" Offset="0xDB8"/>
<Animation Name="gSheikShowingTriforceOnHandAnim" Offset="0x1C58"/>
<Animation Name="gSheikShowingTriforceOnHandIdleAnim" Offset="0x1F64"/>
<Animation Name="gSheikPlayingHarp2Anim" Offset="0x2D38"/>
<Animation Name="gSheikPlayingHarp3Anim" Offset="0x3CE8"/>
<Animation Name="gSheikPlayingHarp4Anim" Offset="0x4F90"/>
</Version>
<Version Pattern="pal-.*|gc-eu.*">
<Animation Name="gSheikPlayingHarpAnim" Offset="0xB6C"/>
<Animation Name="gSheikShowingTriforceOnHandAnim" Offset="0x1A08"/>
<Animation Name="gSheikShowingTriforceOnHandIdleAnim" Offset="0x1D14"/>
<Animation Name="gSheikPlayingHarp2Anim" Offset="0x289C"/>
<Animation Name="gSheikPlayingHarp3Anim" Offset="0x35C8"/>
<Animation Name="gSheikPlayingHarp4Anim" Offset="0x4570"/>
</Version>
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

these animations are different sizes so they can't use relative offsets anyway, so they're duplicated here. #2613 could be used instead in this spot?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Needs discussion There is a debate or other required discussion preventing changes from being made

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants