Register | Login
Views: 19364387
Main | Memberlist | Active users | ACS | Commons | Calendar | Online users
Ranks | FAQ | Color Chart | Photo album | IRC Chat
11-02-05 12:59 PM
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
Posted on 07-29-05 11:39 AM, in Mario 64 - Amazing Stuff Link
Originally posted by stag019
So, uhhh, what exactly does this all mean? How can we fix it?


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
Posted on 07-29-05 09:29 PM, in Mario 64 - Amazing Stuff Link
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
Posted on 07-30-05 10:43 AM, in Mario 64 - Amazing Stuff Link
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
Posted on 08-01-05 11:59 AM, in Mario 64 - Amazing Stuff Link
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
Posted on 08-01-05 01:57 PM, in Mario 64 - Amazing Stuff Link
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
Posted on 08-02-05 12:42 AM, in Mario 64 - Amazing Stuff Link
Originally posted by tachyon
thanks for the warm reception! I found a byte-swapper in my overflowing Downloads folder, and successfully made a .v64 backup. but I still have the same problem.

about the name, a tachyon is a theoretical particle that moves faster than light. it has never been proven to exist.



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
Posted on 08-02-05 01:47 PM, in Mario 64 - Amazing Stuff Link
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
Posted on 08-02-05 02:00 PM, in Mario 64 - Amazing Stuff Link
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
Posted on 08-02-05 02:09 PM, in Mario 64 - Amazing Stuff Link
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
Posted on 08-05-05 12:09 PM, in Mario 64 - Amazing Stuff Link


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
Posted on 08-06-05 12:41 PM, in Mario 64 - Amazing Stuff Link
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
Posted on 08-08-05 12:56 PM, in Mario 64 - Amazing Stuff Link
Originally posted by eNathan
Originally posted by stag019
How did you use Project 64 to change the RAM? I had to download Nemu64.
Originally posted by eNathan
Would anyone happen to know the pointer address to mario.
Im not exactly sure what you mean by this, could you explain a bit more?
Originally posted by eNathan
...they seem to be dynamic...
I'm not sure what you mean by this either.Could you explain this too?


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


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.


18 0C 00 07 00 44 AB C0 00 45 45 E0 -- Decompresses the castle geometry MIO0 data in RAM
18 0C 00 0A 00 2A C6 B0 00 2B 8F 10 -- Decompresses cloud and water background in RAM
1A 0C 00 09 00 35 ED 10 00 36 59 80 -- Decompresses other castle textures in RAM
18 0C 00 05 00 16 D8 70 00 18 05 40 -- Decompresses Peach geometry
17 0C 00 0C 00 18 05 40 00 18 0B B0 -- Decodes Peach geometry
18 0C 00 06 00 1D 83 10 00 1E 4B F0 -- Decompresses Toad, Lakitu and MIPS geometry in RAM
17 0C 00 0D 00 1E 4B F0 00 1E 51 F0 -- Decodes Toad, Lakitu geometry
18 0C 00 08 00 1F 22 00 00 20 08 D0 -- Decompresses [!] boxes and other common objects in RAM.
17 0C 00 0F 00 20 08 D0 00 20 14 10 -- Decodes [!] boxes etc. geometry

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
Posted on 08-11-05 08:53 AM, in Mario 64 - Amazing Stuff Link
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
Posted on 08-11-05 09:10 AM, in How to clone a player (like Mario). Link
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
Posted on 08-20-05 01:58 PM, in Mario 64 - Amazing Stuff Link
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:

15010000040119A01501000004011A901501000004011B801501000004011C701501000004011D601501000004011E501501000004011F401501000004012030

with:

1501000005005CE01501000005005D381501000005005D901501000005005DE81501000005005E401501000005005E981501000005005EF01501000005005F48


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
Posted on 08-21-05 06:13 AM, in Mario 64 - Amazing Stuff Link
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
Posted on 08-21-05 06:41 AM, in Problem with metedit Link
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
Posted on 08-21-05 06:55 AM, in Mario Land Enemy/Object Data Complete! Link
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
Posted on 08-24-05 03:33 AM, in Mario 64 - Amazing Stuff Link
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
Posted on 08-24-05 04:07 AM, in Mario Land Enemy/Object Data Complete! Link
Originally posted by Keitaro
Hip Tanaka designed the sound hardware? News to me *shrug*. And HH, yer thinking of SML2


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


ABII


AcmlmBoard vl.ol (11-01-05)
© 2000-2005 Acmlm, Emuz, et al



Page rendered in 0.038 seconds.