Set up multiversion assets with ZAPD and match gc-eu #1967
Conversation
|
Paths comparison between main, this PR and new assets main
This PR #1967
new assets v4 #1904
|
|
Yeah, keeping |
Not really, it's just the history of it that led to it being |
There was a problem hiding this comment.
Very nice PR, addresses a bunch of warts I remember dealing with when starting on the new assets system
As a bonus it leaves assets/ empty for it to be filled later :^)
ZAPD would be better modified upstream then pulled into the repo but idk, whatever?
on reviewing, I'm just going to trust the xmls are correct, and if they're not someone will find out eventually (at least it matches)
|
Here's the ZAPD PR: NEstelami/ZAPD#322 |
subrepo: subdir: "tools/ZAPD" merged: "0285e11f0" upstream: origin: "https://github.com/zeldaret/ZAPD.git" branch: "master" commit: "0285e11f0" git-subrepo: version: "0.4.6" origin: "git@github.com:ingydotnet/git-subrepo.git" commit: "110b9eb"
|
nvm, the ZAPD PR is merged so I updated the subrepo here |
Assets for each version are now extracted into
extracted/VERSION/instead of using debug rom assets. Although this conflicts with the future new assets system, I think this is a step in the right direction and it unblocks matching other versions.Major changes:
BaseAddress,RangeStart, andRangeEndattributes which give the virtual address of the asset and its offset in its parent ROM segment. These will change for basically every version even though the assets themselves do not, so I moved this info into config.yml. This is implemented with new ZAPD flags--base-addressto override the start virtual address for a file, and flags--start-offset/--end-offsetto only operate on some slice of the file (different from RangeStart/RangeEnd in that offsets in the XML are relative to--start-offset). It's a bit hacky because these are file-level properties and an XML technically could contain multiple files (though that never happens for code or overlay assets). I'll upstream the ZAPD changes soon: ZAPD features to support OOT multiversion assets NEstelami/ZAPD#322_mq.xml) where config.yml says which XML file to use for each asset. This is perhaps not ideal, but I think any in-XML config would require huge changes to ZAPD. I don't expect this to be too bad, only 20 or so XMLs will change between versions and the differences are mostly broad changes like NTSC vs PAL, N64 vs GC, and MQ vs non-MQ instead of version-specific differences. (See https://docs.google.com/spreadsheets/d/1OGPLrezIfd9MaHZf5s5j0AuncW6EuGuR1ZCn5ZLlRYo/edit#gid=218491254 and https://discord.com/channels/688807550715560050/688851317593997489/823637077786099753 for prior work on object differences.)Minor changes:
#include "assets/objects/gameplay_keep/deku_stick.i8.inc.c"instead of#include "extracted/VERSION/assets/objects/gameplay_keep/deku_stick.i8.inc.c"when including generated files since the generated files could be in eitherextracted/VERSION/orbuild/VERSION/.sShadowTexin ovl_En_Jsjutan is now a "variable" (likegMtxClear) instead of a ZAPD<Symbol>so we don't have to hardcode the offset. This was the only instance of<Symbol>in the project.gMtxClearandsShadowTex. Potentially we could generate this from config.yml but I didn't think this was worth it.git clean -f assetsto delete these)ovl_File_Choose.xmlrenamed toovl_file_choose.xmlto match the ROM segment namemake distcleanis now version-agnostic