Filesystem management

[spinout]

I am putting this up so early in development so I can get a sense of weather anybody thinks it is worthwhile to continue. The main issue is that many files have no apparent table other than the DMA table - specifically, files 961 - 1004 (see http://spinout182.com/mqd/f.html). I know very little about sequences and sounds, somebody with more knowledge in that area (DeathBasket ?) would be best for writing the handlers for those tables - see readers.c, writers.c, and tables.c.

 

tl;dr I'm considering halting progress on a tool which is now top priority re: zelda tools because I can't find a pointer to every file.

 

Maybe I should just write a hack for the game itself and re-vamp the whole system. I'd still have the issue of what points to these files, though.

 

Oh, I almost forgot:

https://bitbucket.org/ottehr/z64-fm/src

[Arcaith]

Having a complete map of files and which files point to which other files would be incredibly useful; it would eliminate a lot of guesswork. I say proceed.

[DeathBasket]

I'm not entirely sure about samples but pointers to sequences and instrument banks are all relative to the start of their files and therefore wouldn't need changing. The files themselves though (Audiobank, Audioseq, Audiotable) have their offsets hardcoded in the machine code around 0xB5A4C0, which is a pain.

Also, iirc, the JFIF images' pointers are relative to the start of the map they're stored in and they do not appear in the DMA table.

[spinout]

I'm not entirely sure about samples but pointers to sequences and instrument banks are all relative to the start of their files and therefore wouldn't need changing. The files themselves though (Audiobank, Audioseq, Audiotable) have their offsets hardcoded in the machine code around 0xB5A4C0, which is a pain.

Also, iirc, the JFIF images' pointers are relative to the start of the map they're stored in and they do not appear in the DMA table.

 

The issue isn't JFIF images, but it is something else which is required to render them. I nulled files 961 - 1004 and it broke maps which had their own JFIF images.

[DeathBasket]

Ah, those could be the scrolling images from maps with static backgrounds and more than one camera angle then. I noticed that before if I changed, say, the Kokiri shop's background, the second background that appears when buying something would still appear despite not seeming to be in the map file at all.

[spinout]

Only problem is that nothing I can find points to them ;_;

 

Edit: I tested this out some more, DeathBasket was pretty much right:

- Areas which can be viewed from the top or normally are black when the camera behaves normally and the JFIF render when viewed from the top

- Stores, as DeathBasket said, work fine until you talk to the shop keeper which loads a different background

- Castle town main is completely broken, the rest of (outdoor) castle town works fine.

 

Solutions?

[Jason777]

I've always told myself not to post in a thread where I didn't know what I was talking about but.. today may be an exception?

Let me get this straight: you're creating a new file table?? Wouldn't that help alot with custom maps and make it easier to ADD even more files to the ROM?

[spinout]

I'm doing much more than creating a new filetable. I am writing an application which reads all the tables and turns pointers into indicies of entries in the filetable, sorts all the files, restores the file pointers via the indicies, then builds a new ROM with correct pointers everywhere. It will resolve any errors or inconsistencies found as well as compress the final ROM with lzo or Yaz0 compression if the user wants.

[spinout]

Well I guess I'm continuing this. Right now it is partially functional and I'm working slowly on finishing what is there already. Then I'll get to the hard parts. Still not sure where I'm going with this though.

[Zeth Ryder]

Somehow I missed this thread, this is pretty impressive, how far have you gotten with it?

[SanguinettiMods]

Is this still in development?

[spinout]

I would, except for the fact that my LZO hack makes it completely unnecessary. What should be under development, in my opinion, is porting the LZO hack to other ROM versions - of most importance, probably MM since DeathBasket has figured out how to disable most of the debug features of the debug ROM, and considering it has a more advanced graphics ucode than OoT, I think the Debug ROM should be the ROM of choice for future OoT hacks.

[SanguinettiMods]

Though, from what I can see, the LZO Hack compresses the Debug ROM, whereas the Filesystem Manager would make it easier to insert new and larger files. if you ask me, both of them complete each other rather than one canceling the other out.

[spinout]

The way the LZO hack reads the filetable, it doesn't have to be sorted, therefore you can just put files at the end of all the other files. When the ROM goes to be compressed, any files which are no longer needed are ommited.

[SanguinettiMods]

So does this mean I can extend files to whatever size I want without problems? (i.e. If Link's file gets too large in the normal game, problems occur with collision and actors and a lot of other things after pausing and unpausing or going through an exit.) If this is true, would I still have to move the files that I enlarge and repoint them? And say I wanted to make custom maps which were previously only "fixed" with JSA's DMA Table fix. Would I no longer need to apply that?

[spinout]

JSA's DMA "fix" only works with decompressed ROMs. It will miserably fail on compressed ROMs. As far as link's file creating problems, that doesn't have anything to do with the filesystem - the game only reserved so much space for him. My suggestion: remove all the low polygon models and consolidate his object to a smaller size, then add what you desire.

[SanguinettiMods]

That is what I do. And one last question: If I remove the garbage bytes at the end of the ROM, somehow, would I be able to compress the ROM into a size small enough for a Wii Wad?

[spinout]

Current ROM compressors (my Yaz0 and LZO compressors, ZZT32's LZO compressor) ignore anything that isn't pointed to in the file table.

[Zeth Ryder]

I would, except for the fact that my LZO hack makes it completely unnecessary. What should be under development, in my opinion, is porting the LZO hack to other ROM versions - of most importance, probably MM since DeathBasket has figured out how to disable most of the debug features of the debug ROM, and considering it has a more advanced graphics ucode than OoT, I think the Debug ROM should be the ROM of choice for future OoT hacks.

 

Are you talking the MM debug rom or OOT one for future hacks?