Jump to content

spinout

Member
  • Posts

    343
  • Joined

  • Last visited

  • Days Won

    5

spinout last won the day on November 30 2013

spinout had the most liked content!

About spinout

  • Birthday 10/26/1993

Other

  • Flag
    United States

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

spinout's Achievements

Rising Star

Rising Star (9/14)

  • Conversation Starter
  • First Post
  • Collaborator
  • Reacting Well
  • Week One Done

Recent Badges

43

Reputation

  1. 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.
  2. Somebody else just committed the first stuff for a windows debugger. Promising.
  3. (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?
  4. 64DD emulation development for those interested: http://forums.cen64.com/viewtopic.php?f=6&t=155&start=50
  5. 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.
  6. 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.
  7. Backtrack from $ra, compare to unmodified.
  8. Does PJ64 complain? Does your code overwrite anything? Does it have different behavior depending on your direction?
  9. 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.
  10. Is 'ignore errors' turned on or off in Nemu? Try breakpointing whatever is at $k0 right before the crash too.
  11. 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?
  12. 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.
  13. 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.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.