Register | Login | |||||
Main
| Memberlist
| Active users
| ACS
| Commons
| Calendar
| Online users Ranks | FAQ | Color Chart | Photo album | IRC Chat |
| |
1 user currently in Rom Hacking: |
Acmlm's Board - I2 Archive - Rom Hacking - Mario 64 - Amazing Stuff | | | |
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 | Add to favorites | "RSS" Feed | Next newer thread | Next older thread |
User | Post | ||
stag019 Snifit Level: 23 Posts: 230/299 EXP: 62259 For next: 5464 Since: 06-10-05 From: C:\Documents and Settings\stag019\Desktop Since last post: 9 days Last activity: 7 hours |
| ||
Well, it should appear in the drop down menu. Odd. Read the help file. | |||
tachyon Octorok Level: 7 Posts: 8/23 EXP: 1089 For next: 359 Since: 07-28-05 Since last post: 5 days Last activity: 10 hours |
| ||
it talks like I can just start it up and play a game (which I can't). what's a GUI file? it mentions them. | |||
stag019 Snifit Level: 23 Posts: 237/299 EXP: 62259 For next: 5464 Since: 06-10-05 From: C:\Documents and Settings\stag019\Desktop Since last post: 9 days Last activity: 7 hours |
| ||
Tachyon, I'll PM you eventually. Sukasa, if you still want to fiddle around with stuff, here's a GS code. D033AFA1 0020 803474A4 0001 Pressing L will make the first Bob-omb dissapear, so fiddle with 803474A4. VL-Tone, can you rip the texture on the fountain in the back of the castle? And where has everyone gone? This place hasn't had a post since 08-02-05 12:49 PM!!!! (edited by stag019 on 08-05-05 12:56 AM) |
|||
VL-Tone Red Cheep-cheep Level: 23 Posts: 150/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
Please don't tell me you really think you that texture reads "L is real 2041" ... In my latest experiments confirm that if you change only the level geometry (in a savestate), Mario won't care and instead the original ground collision (This was noted in the first page of this thread). I'm pretty sure I found where the ground collision data is, and hopefully the way it's stored, it would be relatively easy to make an editor that can move any vertex in the level and also change the polygon collision data at the same time. It's located after the geometry data for each level in the MIO0 file. It's loaded with command 2E in the object layout data (the one that includes command 24). For example the castle collision data is loaded with this command 2E 08 00 00 07 00 F3 A0. The address inside the MIO0 file in this case is 00F3A0. It's a plain list of vertex, and all can be found in the geometry data before. At 00F3A2 you can find the number of vertex in the list as a 16-bit integer. Each vertex entry is 6 bytes long, 2 bytes per axis, 16-bits signed integers. After that is a list of numbers that refer to the vertex list before. The problem is that I couldn't confirm this one, as changing the presumed collision data in a savestate or in RAM didn't have any effect when resuming the game. I suspect that this data is used only once when the level is loading, and results from calculations on the collision data is stored elsewhere in RAM. Unless I can stop the emu exactly after it decompressed the MIO0 file in RAM and before it reads and convert the collision data, it's impossible to edit the collision data in RAM and see the results. This problem only happens when I try to test it in RAM, and modifying the MIO0 file and reinserting it in the game would likely work. Anyway it shouldn't matter that much once we can edit MIO0 files without worrying about recompressed size. I don't have much time these days to hack, but overall things look good for the future. (Full Mario level editor by 2007? ) Oh and by the way, I probably said it many times, but if anyone wants to program and release a competing editor, I'm all for it I have a simple question for those in the know, can you simply extend the Mario 64 ROM much like you can do with SNES carts like StarFox, by appending 32k or maybe 256k(?) blocks of stuff like "FF" at the end of the ROM file? Or do you have to modify the header and other things? |
|||
Cellar Dweller Flurry !!! Level: 27 Posts: 235/269 EXP: 107817 For next: 8342 Since: 03-15-04 From: Arkansas Since last post: 16 days Last activity: 34 min. |
| ||
Well, I just pasted a second copy of the SM64 ROM onto the end of itself, and added 0x800000 to the begin and end pointers of the Bob-Omb battlefield file. The level loaded as normal. I then zeroed out the second copy at the end, pasted the battfied file at 0x800000, and adjusted the pointers. The level loaded as normal. Finaly, I inverted a section of the file I had placed at 0x800000, and then it did not work. Testing was done with Project 64 and 1964, so SM64 can be expanded, at least for playing on emulators. I have found and decompiled two functions that call the decompressor into C like pseudocode. They both seem to accept three parameters, a start, an end, and one of unknown purpose. See http://s91407720.onlinehome.us/acmlmboard_files/romhacking/sm64/uncompress_calling_functions.txt for a messy, but somewhat useful, decompiling job. One of them is hardwired to decompress to 0x801C1000 in RAM. I'm also working on a simple command line disassembler that puts out code that is easer to read than output from 64DISASM, and can be saved to a text file with redirection. |
|||
HyperLamer <||bass> and this was the soloution i thought of that was guarinteed to piss off the greatest amount of people Sesshomaru Tamaranian Level: 118 Posts: 6306/8210 EXP: 18171887 For next: 211027 Since: 03-15-04 From: Canada, w00t! LOL FAD Since last post: 2 hours Last activity: 2 hours |
| ||
033948 10 00 00 01 beq r0, r0, 1 no... 03394c 00 00 00 00 nop ...thing ??? The game seems to do this a lot. Anyone have any idea why? As for that function that decompresses to a fixed address, notice that it does a few other things after decompression... probably there to handle one specific thing, like textures or sounds or something. |
|||
Sukasa Boomboom Error 349857348734534: The system experienced an error. Level: 57 Posts: 1573/1981 EXP: 1446921 For next: 39007 Since: 02-06-05 From: *Shrug* Since last post: 6 days Last activity: 1 day |
| ||
I'll check that GS code. Perhaps it changes a sprite table? That would be interesting... | |||
stag019 Snifit Level: 23 Posts: 242/299 EXP: 62259 For next: 5464 Since: 06-10-05 From: C:\Documents and Settings\stag019\Desktop Since last post: 9 days Last activity: 7 hours |
| ||
Thanks, Sukasa. VL-Tone, I only kinda think it says L is real 2041 or 2401 or whatever. I'm not obbsesed with it out think it has to do with Luigi! And you better thank me for telling you to edit the savestate. |
|||
Kario In Possession of a Stolen Shovel Level: 65 Posts: 1975/2082 EXP: 2321379 For next: 14249 Since: 03-15-04 From: Texas... Yeehaw! Since last post: 2 days Last activity: 17 hours |
| ||
Someone should edit the gfx for that sign to make it clearly say "This says nothing" | |||
VL-Tone Red Cheep-cheep Level: 23 Posts: 151/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
Thanks Cellar Dweller, it's good to know that you can expand the ROM just like that! I guess I'll get back at coding my own MIO0 compressor. It's not hard, but I'm trying to optimize the speed and output and I don't have too many cycles to spare stag019, sorry I recently read a thread about "L is Real 2041" speculation on another site and I guess that's why I was a little worked up about it. As for editing the savestate, it's not like I didn't thought about doing it before, but the last time I checked I wasn't able to find anything. This was a long time ago and I kind of forgot about the possibility of doing it, I had other things to keep me busy hacking SM64 without having to mess up with RAM. When we chatted about replacing the decompressed Mario head MIO0 file in RAM with a Luigi-like head, it got me thinking about editing the savestate again, and I realized that the problem I had last time was because the savestates are compressed (in gzip) for my emu. After decompressing it, I found the Mario head data and replaced it with the Luigi head data I created. Kario LOL that's really funny (well in my point of view at least) In the same line of thought we could modify the texture so it could clearly read: "Nothing to read here", "Unreadable", "Don't look here", "Japanese characters" or "Each letter is 2 pixel wide" Or maybe we could put the picture of a naked chick and get quoted on CNN |
|||
KTurbo Paragoomba Level: 15 Posts: 57/78 EXP: 15418 For next: 966 Since: 06-19-04 From: Swe Since last post: 8 days Last activity: 30 min. |
| ||
Originally posted by VL-Tone Yep, go with that. :O |
|||
Cellar Dweller Flurry !!! Level: 27 Posts: 236/269 EXP: 107817 For next: 8342 Since: 03-15-04 From: Arkansas Since last post: 16 days Last activity: 34 min. |
| ||
Originally posted by The Crimson Chin Games for the N64 and newer systems tend to be written in high level languages like C/C++. The extra usless bits of code may be caused by a compiler that lacks the ability to optimize the code fully, or some optimizations were turned off. The benefit of compiler generated code to ROM hacking is that the code will tend to be grouped together in functions with well defined start and end points. Also SGI/Nintendo created a high level library, called "Ultralib", that N64 games all use almost exclusively vs direct hardware access. The functions in Ultralib can be scanned for and calls to them can thus be found. USF rippers have been taking full advantage of this to peform thier task. I think that those other function calls are more likely to be for memory management, or some other general task. |
|||
HyperLamer <||bass> and this was the soloution i thought of that was guarinteed to piss off the greatest amount of people Sesshomaru Tamaranian Level: 118 Posts: 6334/8210 EXP: 18171887 For next: 211027 Since: 03-15-04 From: Canada, w00t! LOL FAD Since last post: 2 hours Last activity: 2 hours |
| ||
I know C/C++ isn't totally efficient, but it really seems odd to just stick random instructions in that don't do anything. I bet a list of those functions' addresses and parameters could be really useful. |
|||
Cellar Dweller Flurry !!! Level: 27 Posts: 237/269 EXP: 107817 For next: 8342 Since: 03-15-04 From: Arkansas Since last post: 16 days Last activity: 34 min. |
| ||
The location of the functions differ from game to game, so they must be scanned for. hcs and someone42 have created files to use with IDA Pro to find them in a savestate. I don't have IDA Pro and I'd rather not try to use a copy from a warez site. hcs posted a utility on the USF site that can read a certain format of object file that is used in N64 development that Ultralib can be found in and produce a searchable pattern. As for information on parameters, I have such information. I think that I have the, uh, same thing that Interdpth mentioned earler in this thread. There is also lots of useful stuff in a repository of open source N64 stuff that hcs put up on SourceForge.net. Like (part of) a program to decode N64 drawing lists. |
|||
HyperLamer <||bass> and this was the soloution i thought of that was guarinteed to piss off the greatest amount of people Sesshomaru Tamaranian Level: 118 Posts: 6349/8210 EXP: 18171887 For next: 211027 Since: 03-15-04 From: Canada, w00t! LOL FAD Since last post: 2 hours Last activity: 2 hours |
| ||
Well if we at least knew the first 16 bytes or so of these functions, we could write a program to find them. | |||
eNathan Goomba Level: 8 Posts: 2/33 EXP: 1773 For next: 414 Since: 08-07-05 From: United States, but does it matter? Since last post: 1 day Last activity: 8 days |
| ||
Im quite impressed on the gfx hacking that has been done in this thread. I have a question though -- I have been messing around with some mem addresses in SM64, and they seem to be dynamic. I am using Project 64 as my emulator (not sure of a differnt emulator would make the addresses static). Would anyone happen to know the pointer address to mario. THX (=_=) |
|||
stag019 Snifit Level: 23 Posts: 251/299 EXP: 62259 For next: 5464 Since: 06-10-05 From: C:\Documents and Settings\stag019\Desktop Since last post: 9 days Last activity: 7 hours |
| ||
How did you use Project 64 to change the RAM? I had to download Nemu64. Originally posted by eNathanIm not exactly sure what you mean by this, could you explain a bit more? Originally posted by eNathanI'm not sure what you mean by this either.Could you explain this too? |
|||
eNathan Goomba Level: 8 Posts: 3/33 EXP: 1773 For next: 414 Since: 08-07-05 From: United States, but does it matter? Since last post: 1 day Last activity: 8 days |
| ||
Originally posted by stag019 Well, in response to your first response to my coment ...lol I did not use Project 64 to actaully change the data in the RAM. I generally either use a program called Artmoney or TSearch. These programs will "open" a process (in this case, Project 64 emulating Mario 64) and will search its memory for certian data. If your a programmer, you may be farmilar with the API's WriteProcessMemory and ReadProcessMemory which are used to read/write data to/from another program. A pointer address is basicly like this. Lets say marios coins are located at 3B0794DA, his health at 3B0794DD, and his number of lives at 3B0794DE. All those addresses are fairly close to eachother, as they begin with 3B0794D. All of mario's data is somewhere around these adresses also. The 'pointer' to mario is a static adresses which identifies the begining of mario's data AFAK. Dynamic Memory is basicly memory that changes everytime you restart the program. This can be a bitch for memory hacking newbs like me to get around. However, static addresses are always the same. For example, if game uses DMA (Dynamic Memory Allocation) it will locate memory for its variables on a first come first serve kind of basis, so one time mario's health could be 3B0794DD and another time it could be 0CD995DA. Hope this helps |
|||
VL-Tone Red Cheep-cheep Level: 23 Posts: 152/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
Originally posted by eNathanOriginally posted by stag019 Do you know if the data you are looking with Artmoney or TSearch is an exact mirror of the n64 RAM? Maybe it's Project64 that moves things around dymamically? GameShark codes that changes things like Mario's health only deals with fixed addresses, and that doesn't seem to be a problem. The data for Mario's geometry and textures, the level geometry data and some other textures files are loaded at specific places in RAM when the level starts, and those don't move in RAM. I'm not sure you have the right definition of DMA... Here is data found in the ROM at 454AEC, part of the "Level layout data" which loads stuff in RAM while the level is initialized. Other stuff is loaded by other commands not shown here.
Not so far after this data you can find 2E 08 00 00 07 00 F3 A0. Which loads the collision map for the whole level from address F3A0 in the castle geometry file. What I found while trying to make a name list of the possible objects in a level is that unless we edit much more data, we can only use objects that are loaded for this particular level. So you cannot put a Koopa or Goomba in the Castle grounds scene without some rather heavy editing. The other kind of objects found inside the MIO0 level file seems to be shared by all level though, coins, trees, doors etc. (I didn't confirm this, it's a guess) |
|||
eNathan Goomba Level: 8 Posts: 7/33 EXP: 1773 For next: 414 Since: 08-07-05 From: United States, but does it matter? Since last post: 1 day Last activity: 8 days |
| ||
VL-Tone, if im wront about DMA then there must be alot of inaccurate info on the internet (which I should have assumed). Or maybe they were just explaining in a rather simple method, and as a result they had to put a slant on the truth. I am going to download some other emulators to see if the addresses are static. |
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 | Add to favorites | "RSS" Feed | Next newer thread | Next older thread |
Acmlm's Board - I2 Archive - Rom Hacking - Mario 64 - Amazing Stuff | | | |