spinout

Nintendo will say that all they have to comment on the subject is that it was released as Master Quest. Nintendo will never admit that Master Quest was just a rehash of OoT, and URA was never released.

Somebody else just committed the first stuff for a windows debugger. Promising.

(bump) My octopus actor worked on hardware but had z buffer issues as well. I don't remember what converter I used. Probably my most recent python converter (not too recent, 2012 at best, lol). JSA, any progress on ZLE3?

64DD emulation development for those interested: http://forums.cen64.com/viewtopic.php?f=6&t=155&start=50

Just add data at the end of the extracted tables, and reinsert. You're going to have to fix your checksum/rom settings each time. Sorry for the inconvenience.

Hi, The BPS patch is not needed. If you are having patching issues, you can use a big-endian ROM and the python script, by executing it as so: $ ls rom_update.py z64_tables_bin.bin $ python rom_update.py rip ZELOOTMA.z64 $ ls rom_update.py actor_table.bin scene_table.bin object_table.bin exit_table.bin auxillary_data.bin z64_tables_bin.bin $ python rom_update.py write ZELOOTMA.z64 (ls statement used to list files only - you only need z64_tables_bin.bin, the rest of the hack can be applied from the python script) Glad to hear someone is using this! I'll try and check back in again soon.

Racecar http://instagram.com/ottehr

Backtrack from $ra, compare to unmodified.

Does PJ64 complain? Does your code overwrite anything? Does it have different behavior depending on your direction?

http://spinout182.com/?a=z&p=zfsnew ??? There has been a link to a 7z archive for ages. And yeah, my C hacks all have awful hooks. I got my bombarrows working on console with some modifications but I haven't tested anything other than my ROM compressor, bomb arrows, and my octopus lol. Octopus had crazy z axis problems.

Is 'ignore errors' turned on or off in Nemu? Try breakpointing whatever is at $k0 right before the crash too.

Savestate. Breakpoint 0x80002130 shortly before backing up, back up, check what $ra is, go to the beginning of that function, load savestate, back up again without the breakpoint, with and without your hack, and check if there is a difference. If 0x80002130 doesn't break when you're backing up, I'm not quite sure if I can help you. Perhaps use a strict emulator that tells you where it encounters faults?

What language is your hack written in? If it is written in raw MIPS you may have violated some rules that the R4300i cares about more than Nemu.

OoT uses a binary search algorithim to find files in the file table. Make it a table that is not binary search friendly and you will eventually have problems with the game not finding the file you are looking for. A binary search friendly list is one that has the values in order (smallest to largest or vice versa), so if a file is moved but it keeps the same entry the game will not be able to find the entry in the filetable. E.G: 1, 2, 3, 4, 5, 6, 7, 8 If you do a binary search for 7, the algorithim will check the 4th entry (half way through), see it is too small, then check the next half way point (6), then it will see the next half way point (7), and return 7 as the result of the binary search. If you switch 2 and 7, you'll get a problem: 1, 7, 3, 4, 5, 6, 2, 8 Algorithim checks at 4, sees it's too small, moves up to 6, still too small, goes to read 2, and runs into undefined behavior when it reads 2. This is why using the stock DMA table in OoT/MM is a pain in the ass. The Debug ROM seems to know it is decompressed and therefore does not care about file table offsets unless the table points to a compresed file - at least this is the behavior in emulators. Why does the game use a binary search? It is much faster to look up files, especially when you have over 1.5k files. DMA transfers take up a lot of time so the programmers wanted to speed up the process. How do we work around this in a practical manner? Option 1: Make a tool which rebuilds ROMs and puts everything in order and fixes all the tables. Option 2: Make a hack which changes how DMA transfers work. I have pondered and unsuccessfully attempted the first option. I have successfully implemented the second option, with LZO compression to boot. I would like to port this hack/tool to other ROM versions. Hardware tested with no errors.

https://code.google.com/p/vg64tools/source/browse/pc/z64porter/trunk/z64porter.c I always regretted not finishing this.

>Decompiler Oh please. Looking good xdaniel, I wish I was still at it programming.

Fresh install of lubuntu.

Perhaps the files were not organized, but they surely did not deal with the ROM as a 32/64 MB image. Perhaps they did when they were still getting booting and the filesystem down, but the majority of the game development surely came after that point.

The stuff that compiled when the Nintendo devs ran their build programs. OoT as it was known to them - an organized set of text files, not a giant binary blob that we have.

It would be like taking a metal plaque, melting it down and casting it to a new plaque - much more difficult than simply using something designed to have modifiable storage (flash cart)

This is why I'm always screaming 'wiki'!

I didn't know that additional scenes would corrupt the save... Where is the info on this?

Sweet. It would be *awesome* to actually see the hack in use...

These are the entries in the exit list within the scene? As opposed to being indexes within a list in code, like OoT. And wouldn't it be more like: SSSSSSSS SSSSSSSE EEEEEEEE zzzzzzzz In a bitwise manner, that is: scene = exit_val>>17 entrance = (exit_val >>8) & 0x1F ? Nevertheless, this thread is full of win. Would there be opposition to me putting the data on the wiki?