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
1 user currently in Rom Hacking: hukka | 2 guests
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 33Add to favorites | "RSS" Feed | Next newer thread | Next older thread
User Post
tachyon

Octorok
Level: 7

Posts: 14/23
EXP: 1089
For next: 359

Since: 07-28-05

Since last post: 5 days
Last activity: 10 hours
Posted on 10-14-05 07:57 PM Link | Quote
wooot! it works now. actually, I ditched corn and made PJ64 work without a gamepad by messing with the configuration. I'll start helping now.
EDIT: okay, which parts of the hex code need a MI00 decompressor, and where can I get a decompressor and recompressor?


(edited by tachyon on 10-14-05 11:44 AM)
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: 7706/8210
EXP: 18171887
For next: 211027

Since: 03-15-04
From: Canada, w00t!
LOL FAD

Since last post: 2 hours
Last activity: 2 hours
Posted on 10-14-05 11:29 PM Link | Quote
All the information you seek is located within this thread.

According to this document, 0x10000000 to 0x1FBFFFFF is the cartridge ROM area, which works out to about 250MB. Though there does seem to be a lot of mistakes in it.
tachyon

Octorok
Level: 7

Posts: 15/23
EXP: 1089
For next: 359

Since: 07-28-05

Since last post: 5 days
Last activity: 10 hours
Posted on 10-15-05 02:28 AM Link | Quote
okay, I got the decompressor. unfortunately, I need to unRAR it first, and my unRARer doesn't work. what do you use to unRAR files? does the recompressor come with the decompressor? and do you need a dissasembler to see decompressed ROMs? a tracer would help too...agghhh...this is so complicated!
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: 7719/8210
EXP: 18171887
For next: 211027

Since: 03-15-04
From: Canada, w00t!
LOL FAD

Since last post: 2 hours
Last activity: 2 hours
Posted on 10-15-05 02:29 AM Link | Quote
WinRAR, yes, and no.
tachyon

Octorok
Level: 7

Posts: 16/23
EXP: 1089
For next: 359

Since: 07-28-05

Since last post: 5 days
Last activity: 10 hours
Posted on 10-15-05 03:01 AM Link | Quote
okay, I got WinRAR and extracted it and it still doesn't work! the screen comes up for a split second and then goes away.
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: 7724/8210
EXP: 18171887
For next: 211027

Since: 03-15-04
From: Canada, w00t!
LOL FAD

Since last post: 2 hours
Last activity: 2 hours
Posted on 10-15-05 05:00 AM Link | Quote
Command line programs do that. You need to run the command prompt first (Start -> Run -> command -> OK on 9x/ME, or Start -> Run -> cmd -> OK on NT/2K/XP), and run the program from in there. If you can't figure out how to do that, you need to learn about DOS.
Cellar Dweller

Flurry
!!!
Level: 27

Posts: 268/269
EXP: 107817
For next: 8342

Since: 03-15-04
From: Arkansas

Since last post: 16 days
Last activity: 34 min.
Posted on 10-15-05 01:55 PM Link | Quote
It should not be too hard to create an ASM hack to load the 0x108a40 data predecompressed from some other area. I may be able to do it, if I remember to do it.

Originally posted by HyperHacker
According to this document, 0x10000000 to 0x1FBFFFFF is the cartridge ROM area, which works out to about 250MB. Though there does seem to be a lot of mistakes in it.


AFAIK, N64 games almost never read ROM data from memory mapped areas. They set up DMA tansfers from ROM to RAM and work with data in RAM. Even the function that loads compressed data first allocates RAM for the MIO0 file, uses a DMA transfer to load it into RAM, reads the size form the MIO0 header, allocates that much RAM, calls the uncompress function, and frees the memory holding the compresssed data.

Keeping a bunch of data uncompressed may be a good idea for now, but after the data structure becomes better understood, it may be a good idea for editors to recompress the data on save. An inventory of the assets(textures, models, objects, etc) could be performed by walking the data and translating the information into the editors internal format. When saving, the data is translated back and saved in the game's format.

If anyone is looking for a no-op level command, you can use a 0x24 command with an act mask of zero and the size byte set to how many bytes to skip. The size should be a multiple of four, and a zero size will cause the level loader to hang in an infinite loop. It is also possible to increase the size byte of a command to skip commands after it.
VL-Tone

Red Cheep-cheep
Level: 23

Posts: 184/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 10-16-05 11:16 AM Link | Quote
Originally posted by Cellar Dweller
It should not be too hard to create an ASM hack to load the 0x108a40 data predecompressed from some other area. I may be able to do it, if I remember to do it.

Originally posted by HyperHacker
According to this document, 0x10000000 to 0x1FBFFFFF is the cartridge ROM area, which works out to about 250MB. Though there does seem to be a lot of mistakes in it.


AFAIK, N64 games almost never read ROM data from memory mapped areas. They set up DMA tansfers from ROM to RAM and work with data in RAM. Even the function that loads compressed data first allocates RAM for the MIO0 file, uses a DMA transfer to load it into RAM, reads the size form the MIO0 header, allocates that much RAM, calls the uncompress function, and frees the memory holding the compresssed data.

Keeping a bunch of data uncompressed may be a good idea for now, but after the data structure becomes better understood, it may be a good idea for editors to recompress the data on save. An inventory of the assets(textures, models, objects, etc) could be performed by walking the data and translating the information into the editors internal format. When saving, the data is translated back and saved in the game's format.

If anyone is looking for a no-op level command, you can use a 0x24 command with an act mask of zero and the size byte set to how many bytes to skip. The size should be a multiple of four, and a zero size will cause the level loader to hang in an infinite loop. It is also possible to increase the size byte of a command to skip commands after it.


So is there a 32MB limit on ROM size?

As for compressed data, it's not that I'm to lazy to code a MIO0 compressor, but is there really any use at keeping the compression? Anyway I'm not totally against it, but I would like to know of any reason why we should keep compressed files.

Ok I must admit that the reason I'm inclined to get rid of the compression is that it's too slow in Director/Shockwave (which is, unfortunately, what I'm more experienced in). The rest is fast enough, it has a relatively fast OpenGL or DirectX driven 3d engine.

As I said before if anyone with good C++ and OpenGL experience wants to build a Mario 64 level editor before me I won't mind at all, but if I want to make my editor progress, I need to get rid of the compression. I'm thinking of learning C++ to make a simple program that transforms the ROM into a directly editable uncompressed version that doesn't require to write too much data on saving. By keeping space between the segments in ROM, it avoids having to move big chunks of data when a segment expands. One way or another, the ROM needs to be expanded and MIO0 segments need to be relocated after 0x800000. So I will try to offset this process in C++ to get the needed speed. Once the ROM is transformed, it can be edited and used as is.

An inventory of the assets is a very good idea, but I don't see how compression can help that. By the way from my brief encounters when digging Zelda: OOT, I realized it's organized in a much better way, and that there is probably a directory of all assets somewhere. Mario 64 doesn't have that, as you said you have to walk the script to find offsets for the different parts. Most offsets refer to RAM segments and we have to keep track of which data is loaded in which segment. My current editor does that, and it has too, since there is some skipping between segments happening in level loading scripts.

That 0x24 command used as a no-op should be very useful along the way of improving the editor. I wish I found a similar command to use in StarFox.

Ok, I'm on my way to make an improved Mario 64 hacking document...
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: 7763/8210
EXP: 18171887
For next: 211027

Since: 03-15-04
From: Canada, w00t!
LOL FAD

Since last post: 2 hours
Last activity: 2 hours
Posted on 10-16-05 11:33 AM Link | Quote
Imagine downloading a patch that doesn't compress it on dialup. No reason the editor can't store things uncompressed, but have an option to compress everything before you release the hack.
VL-Tone

Red Cheep-cheep
Level: 23

Posts: 185/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 10-16-05 12:45 PM Link | Quote
Originally posted by HyperHacker
Imagine downloading a patch that doesn't compress it on dialup. No reason the editor can't store things uncompressed, but have an option to compress everything before you release the hack.


RAR, ZIP or GZIP could do the same job to compress a patch as MIO0. And also, blank space can be compressed by a large amount, to only a few bytes.

Cellar Dweller

Flurry
!!!
Level: 27

Posts: 269/269
EXP: 107817
For next: 8342

Since: 03-15-04
From: Arkansas

Since last post: 16 days
Last activity: 34 min.
Posted on 10-16-05 02:19 PM Link | Quote
I really don't know what the size limit is. IIRC, the N64 cart pinout has 16 address/data lines, an alel(address latch enable, low) line, an aleh(address latch enable, high), a read line, and some other clocking/save/lockout stuff. This suggests that the max size is 4G by 16 bits, or 8 GB. The hardware register for controlling the start of the transfers is 32 bits. I just don't know what the max size is. It may be much less than suggested here.
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: 7774/8210
EXP: 18171887
For next: 211027

Since: 03-15-04
From: Canada, w00t!
LOL FAD

Since last post: 2 hours
Last activity: 2 hours
Posted on 10-17-05 12:49 AM Link | Quote
But why waste the HD space? Even if you do have tons, you may as well compress things when it makes no noticable performance difference and saves a fair bit of space.
VL-Tone

Red Cheep-cheep
Level: 23

Posts: 186/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 10-17-05 08:40 AM Link | Quote
Originally posted by HyperHacker
But why waste the HD space? Even if you do have tons, you may as well compress things when it makes no noticable performance difference and saves a fair bit of space.


Why? Because I have no choice, Director/Shockwave is too slow in itself to decode and encode MIO0 files at a reasonable speed. My solution for my particular problem was to have an external C++ program preparing the ROM for more direct editing of the file. I guess I could make my editor call another external C++ program to re-compress MIO0 files and reinsert them.

Anyhow what I was proposing was a much easier solution for me and I didn't thought that "wasting" 8-16 megs on a multi-gig HD was that bad (for the environment I guess?). I never proposed that it was the best way to do things, or that other people working on an editor should do the same.

I'll stop dragging this thread into my own development platform problems, and I'll deal with those myself and with the help of people on another site, since I guess everyone here that could help me solve my "particular" problems will tell me to change dev platform and learn C++ and OpenGL.

I'll still post everything I find in Mario 64 on this thread, and any future public release of my editor, but I guess that I'll be less pro-active. I'm not mad or anything, but I'll stop wasting your time with my choice of development environment.

Bah ok I have to admit, I'm somewhat mad... not against any of you... but against myself and the situation itself.

Oh well I'll calm down, it's just a thread on a forum on the internet after all...
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: 7794/8210
EXP: 18171887
For next: 211027

Since: 03-15-04
From: Canada, w00t!
LOL FAD

Since last post: 2 hours
Last activity: 2 hours
Posted on 10-18-05 12:51 AM Link | Quote
That's why I said...
Originally posted by HyperHacker
No reason the editor can't store things uncompressed, but have an option to compress everything before you release the hack.
VL-Tone

Red Cheep-cheep
Level: 23

Posts: 187/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 10-18-05 05:08 AM Link | Quote
Originally posted by HyperHacker
That's why I said...
Originally posted by HyperHacker
No reason the editor can't store things uncompressed, but have an option to compress everything before you release the hack.



Ok then everything is fine, everyone is happy Forget about my rant, I had a stressful day at work...

Edit: I made a major update to my Mario 64 ROM hacking doc found at http://pages.infinit.net/voxel/Mario_64_Hacking_Doc.txt

Since some are too lazy to click URLs I'll paste what's new (it's very long).

------------------------------------
| Level Layout Script Commands |
------------------------------------

The level layout commands are used to load everything in the level and placing objects and
geometry.
The second byte of level layout commands is always the length byte.
Hex examples that are provided are from Level 1 (Bob omb's Battlefield) that starts at 405A60
in ROM.
They are shown in the order they are found in the decoded level script, starting at
405A60+0x264.
------------------------------------

[1B] [04] [00 00]

[1]: 1B= Starts a RAM loading sequence (for command 0x17, 0x18 and 0x1F)
[2]: Length byte (dec 4)
[3,4]: Always 00

------------------------------------

[18] [0C] 00 [07] [00 3F C2 B0] [00 40 5A 60]

[1]: 18= Decompress MIO0 data from ROM and copy it into a RAM segment
[4]: RAM segment to copy data to
[5,6,7,8]: Start address in ROM of MIO0 data
[9,10,11,12]: End address in ROM of MIO0 data

------------------------------------

[17] [0C] 00 [0C] [00 13 B5 D0] [00 13 B9 10]

[1]: 17= Copy uncompressed data from ROM to a RAM segment
[2]: Length byte (dec 12)
[4]: RAM segment to copy data to
[5,6,7,8]: Start address in ROM of uncompressed data
[9,10,11,12]: End address in ROM of uncompressed data

------------------------------------

[1D] [04] [00 00]

[1]: 1D= Ends a RAM loading sequence (for command 0x17, 0x18 and 0x1F)
[2]: Length byte (dec 4)
[3,4]: Always 00

------------------------------------

[25] [0C] [00 01 00 00 00 01] [13 00 2E C0]

[1]: 25= Loads Mario object, points to it's behavior code.
[2]: Length byte (dec 12)
[3,4,5,6,7,8]: ?? some parameters to be fed into the behavior code
[9,10,11,12]: Behavior code address, including segment number?

------------------------------------

[06] [08] 00 00 [15] [00 06 60]

[1]: 06= Makes the Level layout script jump to another address (and continue decoding from
there)
[2]: Length byte (dec 8)
[4]: RAM segment number to jump to
[5]: Offset in segment where to jump

------------------------------------

[07] [04] [00 00]

[1]: 07,0A= Jumps back to after the last 0x06 command was called
[2]: Length byte (dec 4)
[3,4]: Always 00

------------------------------------

[22] [08] 00 [36] [0E] [00 05 80]

[1]: 22= Loads polygon object using geometry layout data found at address, and associates an
ID number.
[2]: Length byte (dec 8)
[3]: Always 00?
[4]: ID number that will be used to insert object in level using command 0x24
[5]: RAM segment number in RAM where to find geometry layout data
[6,7,8]: Offset in segment number

------------------------------------

[21] [08] [40] [84] [08] [02 5F 08]

[1]: 21= Loads polygon object data directly without using geometry layout data
[2]: Length byte (dec 8)
[3]: ??
[4]: ID number that will be used to insert object in level using command 0x24
[5]: RAM segment number where to find geometry layout data
[6,7,8]: Offset in segment number

------------------------------------

[1F] [08] [01] [00] [0E 00 04 88]

[1]: 1F= Loads LEVEL polygons using geometry layout data found at address, and associates an
ID number. Also delimits the start of a particular area in a level.
[2]: Length byte (dec 8)
[3]: Area number in level
[4]: Always 00?
[5]: RAM segment number where to find geometry layout data
[6,7,8]: Offset in segment number

------------------------------------

[24] [18] [1F] [36] [0D 3E] [00 00] [01 80] [00 00] [00 B4] [00 00] [00 00 00 00] [13] [00 42 84]

[1]: 24= Places an object in level at X Y Z position and rotation, with some parameters.
[2]: Length byte (dec 24)
[3]: Course(s) on which the object will appear, as binary value
[4]: ID number of the object, as defined by a previous 0x22 command
[5,6] [7,8] [9,10]: X Y and Z position in level as 16-bit signed integers
[11,12] [13,14] [15,16]: X Y and Z rotation as 16-bit signed integers
[17,18,19,20]: Parameters to be fed into the behavior code, varies depending on which behavior
[21,22,23,24]: RAM segment number and offset for behavior code to be attached to this object

------------------------------------
[26] [08] [0A] [09] [01] [0A] [00 00]

[1]: 26= Command that connect warps, level entry and exit points, doors etc.
[2]: Length byte (dec 8)
[3]: Warp ID to jump from (warp ID's are defined with some previous 0x24 commands using
specific behaviors)
[4]: Course ID number to warp to (Course ID's are defined from previous 0x0C commands)
[5]: Course area/part to jump to (ie, main level and bonus slide areas)
[6]: Warp ID number in destination level area
[7,8]: Always 00 00?

------------------------------------

[28] [0C] [00 01 00 00 00 00 00 00 00 00]

[1]: 28= Sometimes seen after 0x26 commands, near the end, I don't know it's use
[2]: Length byte (dec 12)
[3-12]: ??

------------------------------------

[2E] [08] 00 00 [07] [00 E9 58]

[1]: 2E= Loads terrain collision data for level
[2]: Length byte (dec 8)
[5]: RAM segment number (usually 07, the main level polygon data segment)
[6,7,8]: Offset in segment

------------------------------------

[39] [08] 00 00 [07] [01 10 4C]

[1]: 39= Inserts multiple objects found inside main MIO0 level segment
[2]: Length byte (dec 8)
[5]: RAM segment number (usually 07, the main level polygon data segment)
[6,7,8]: Offset in segment

------------------------------------

[30] [04] [00 00]

[1]: 30= Some command sometimes used near the end of level layout
[2]: Length byte (dec 4)
[3,4]: Always 00

------------------------------------

[36] [08] [00 00 00] [03] 00 00

[1]: 36= Music command
[2]: Length byte (dec 8)
[3,4,5]: Other music parameters
[6]: Song number (see table below)

------------------------------------

[20] [04] [00 00]

[1]: 20= Seems to end area-specific data (started with command 0x1F)
[2]: Length byte (dec 4)
[3,4]: Always 00

------------------------------------

[31] [04] [00 00]

[1]: 31= Some command used near the end of level layout (usually after command 0x36)
[2]: Length byte (dec 4)
[3,4]: Always 00

------------------------------------

[2B] [0C] [01 00 00 87 E6 62 00 00 19 40]

[1]: 2B= Some command used near the end of level layout
[2]: Length byte (dec 12)
[3-12]: No Idea what it does, I didn't try to modify it...

------------------------------------

[11] [08] 00 00 [80 24 BC D8]

[1] 11,12= Some commands used near the end of level layout (0x11 is used, then 0x12)
[2]: Length byte (dec 8)
[4,5,6,7]: Some RAM address, seems to be always the same (8024BCD8)

------------------------------------

[1C] [04] [00 00]

[1]: 1C,04,1E= Some commands used near the end of level layout
[2]: Length byte (dec 4)
[3,4]: Always 00

------------------------------------

[02] [04] [00 00]

[1]: 02= End of level layout data
[2]: Length byte (dec 4)
[3,4]: Always 00

------------------------------------

------------------------------------
| Song values for command 0x36 |
------------------------------------
00-nothing
01-end level
02-SMB music title
03-Bob-omb's Battlefield
04-Inside Castle walls
05-Dire Dire Docks
06-Lethal Laval land
07-Bowser battle
08-Snow
09-Slide
0A-Crash
0B-Piranha plant lullaby
0C-Hazy Maze
0D-Star select
0E-Wing cap
0F-Metal cap
10-Bowser Message
11-Bowser course
12-Star catch
13-Ghost Merry-go-round
14-Start and End Race with Koopa the Quick
15-Star appears
16-Boss fight
17-Take a Key
18-Looping stairs
19-Crashes
1A-Credits song
1B-Crashes
1C-Toad
1D-Peach message
1E-Intro Castle sequence
1F-End fanfare
20-End music
21-Menu
22-Lakitu

------------------------------------
| Object format for command 0x39 |
------------------------------------

Each object loaded with this command is dec 10 bytes long.
[01] [1F] [01 04] [02 DF] [07 80] [00 00]

[1]: Horizontal rotation and object bank number
[2]: Object type (don't know where it's defined, has predefined behavior)
Value 1E or 00 as type will end the object list and complete the 0x39 command.
[3,4] [5,6] [7,8]: X Y and Z position in level as 16-bit signed integers
[9,10]: Object parameters




------------------------------------
| Geometry Layout Commands |
------------------------------------

The geometry layout has its own sets of commands, it doesn't use a length byte.
It contains the hierarchy of parts for a given object, calling polygon data for specific parts
or frames of animation.
I don't know much about the overall structure of the data, it may be some kind of BSP tree.
------------------------------------

[02] [01 00 00] [0E] [00 0B F0]

[1]: 02= Jumps to address in segment, continue decoding from there.
[2,3,4]:??
[5]: Segment number
[6,7,8]: Offset in segment

------------------------------------

[03] [00 00 00]
[1]: 03= Jumps back to after the last 0x02 jump command called
[2,3,4]: Always 00

------------------------------------

[15] [04 00 00] [07] [00 79 40]

[1]: 15,14= Loads polygon commands (RSP graphic lib) for an object part found in MIO0 file.
[2,3,4]: ??
[5]: Segment number
[6,7,8]: Offset in segment

------------------------------------


[18] [00 04 00] [80 2D 10 4C]
[1]: 18,19,0E= I don't know the use of these commands, it points to a RAM address, maybe hooks
for controlling animation of parts?
[2,3,4]: ??
[5,6,7,8]: Some RAM address.

------------------------------------

[04] [00 00 00]
[1]: 04,05,0C= I don't know the exact use of these, they all ends by 00 00 00.
[2,3,4]: Always 00

------------------------------------

[08] [00 00 0A] [00 A0 00 78] [00 A0 00 78]
[1]: 08= Again, I don't know much about this one.
It seems to initialize something since it's often found at the start of geometry layout data...
[5,6,7,8] [9,10,11,12]: Always 00 A0 00 78

------------------------------------
There are a few other commands for the geometry layout data not documented here, they are
mostly 4 bytes commands.
------------------------------------

------------------------------------
| Polygon data Commands |
------------------------------------

[F3] [00 0,0 00] 07 [7F F][1 00]

[1] : F3 = command to load the texture into the texture memory along with more settings
[2,3,4] : the s, t coordinates of the upper left corner of the texture tile in fixed point
format (not used?)
[5] : the tile number on the lower 3 bits
[6,7,8]: width and height of texture represented as a slant. hhhwww
width=256/www*32
height=hhh/32/width

------------------------------------

[FD] [10] 00 00 [09] [00 48 00]

[1]: FD = load texture
[3] : format/pixel size fffpp000
f = format
RGBA = 000 (there are other options)
p = storage size of 1 texel
16 bits = 10 (other options too)
0 = unused

[5]: RAM segment number
[6,7,8]: Offset in segment

------------------------------------

[03] [88] [00 10] [08] [00 C0 90]

[1]: 03= Load color for next triangles.
[2]: When is 0x86, loads the bright color, when 0x88(?) loads darkened color.
[3,4]: ??
[5]: RAM segment number
[6,7,8]: Offset in segment
(colors referred are in 32-bit RGBA format 8888)

------------------------------------

[04] [B0] [00 C0] [07 00 BD 50]

[1]: 04= Loads a chunk of vertices into RSP (The RSP cannot contain too much vertices)
[2] : number of vertices minus one in the high nibble and where in the vertex cache to load in
the low nibble
(eg 0xb+1= 0xc=12 vertices loaded into index 0)
[3,4] : number of bytes of vertex data to load( 16(dec) for each vertex) (redundant?)
[5]: RAM segment number
[6,7,8]: Offset in segment and base address for next triangles.

------------------------------------

[BF] [00 00 00] [00] [28 32 3C]

[1] : BF= Triangle command
[2,3,4] : mean nothing and are likely ignored
[5] : vertex to get normal or color from for flat shading, if flat shading is used; seems to
always be 0.
[6,7,8] : vertex number times 10(dec)

------------------------------------

[06] 00 00 00 [04] [00 CA 00]

[1]: 06= Jumps to another point in the triangle data.
[2,3,4]:??
[5]: RAM segment number
[6,7,8]: Offset in segment

------------------------------------

[B8] [00 00 00 00 00 00 00]

[1]: B8: Command that jumps back to the next command after the last "06" jump (uses a stack)
[2-8]: always zero

------------------------------------

[E6] [00 00 00 00 00 00 00]

[1]: E6= This is just makes the RSP wait until it is not using any textures,
or something like that, in preparation for loading the texture image.
[2-8]: always zero

------------------------------------

Other additional polygon (RSP graphic lib) commands may include:
E7, FC, B6, F5, E8, F2, B7, BA, B9, F8, BC and FB



(edited by VL-Tone on 10-17-05 10:38 PM)
(edited by VL-Tone on 10-18-05 03:10 AM)
(edited by VL-Tone on 10-18-05 03:15 AM)
(edited by VL-Tone on 10-18-05 10:48 PM)
Spekkio

Level: 8

Posts: 22/22
EXP: 1898
For next: 289

Since: 11-29-04
From: End of Time

Since last post: 15 days
Last activity: 70 days
Posted on 10-18-05 11:10 AM Link | Quote
Where can I get Mario64Edit?
VL-Tone

Red Cheep-cheep
Level: 23

Posts: 188/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 10-18-05 12:06 PM Link | Quote
Originally posted by Spekkio
Where can I get Mario64Edit?


My Mario64 prototype editor is not online anymore, it was very limited, only could change a few objects in one level and had a some flaws that made it not so useful. I could put it again online, but only when I moved to my new host.

The version I'm working on is improving and is able to open just about every level, but it will take some time before I can release a new version. Let's say that before the holidays I'll publish a new version


(edited by VL-Tone on 10-18-05 03:07 AM)
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: 7818/8210
EXP: 18171887
For next: 211027

Since: 03-15-04
From: Canada, w00t!
LOL FAD

Since last post: 2 hours
Last activity: 2 hours
Posted on 10-18-05 06:27 PM Link | Quote
Cool. This needs some fixing though.
Originally posted by VL-Tone
[1D] [04] [00 00]

[1]: 1B= Ends a RAM loading sequence (for command 0x17, 0x18 and 0x1F)
[2]: Length byte (dec 4)
[3,4]: Always 00
VL-Tone

Red Cheep-cheep
Level: 23

Posts: 189/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 10-19-05 08:14 AM Link | Quote
Originally posted by Santa Claus
Cool. This needs some fixing though.
Originally posted by VL-Tone
[1D] [04] [00 00]

[1]: 1B= Ends a RAM loading sequence (for command 0x17, 0x18 and 0x1F)
[2]: Length byte (dec 4)
[3,4]: Always 00




Yeah that's the joy of copy and pasting There were 2 other similar mistakes that I fixed. I also changed 2 things because I figured out how they work.

First is the 0x1F command:

[1F] [08] [01] [00] [0E 00 04 88]

[1]: 1F= Loads LEVEL polygons using geometry layout data found at address, and associates an
ID number. Also delimits the start of a particular area in a level.
[2]: Length byte (dec 8)
[3]: Area number in level
[4]: Always 00?
[5]: RAM segment number where to find geometry layout data
[6,7,8]: Offset in segment number


I found out that this command not only loads the geometry data for an area, but also marks the start of an area inside a level (ie. bonus slide), and command 0x20 seems to indicate the end of area specific data. Byte 3 in the 0x1F commands seems to determine/assign the area number, that can be used by the 0x26 warp command for example.

By the way, I successfully merged my newer decoding engine with my old editor, and it can now show and edit %90 of all levels, and thanks to my discovery yesterday, you can select which area to edit inside a level. For now it still edits the 0x24 objects only, but it displays the objects loaded from the 0x39 command too (which are inside a MIO0 file, these are the object that you guys made a list for).

You'll have to accept the following limitations if I release the new editor anytime soon: it requires that you uncompress all MIO0 files from Mario 64 and that you put them in the same folder than the editor. Each file must have its name representing the address where the MIO0 file is found in the ROM. This is the way the MIO0 de-compressor N64UNC found on Dextrose automatically names its output files, I'm not sure if the other MIO0 de-compressors work the same way... I'll probably make the 0x39 objects editable, but it will require people to deal themselves with inserting the data back into the game. (The 0x24 objects are uncompressed in ROM so it won't require that.)

I'll probably add something to edit the music bytes, and I'll work on an interface that would enable to change other things like the 0x22 commands and warps. For now, it will still be cubes representing objects, but I may add the option to make it draw them as is (which currently doesn't always work for all objects, and they don't appear in the right scale)

So Santa I'll probably release something much sooner than expected, before the holidays even start

(Edit: proof reading? what does it mean?)


(edited by VL-Tone on 10-18-05 11:15 PM)
(edited by VL-Tone on 10-18-05 11:20 PM)
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: 7840/8210
EXP: 18171887
For next: 211027

Since: 03-15-04
From: Canada, w00t!
LOL FAD

Since last post: 2 hours
Last activity: 2 hours
Posted on 10-19-05 10:07 AM Link | Quote
Awesome. Now you just need to learn a real programming language.
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 33Add to favorites | "RSS" Feed | Next newer thread | Next older thread
Acmlm's Board - I2 Archive - Rom Hacking - Mario 64 - Amazing Stuff | |


ABII


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



Page rendered in 0.027 seconds.