PDA

View Full Version : Removing HUD in MM or OOT


Mozzie
22nd July 2009, 11:52 PM
I want to record some short videos of Majora's Mask and OOT without the hud and I am wondering is there a video plugin or gameshark code that has that capability. I just want to prevent it from rendering.

HatCat
23rd July 2009, 12:16 AM
For a GameShark code you may need to disassemble the game and do the research on how to have the texture not display.

What you can do with a video plug-in is retexture the game. Dump the texture, clear all pixels to transparent, and set it in the texture replacement folder.

Zeth Alkar
4th August 2009, 12:59 AM
For a GameShark code you may need to disassemble the game and do the research on how to have the texture not display.

What you can do with a video plug-in is retexture the game. Dump the texture, clear all pixels to transparent, and set it in the texture replacement folder.

Um you don't need to disassemble the game to make the hud disappear, You can either change the settings for the transparency(alpha) values, the same area in RAM for the RGB values for the Hud. Or you can change if the Interface HUD is activated or not(however doing this can cause the game to go into cutscene mode and exits can be messed up) Or there is the third option, move the interface off screen, which you can find the codes to do that here.
http://64.vg/wiki/index.php?title=Interface_Hacking

Also, I have a No interface code for OoT Debug rom.
8015F9BF 00?? Values: 00 = Off | 01 = On

Also for Majora's Mask (U) No Interface:
50000902 0000
813FD76E 0000

HatCat
4th August 2009, 01:23 AM
Thanks for the codes. All of those methods mention modifying the game, which is also what a "cheat code" does.

To actually find the addresses in the game to know where to write to accomplish the options you give, sometimes people disassemble the game into MIPS code to learn about the game's structure to be able to produce new methods using patterns.

If you already know where the target addresses are due to the findings of someone else that doesn't imply how they were tracked down.

squall_leonhart
4th August 2009, 01:28 AM
yo bitches, i would like to start some cheatin in 1.7 and get some more made but it just dun fookin work >.<

HatCat
4th August 2009, 01:46 AM
I use comparison / value searching on 1.7, but I use 1.6 to create and test.
I otherwise see no point in acknowledging this "1.7 beta" but such new allowances.

Zeth Alkar
4th August 2009, 02:02 AM
Thanks for the codes. All of those methods mention modifying the game, which is also what a "cheat code" does.

To actually find the addresses in the game to know where to write to accomplish the options you give, sometimes people disassemble the game into MIPS code to learn about the game's structure to be able to produce new methods using patterns.

If you already know where the target addresses are due to the findings of someone else that doesn't imply how they were tracked down.

Not all of the game can be disassembled into Mips code :<
And a lot of these are easy to find, just by searching values in RAM, just a lot of trial and error as with many codes made. But as you stated, either way works fine.

HatCat
4th August 2009, 02:29 AM
Not all of the game can be disassembled into Mips code :<
Binaries result from assembly; interventions like compression make it harder to directly translate to some assembly or another.

And a lot of these are easy to find, just by searching values in RAM, just a lot of trial and error as with many codes made.

I use that method myself, but for comparison searching you would have to compare memory after enabling/disabling certain GUI elements or groups. If you can disassemble the game and learn about its structure, you yourself find such multiple ways to solve a problem and also know more about side effects or negative results as you mentioned.

Zeth Alkar
4th August 2009, 02:55 AM
Binaries result from assembly; interventions like compression make it harder to directly translate to some assembly or another.



I use that method myself, but for comparison searching you would have to compare memory after enabling/disabling certain GUI elements or groups. If you can disassemble the game and learn about its structure, you yourself find such multiple ways to solve a problem and also know more about side effects or negative results as you mentioned.

I have to say I do agree, as I was saying its not necessary to do such a task, but either way works, and your right, going through the game, you learn so much more on how the game runs, which opens up a lot of doors for making mods or codes.

HatCat
5th August 2009, 02:42 AM
Now in honesty the fun part is, I don't know MIPS disassembly. :D
As you can see I'm limited to things like dividing generation languages, but as far as actual programming, currently I'm caught up in this philosopher's life. Today I study things like that and chess, and when I am free of The Fat Man's grasp, then I'm under my own roof, and I can keep learning about software programming. Right now though it's hard to, get around with him in the way you know

Measuring in entirety, getting used to the hard way isn't completely beneficial. Regardless of whether I've learned to follow x asm yet I'm all for the easy way. Currently memory searching or the method you've suggested is still my only way and fun enough. :)

Any hacking I ever did was nothing from reading. It was all my own experiment.

Zeth Alkar
5th August 2009, 09:17 PM
Now in honesty the fun part is, I don't know MIPS disassembly. :D
As you can see I'm limited to things like dividing generation languages, but as far as actual programming, currently I'm caught up in this philosopher's life. Today I study things like that and chess, and when I am free of The Fat Man's grasp, then I'm under my own roof, and I can keep learning about software programming. Right now though it's hard to, get around with him in the way you know

Measuring in entirety, getting used to the hard way isn't completely beneficial. Regardless of whether I've learned to follow x asm yet I'm all for the easy way. Currently memory searching or the method you've suggested is still my only way and fun enough. :)

Any hacking I ever did was nothing from reading. It was all my own experiment.

I know whatcha mean.

HatCat
6th August 2009, 02:11 AM
The last thing I have tried with Zelda recently was I used WinMerge to trace differences between versions 1.0, 1.1, and 1.2 of Legend of Zelda, The: Ocarina of Time. Most isolated addresses I couldn't find the purpose of just by looking.

I can recognize as 32 bits textures but don't know anything about the audio format. There were some consistencies in some groups of changed values that tell me disassembly would be needed...when I viewed the game in Niew64 its MIPS viewer justifies these patterns as changed inputs for some register function I guess.

I've been wanting to learn about the purpose of all the 64 beginning bytes in a ROM image file header. What I found that isn't documented is that 0x3F actually stores the release build number. So like for v1.0, 1.1 and 1.2 the respective values in that header address are 0x00, 0x01, and 0x02. Things I haven't found or read about were 0x0E and 0x0F, which seem to have no relation to the fields I could identify.
Also the range 0x04 to 0x07 is uniquely changed for Star Wars: Shadows of the Empire, and I have no idea what's unique about the game to justify only this.