Register | Login | |||||
Main
| Memberlist
| Active users
| ACS
| Commons
| Calendar
| Online users Ranks | FAQ | Color Chart | Photo album | IRC Chat |
| |
Acmlm's Board - I2 Archive - - Posts by VL-Tone |
Pages: 1 2 3 4 5 6 7 8 9 10 |
User | Post | ||
VL-Tone Red Cheep-cheep Level: 23 Posts: 141/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 stag019 It means that you just have to change 1A0C0009003573500035ED10 at 49DFD4 to 1A0C00090031E1D000326E40 to have LLL textures in WF Or... Change 1A0C00090031E1D000326E40 at 48D03C to 1A0C0009003573500035ED10 to have WF textures in LLL. I hope it makes more sense Edit: Sukasa, I don't have anything that comes to mind as to a pointer that would be useful to be found in RAM I'm not saying it couldn't be useful, but really for what I'm working on right now at this moment, I can't think of anything... (edited by VL-Tone on 07-29-05 02:43 AM) (edited by VL-Tone on 07-29-05 02:57 AM) (edited by VL-Tone on 07-29-05 12:27 PM) |
|||
VL-Tone Red Cheep-cheep Level: 23 Posts: 142/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
Doh! Well of course I meant Whomp's Phorteress I also got the LLL textures in WF to work, but I didn't try the reverse. |
|||
VL-Tone Red Cheep-cheep Level: 23 Posts: 143/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
Here is the promised Beta Flower anim! And here is the "public domain" Wet Dry World texture BG. (edited by VL-Tone on 07-30-05 02:34 AM) |
|||
VL-Tone Red Cheep-cheep Level: 23 Posts: 144/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
Oh well I'm back... The Crimson Chin, I'm aware that the n64 doesn't use banks, but there seem to be constants regarding where the MIO0 files are decompressed in RAM. I called them banks because the game seems to load textures and geometry in specific parts of RAM, and those loading addresses are always multiples of 64k (or maybe 128 or 256k...). The "bank" number I was usually refering is the high byte of the addresses referring to MIO0 file content, and this byte is usually not relevant to the position inside the file, you have to substract the base address (high byte + 00 00) to find the address inside the MIO0. I'm very tired so it might be a confusing explanation. Anyhow I guess I should stop using the term "banks" because it confuses people tachyon: My best bet is that you use only a .v64 type Mario 64 ROMs in my editor, it will be improved later to either support both formats or at least prevent you from opening the wrong format. I thought all the warnings on my page and documentation would scare newbies from using my editor, I guess I was wrong zidapi: I should have posted the Beta Egg and Flower earlier, but I was sucked up into the polygon decoding |
|||
VL-Tone Red Cheep-cheep Level: 23 Posts: 145/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
tachyon: I forgot, welcome aboard and really cool nick by the way I hope I wasn't too rough with you with that newbie thing, it's just that my program is not exactly ready for anyone, because it doesn't check if it's the right ROM version. You can use my editor, and don't hesitate to ask me any questions about it, even newbie questions. The same applies to anyone who has downloaded my editor |
|||
VL-Tone Red Cheep-cheep Level: 23 Posts: 146/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 tachyon Maybe you have the european SM64 ROM? You need the US 1.0 version for my editor to work. |
|||
VL-Tone Red Cheep-cheep Level: 23 Posts: 147/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
Hmmm, let me count the number of times someone mentioned that opening a ROM resulted in objects that are misplaced? Ok it's my fault... To end the confusion, I added ROM version checking routines to the editor. Yeah I admit, I should have added these from the start. And, most importantly: the editor will now open and edit US Mario 64 ROMs with either normal or reversed byte ordering. This should cover most formats, .v64, z64 etc. The new version 0.31b is available at: http://membres.lycos.fr/nes3d/M64EditDownload.htm Another important new feature: it will prevent the user from opening a ROM with an incompatible version, like the european PAL version. It does that by checking the MIO0 signature for the level 1 geometry file. This method should be pretty much infallible (knocks on wood) in preventing the opening of a file not handled by the editor. When you try to open an incompatible version, you get an alert dialog box: "Wrong version...". After clicking ok you will be taken to a mostly black screen with only the Open ROM... button working (and the close button!) so you can try another ROM file. |
|||
VL-Tone Red Cheep-cheep Level: 23 Posts: 148/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
Ouch... I'm working on fixing this right at this moment Hopefully it only happens with you fiddle with it too much |
|||
VL-Tone Red Cheep-cheep Level: 23 Posts: 149/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
Do you have version 0.31b? Version 0.31b supports ABCD and BADC ordering. (Edit... ok that's it I quit! ) (edited by VL-Tone on 08-02-05 05:16 AM) (edited by VL-Tone on 08-02-05 05:18 AM) (edited by VL-Tone on 08-02-05 05:40 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? |
|||
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 |
|||
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) |
|||
VL-Tone Red Cheep-cheep Level: 23 Posts: 153/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
Hey sorry guys, I won't be able to post much today and tomorrow and in the next few days. (I hope the glue on the topic will hold!) The main reason is that Metroid Cubed, on my page, was featured on g4tv's "Attack of the show". Yeah, Metroid Cubed was seen on mainstream TV I got like 10,000 visitors in one day and it generated like a 100+ threads and blog entries everywhere on the Web. So now I have too many emails to reply to, and since I got a couple of offers for a domain name and hosting, I'm currently busy negotiating the details of it. |
|||
VL-Tone Red Cheep-cheep Level: 23 Posts: 154/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
Hi enathan, For now, we don't know how to change a goomba into a Mario, but it's a great idea. We are not up to the point we can do that. It may be possible in the future, but I don't think we are even near doing that. Changing a goomba to use the Mario shape is one thing, but we would also have to make it behave like a running Mario. Since it's really about Mario 64, you should have posted this in the Mario 64 sticky post at the top. Normally I would have been one of the people replying there, but like I said, I have been busy lately. Anyway, just be patient |
|||
VL-Tone Red Cheep-cheep Level: 23 Posts: 155/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
Hi there! I'm back from the moon! I'm still a little busy on other things, but here is a quick cool hack I did: Here is the IPS patch, to be used on a normal order (ABCD) US Mario 64 ROM http://pages.infinit.net/voxel/Mario64PeachHead.ips Yeah, it's Mario with Peach's head She even blinks The only big limitation here is that it only works outside the castle... If you go inside the castle or levels with this patch, very weird things can happen to Mario's head, so be warned! I'll try to answer questions before they are asked (as usual). Q: Can you make Peach's head bigger? A: No, I don't know how to do this (yet). Q: Can you change Mario's head to, let's say a Goomba? A: Yes I can change the head to a Goomba, but only in a level that has them. In theory, outside of the Castle, I could make Mario's head into Yoshi's head, if it's not stuck to his body. But I don't know where Yoshi's geometry is. Q: Could you change Mario's body to Peach's body? A: I don't know if Peach even has legs in Mario 64, and that could be a problem Q: What does the IPS patch changes? A: At 127CBC in ROM, it replaces:
with:
Q: How can I change it myself to other things? A: It's complicated, for now, and you cannot change it to objects not used in a level and this is a limitation of the game. Some other problems include that some objects will appear sideways as Mario's head. I'll try to explain how it was done soon. Kawa-oneechan: Really neat data you got there about Mario's moves It will be useful for sure! Wouldn't that be fun if one day the motion capture data from SM64 is cracked and that some people start to record new moves for Mario? Sure it requires a motion capture device, but ping pong balls and a few cheap cameras can do the trick! By the way Bob-Omb's Battlefield geometry is in the MIO0 file at 003FC2B0. The level (1) layout starts at 405A60. Command 3908 loads the "other" object layout data that is inside the MIO0 file (coins etc.) This is the one that has two sets of 256 objects that are mostly documented. Each one of these objects is 10 bytes, the first two bytes being for horizontal rotation and type, then X Y Z in 16-bits signed integers, and the last two bytes are some parameter. Since you guys documented types for these objects using a sign as a basis, which used a specific parameter, it broke some objects that crashed when this parameter was used. The [!] boxes of a single type can have a different content and color depending on which value is used as a parameter. I've began integrating these objects into my editor. Back in the main layout data for Level 1 that starts at 405A60: The 180C command will load the different MIO0 files for the level, and the 170C command points to the "geometry layout" data for this particular MIO0 file. The geometry layout data is using yet another set of commands and is also uncompressed in ROM. "15" commands like those pointing to Mario's head, point to an address inside a specific MIO0 file in RAM that is the starting point for the geometry data itself for a particular part or animation frame. That's all for now Have Fun! |
|||
VL-Tone Red Cheep-cheep Level: 23 Posts: 156/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
I think it's a table pointer, but I have not verified it. The text messages from friendly bob-ombs in the uncompressed object layout data are referred by a table pointer. I would love to hear Bowser's laugh at "normal" speed, instead of the slowed down version in the game (or accelerated one for Boo's) By the way anyone of you tried the ips patch for Mario with Peach's head? I know it's a little freakish, but it's very funny in action Anyway it's not like I spent much time on it, I was studying the data when I realized I could do this hack pretty easily from what I knew, but it was never like a goal to me. (edited by VL-Tone on 08-20-05 09:14 PM) (edited by VL-Tone on 08-20-05 09:18 PM) |
|||
VL-Tone Red Cheep-cheep Level: 23 Posts: 157/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
I did my own documentation about the item format a long time ago, it's not complete nor perfect, but it can be a start to understand how it works: http://membres.lycos.fr/nes3d/MetroidItemData.txt Actually, complete item support is one of the few things still missing from Metroid Cubed (powerups are shown, with some exceptions, but enemies generated by items don't) |
|||
VL-Tone Red Cheep-cheep Level: 23 Posts: 158/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
Wow SML hacking at last! Great jorb guys! SML is one of the game I wish to be seen hacked/edited, (since I played it alot when I had my gameboy in 1988) In the "did you know that" section: Did you know that SML was produced by Gunpei Yokoi and part of the Metroid team? Hip Tanaka (who worked on Metroid) did the music and sfx for SML. He's very good at giving the impression that the gameboy could play more than 3 notes at the same time, even more so since he probably designed the sound hardware for the gameboy. |
|||
VL-Tone Red Cheep-cheep Level: 23 Posts: 159/200 EXP: 64158 For next: 3565 Since: 06-06-04 From: In the Moon! Since last post: 5 days Last activity: 2 hours |
| ||
Cellar Dweller, I've warned people about the head patch only working outside the castle, this is because it's the only place Peach's geometry is loaded. Maybe I should have been more clear that it could crash the game, though I didn't know Windows could lock because of an emu. Anyway great info you got there, as usual I guess I should try to find these docs, but I try to keep my reverse-engineer "clean". I don't know... everything I found until now has been without the docs (earlier info you posted confirmed things I already figured out), and some of these routines are probably patented, so it doesn't matter that I own the SM64 ROM, they could sue my butt off if I publish an editor based on trade-secrets. I think they tolerate what we are doing, but we shouldn't push our luck too far... But as for the commands you described, do you have any concrete example of them in the game? As for the "Area of the RSP's RAM to place the data: 0x06=Segment table" I think it's what I referred (incorrectly) as RAM banks. For example, Mario's geometry is loaded in "bank" 04. RT-55J thanks for the sample Was it part of a mailbag entry on TMK? If so can you link it? (edited by VL-Tone on 08-23-05 06:34 PM) |
|||
VL-Tone Red Cheep-cheep Level: 23 Posts: 160/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 Keitaro I said that he probably did. Let me tell you why I think so. First, Hirokazu "Hip" Tanaka, for his first job at Nintendo designed the sound hardware (and software) for the original Donkey Kong arcade machine. I would assume he had at least a small role in designing the NES/Famicom sound hardware having previous experience at that. Tanaka was part of R&D1, directed by Gunpei Yokoi (part of R&D1 became intelligent systems http://intsys.co.jp). He did the music for most of the first small NES games like Balloon fight, Gyromite, Duck Hunt and others (Like Metroid!). He also wrote his own tools to generate music and sfx for the NES. The GameBoy was designed by the R&D1 team, and Tanaka was a hardware and software sound engineer so he probably at least co-designed the GameBoy sound hardware. SML really looks like it was the first game designed for the GB, and the game probably evolved as they were designing the HW, so it was best for them to have a sfx and music composer working on the HW. Another thing pointing to an involvement in the GB hardware is that Tanaka in fact designed the GameBoy Camera hardware, and directed the software aspect (I'm betting that he coded the DJ mini-game himself). Anyhow, let's get back to Super Mario Land hacking (sorry for the off-topic post). (edited by VL-Tone on 08-23-05 07:08 PM) |
Pages: 1 2 3 4 5 6 7 8 9 10 |
Acmlm's Board - I2 Archive - - Posts by VL-Tone |