Points of Required Attention™
Friendly reminder: Please don't respond to spammers! Their posts inevitably get memory-holed when staff get around to, leaving behind an inexplicable tableau of you shouting at nothing and (if they otherwise would have been alone in a thread) dangling posts and wrong postcounts.
Views: 47,686,875
Main | FAQ | Uploader | IRC chat | Radio | Memberlist | Active users | Latest posts | Calendar | Stats | Online users | Search 06-23-18 04:06 PM
Guest: Register | Login

Main - Posts by VL-Tone

Posted on 06-22-07 07:40 AM, in TT64 public beta it's here Link | Quote | ID: 47779

Level: 9

Posts: 1/12
EXP: 2674
Next: 488

Since: 02-22-07

Last post: 3968 days
Last view: 3533 days
Hey I was supposed to start this thread

Nahhh It's ok I don't mind, I didn't have time to post here this afternoon.

So I'm back posting here, though I was already posting, undercover, under the name Concertmate-200. (Look on google and you'll understand the link between these two names)

Just dropping by for now, it's been a stressful day, I got back from work not so long ago. Tonight I'm gonna relax, watch some movies... I need to get my mind set on something else for a few hours. Tomorrow I'm gonna finish the documentation, improve the webpage and fix some bugs.

BTW, did you know that June 23rd 2007 will be the 11th anniversary of SM64's Japanese release?

Drag, I'm aware of the right-click issue, I can't find the solution for now. It's a Director related issue, since even when I disabled all "rightmouseup" handlers in my code, this bug still happens. Right-clicking on anything except the 3d view will trigger this bug, and it only happens on the main interface page... But I'd like to know, when you say it "crashes" what do you mean exactly, is it an OS crash, or a script error?

As for the list box bug, could you please post a screenshot of this? And on what platform did you run it?

Posted on 06-23-07 12:36 AM, in F-Zero? Link | Quote | ID: 48564

Level: 9

Posts: 2/12
EXP: 2674
Next: 488

Since: 02-22-07

Last post: 3968 days
Last view: 3533 days
I did a lot of F-Zero Hacking back in the days, just before I got sucked into SM64 hacking...

I managed to completely decode all tracks at the time, and was working on the AI data.

Higher resolution maps (2048x1024) can be downloaded there: http://homepage.mac.com/qubedstudios/F-ZeroMaps.zip

I remember doing full res maps, but I can't find them...

This is the old archived thread: http://acmlm.no-ip.org/archive2/thread.php?id=821

My English improved a little bit since then

I dug a few things that might help you with A.I. hacking:

Here is some information I found about F-Zero's rival cars A.I.

At 7E0BD3 in wram is the on-track angle of the rival car in practice mode.
It's in 2 degree steps.

If you set this value via a cheat to 00 for example, you'll see that from the start,
the rival car faces left, and when the race start you see it go left and start to bounce
off the green barrier. So other cars do bounce on the barrier in that context,
but alas dont explode.

If you disable the cheat when the car is far away from where it should be,
you'll see that the car turns around and starts to drive toward an imaginary point
farther on the track, and this time it will pass through barriers if it has to.

I don't understand exactly what changes the behavior from bouncing to drive-thru-walls.
But the point it drives to is obviously it's next check point on the track so this pretty
much confirm that F-Zero uses a point-to-point A.I. for cars.

The drive-thru-walls game-genie code (for your car) is very usefull to follow the other car.

Angle values like FF will stop the car, and depending on where it is relative to you it will
either continously rotate on itself or stop rotating. A real speed value is probably near
7E0BD3, I'm looking foward to find it.

Note that the angle value is not exactly absolute, the game will rotate the car until it
reaches the angle stored in 7E0BD3 so turning not instantaneous. Suden 180 degrees
changes may not trigger the rotation.

So here is the way it probably works:
The game calculates the angle between the car and it's next check point.
Then, it stores this angle in 7E0BD3, and the game starts to make the car turn until
it reaches the right angle.

When the car is close enough in distance to the check point, the game steps in so
it aims for the next check point. The checkpoint data probably also includes speed
info for each point so the cars can slow down in some tight turns.

Around 7E0030 in wram there are various position values for the enemy car.
Some 16-bit X and Y pointers for its position on the track and another X and Ys
that seem to be the relative pos between the rival car and your car position.
Also there is 7E0BD3 mirrored near that.
I wasn't able to patch those with cheats, they are probably mirrors too.

Look what I've found... at 7E0D02 in wram is the checkpoint counter for the rival car!

It starts at 00 and increment as the car passes through the check points until 3A
(in Mute City 1) when the car reaches the starting line, then it goes back to 00.
Note that again this apply to the practice mode.

It means there are around 59 ($3A+1) checkpoints in MuteCity 1. Using a cheat you
can patch it to any value in this range and see the car turn around and head towards
this checkpoint. Put 00 in 7E0D02 while the rival car is in the middle of the course,
and you'll see it head for the starting line.

As I predicted, the car won't turn around if it has to do a 180 degree turn, so when it
reaches the check point it start to drive in a straight line, wrapping around the track.
If you then remove the cheat, you'll see that the value was incremented elsewhere
and that it has reached a higher number, and the car will head up to the point it was
supposed to be.

This mechanism is probably used in the grand-prix mode for the cars behind you to catch up.
By incrementing the counter faster than the cars would, it forces them to take short-cuts,
and they catch up with you, maybe it actually fetches them the last checkpoint you activated.

So we're closer than ever to find the actual checkpoint data which must have 59 entries
for Mute City 1.

EDIT: I didn't look for the car abilities values yet, to find them you could make a savestate
for each rival car at the starting line of Mute City 1 in practice mode.
Then you use a cheat finder to see what values are different, if you eliminate things like timers that could be different, you should end up finding data that is specific to each car. Fiddle with
the bytes in ram to see what they do, and then you can try to look for that data in the ROM.

Heian-794 asked me:

VL-Tone, is the car obeying the rules (i. e. not driving over empty space) when you change its next checkpoint?

My answer was:

The car doesn't obey these rules and will drive in a straight line to it's destination point,
even over empty spaces outside the track. But like I said I'm trying to figure out the details,
if you force the car to drive at a specific angle that is not towards the next checkpoint,
it will bounce of barriers like your car.

I'm using different techniques to find these values, to find the checkpoint counter, I ran the cheat
search at various points in the race, looking for values that were higher than the last sample.
Eventually I got down to a dozens of bytes, and by putting them as watch points so they are
showing on the snes screen, I quickly found that one value cycled from 0 to 3A and back to 0
when the car made a complete lap. Since the value was incremented at various time intervals,
it was clear that this counter had to do with checkpoints. Then when I patched the value it
comfirmed that this was it.

I didn't try to find the actual point list since ( I had to go to work until 9:30pm), but I'll start again
after this post. I'm thinking of doing a program that draws paths from a list of 16-bit X and 16-bit Y
values. The program will take the values from the f-zero rom at successive adresses while hoping
to find a track path pattern.

Dang I found the cars A.I. path data in WRAM!!!!!

At $7E11FE in wram the X data is stored in 16-bit chunks.
And at $7E1467 in wram the Y data is stored again in 16-bits chunks.

Look at these pictures (in .png format) of the Mute City I car path.
They were done using a custom tool I made for the occasion.
The map on the background was made with Tyler's set of panels, but half are missing.


-->The first one is drawn only using the high bytes of the data.
-->The second one is using the 16-bit value as normal, note the weird zig-zags this introduce.
-->And the last one is using inverted low bytes (FF-xx) and it seems to correct most anomalies.

Now the data can be found and extracted from savestates, but I cannot find it in ROM.
From what I concluded, the data is built when loading the track by adding a series of values
to the starting positions found at around $16200 in ROM. That explains why the path
of other cars is relative to the starting pos value. You can see that the first values at
$7E11FE and $7E1467 are the same as the starting pos in ROM. Just before each starting
pos values after $16200 in ROM are the checkpoint counts, which is 3A for Mute City I.

Sorry for the long post, but I don't have time to trim it down...

Posted on 06-23-07 03:10 PM, in TT64 public beta it's here Link | Quote | ID: 48897

Level: 9

Posts: 3/12
EXP: 2674
Next: 488

Since: 02-22-07

Last post: 3968 days
Last view: 3533 days
Bug-fix release for Toad's Tool 64, now at version 0.3b.


Fixes are:

•A bad bug in Windows that was triggered when right-clicking causing TT64 to crash or refresh the window was eliminated.
•Some imported textures weren't correctly saved to ROM (creating a dot in the corner). This should now be fixed.
•The "Rotate Camera" button should now be hilighted as it should, when a level is loaded.
•Manually entering decimal values in the parameter bar would cause the wrong number to be entered instead. Also fixed.
•On Windows TT64 should now stop using CPU cycles when it's window is deactivated or minimized.
•Fixed a bug where clicking on cancel when opening a ROM would generate a script error.

Drag: I don't know what to do about the bug you experience, it doesn't have anything to do with my code, it's a Director application and/or Windows bug. My code is simply "set this text line to be yellow" and Director is supposed to take care of the rest. I noticed some similar but less severe problem in the Command list when I tested the program on Windows (like only 2 pixels of misalignment), but I'm clueless about why it happens on your machine. Maybe I could try to switch the font or properties of the text field and it would fix it.

Posted on 06-23-07 03:49 PM, in F-Zero? (rev. 3 of 06-23-07 03:50 PM) Link | Quote | ID: 48899

Level: 9

Posts: 4/12
EXP: 2674
Next: 488

Since: 02-22-07

Last post: 3968 days
Last view: 3533 days
You might take a look at another archived F-Zero thread where I explained to you how the track data is stored. http://acmlm.no-ip.org/archive2/thread.php?id=12682 Maybe you'll understand it better now, though I'm sure I could give a better explanation now if I had the time.

Essentially, the whole track is compressed using 4 layers of LZ-like compression. (Track/Panels/Rows/2x2Tiles)

For each layer, you have two elements: a list of pointers, and the non-repeating data referred by these pointers.

Changing only the pointers is very limiting, I tried to build an editor by doing that and quickly realized that it wouldn't work. To make any serious arbitrary changes to tracks, they would need to be decompressed, then re-compressed. That means the track data could vary in size when re-compressed, so we would have to extend the ROM and put the track data where space is not an issue. That in itself wouldn't be that hard.

Like I said at the end of the clipping I posted bellow, the hard part of making an F-Zero track editor/creator would be building a tool to assist the user when "drawing" these huge tile-based tracks. I had imagined a program that could easily draw diagonals at various angles of those "spheres" delimiting the track without having to manually click on hundreds of 8x8 tiles.

So here's one of the post I made in this old thread:

Let me try to make a simple explanation.

The basic graphic tiles are 8x8 pixels. Track panels are 256x256 pixels which means 32x32 basic tiles.

What defines what goes inside the panels are 16 pointers that are each 2 bytes long (16-bits).

Each pointer represents a row which is composed of sixteen 2x2 basic tiles graphics.

The number indicate what part of the row data will be used to display this particular row.

The whole row data itself is composed also of 2 bytes numbers but this time pointing to tile data.

The whole row data is uncompressed and starts at $10C13 in a ZST state for a particular track.

Each 2 bytes value in the row data is a pointer that represents a 2x2 basic tiles graphic.

The 2x2 tiles graphics data are also stored elsewhere, starting at $64580 in ROM.

Tile data is using one byte for each 8x8 pixels tile. So for each basic 2x2 tiles graphic 4 bytes are used.

Here is the 256 tiles set used by the tile data for Mute City (it's not the tile data itself)

If anyone already has the full set of these graphics for all tracks with all palette variations I would really need that. As you can see that palettes are off in some of my maps as I only have some of the graphic sets.

Anyway I guess the reason why it can get confusing is that the same thing is happening at several levels. The same "compression" method is used at the row and tile level, and actually it works much the same across the whole hierarchy of track parts:


If there is any part you don't understand, don't hesitate to ask...

Don't get too over hyped about editing the tracks. Even with this data, editing will be hard, unless someone designs a special tool to draw arbitrary tracks that would be then re-compressed as new panel, rows and tile data. That's how I think Nintendo proceeded, there is no way they worked by hand at the row and tile level unless they are really crazy

Posted on 07-04-07 09:09 PM, in TT64 public beta it's here Link | Quote | ID: 52280

Level: 9

Posts: 5/12
EXP: 2674
Next: 488

Since: 02-22-07

Last post: 3968 days
Last view: 3533 days

First thing, you have to understand how 0x42 and 0x43 commands work.

To save space, these two command types use a single number to represent different preset combinations of Model ID/Behav/Behav Params. You are limited to those in the list as they are hard-coded in the ROM.

In expert mode, parameters in gray are simply there to show you what the preset number represents, you cannot change those parameters. The orange behavior parameters will override the gray ones if they're not both equal to zero. You can change the orange parameters. These are always present in 0x42 commands, but not always in 0x43 commands which have a variable length.

Warp destinations appearing in the Warp ID menus are those set by the 0x26 commands. You have to change 0x26 commands to change the destination to something else than what was originally intended. When you make a change to the destination level or area in a 0x26 (or 0x27) command, make sure that the destination Warp ID is available in that level/area, or the game might crash. If you open the "Destination Warp ID" pop-up menu, you should get a list of those that are available.

I'll try to make TT64 automatically set a valid warp ID when you change the Destination level or area, to avoid this potential problem.

As for the Act/Stars problem, I'm guessing that some objects don't obey that parameter. But I would need some specific examples.

BTW when you guys submit bug reports, please try to make it so that I can reproduce the bug easily, include as much details as you can, and what steps are needed to reproduce the bug. Also please specify if you are running XP or Vista if you are on Windows.

I would need more details about your "disappearing red coin" bug. Does it still happen if you quit and restart the editor? Does it still happen when you open another ROM?

Posted on 07-06-07 09:10 AM, in TT64 public beta it's here (rev. 2 of 07-06-07 09:14 AM) Link | Quote | ID: 52683

Level: 9

Posts: 6/12
EXP: 2674
Next: 488

Since: 02-22-07

Last post: 3968 days
Last view: 3533 days
I realized not long before releasing TT64 that the 6th bit of the act byte is not actually for the 6th act (coins). If you click on the 6th big star in TT64 to show only objects from that act, you'll see that only very few objects are included.

What I just found out by experimenting is that act 6 seems to use act 1's objects. If you choose the 6th act in Bob-Omb battlefield you'll see that everything is like act 1, including King Bob-omb on the mountain, which is not present in act 2,3,4 and 5.

So joe, I guess you're right, there's no way of making an object appear only in act 6...

What I haven't verify is if act 6 also uses act 1's object in other levels, maybe in another level, act 6 uses act 2's objects for example.

But CrashDance22, I think I found the source of your problem:

Did you activate the Level Select by any chance? This feature was added at the last minute, and I just found that it can screw up a few things, like acts... I just did a test in BoB, selected act 6 and it put me in some other act (act 2 I think?). Try it again without the level select and tell me how it fares.

Cellar Dweller:

What you're saying is that if the act byte is set to 0x00 the object is skipped and won't use any RAM space or cpu resources? That could be very useful to implement a way to add and delete objects. I could extend the level scripts (moving them in the extended ROM part first) by inserting blank 0x24 commands, activating them when the user decides to add an object.

Also, what I'm thinking of doing, and that would help a lot to simplify the editor and make it more flexible, is converting all 0x42 and 0x43 commands to 0x24 commands.

That way all objects could rotate on all three axis, and they wouldn't be restricted to presets. Having only one type of 3d object would also be much less confusing for users.

I just hope the game won't run out of RAM because of the larger level scripts.

Posted on 07-07-07 03:06 AM, in TT64 public beta it's here (rev. 2 of 07-07-07 03:07 AM) Link | Quote | ID: 52823

Level: 9

Posts: 7/12
EXP: 2674
Next: 488

Since: 02-22-07

Last post: 3968 days
Last view: 3533 days
Posted by HyperHacker
Hm, but in the game, King Bob-omb doesn't appear on act 6.

Well, here's what happens in an unmodified ROM with my battery save.

Selecting the 6th star. Note that the 6th star in that game was
collected while in act 1, maybe it has something to do with it?

This pink bob-omb is set to appear in act 1, but also appears in act 6,
while in act 2,3,4,5 it's replaced by another bob-omb saying "Thank-you"
for killing King-Bob omb, and obviously he's not present in those acts.

There he is, in act 6, in an unmodified ROM...

Posted on 07-07-07 10:48 AM, in TT64 public beta it's here (rev. 3 of 07-07-07 10:53 AM) Link | Quote | ID: 52919

Level: 9

Posts: 8/12
EXP: 2674
Next: 488

Since: 02-22-07

Last post: 3968 days
Last view: 3533 days
Posted by residentevil64
How do you make marios head peach???


like on here

Hmm I'm sorry I didn't keep the details of how I did it at the time, since everyone seemed so creeped out about it Anyway it would only work outside the Castle. I'll try to make a tutorial for you, but I don't promise anything. Future versions of TT64 will enable you to change body parts, relatively easily.

Posted by HyperHacker
Leet hax.

Hm, looks like act 6 uses whatever act you haven't beaten yet. If you get #6 first, King Bob-omb is still there, and once you beat him, go to #6 again and Koopa The Quick will be there instead. I didn't get a chance to see what happens if you e.g. get #6, then one besides #1, and play #6 again, because it doesn't seem possible in level 1. You need #1 to get #2, you need #2 to open the cannons, and you need the cannons to get #3 (on the island), #4 (red coin on the island) and #5 (shoot from the island). :-/

You're right... I guess that we can conclude that you cannot count on having a specific object set tied to an act when you play in act 6. So when putting the 6th star in a mod, you'd have to make sure it can be accessible in all acts. Essentially, that would mean that you can always get the 6th stars before all the others.

Some good news about the possibility of adding objects, I successfully managed to:

1. Move a level script to the unused space at the end of an extended ROM.
2. Make the level script linear, so it doesn't use any "gosub" commands and doesn't share 0x22 commands with other levels.
3. Add 100+ empty zeroed 0x24 commands that could be used to add objects to a level.
4. Transform all 0x42 commands into 0x24 commands and move them into the main level script.

My experiment involved Castle Grounds, and was done in part by "assisted" hex editing, and some routines I wrote in TT64.

To avoid having the original 0x42 objects displayed, I simply "NOPed" the 0x39 command, which loads the "Macro Objects" commands found in the level's MIO0 bank. As it was suggested before, a good way to "NOP" a level script command is to change it to a zeroed 0x24 command, which in that case can have a different length byte than usual. So what I did is change the 0x39 command to 24 08 00 00 00 00 00 00, and that way the command is skipped.

Level script banks also contain geometry layout commands for the polygon objects that are part of the level MIO0 (level parts like some platforms that are exclusive to a level). These level specific geometry layout commands are found just after the level script. If I changed the size of the level script I would have to re-point all references to these geometry layout commands (in some cases there are many), and that each time I would want to change the size of the level script. To avoid that problem, I put the the whole extended level script after the geometry layout commands, keeping the original level script intact (and unused).

Take a look at this: http://homepage.mac.com/qubedstudios/SM64MainLevelScripts.txt

These are the scripts used by menus and are used as a central hub script to launch levels.

2AC184/04E4: 00 10 00 0E 00 45 45 E0 00 45 4E 00 0E 00 05 08 --Outside Castle

The 0x00 command copies an uncompressed bank from 0x4545E0 to 0x454E00 in the ROM to somewhere in RAM then jumps to the offset found in the last 3 bytes (in that case 0x000508). 0x0E is the Bank ID. I changed both the start and end pointers to reflect the new location and size of the new level script bank, then change the jump offset so that the game will load the new extended/linear script (0x820, at the end of the original).

So anyway it all works well to that point.

My problem comes when trying to convert 0x43 commands to 0x24.

Well actually I can convert the commands, but my problem is disabling the originals.

What I call the 0x43 commands are found in another chunk of data in the level's MIO0 bank. The 0x2E command in the level script loads the solidity (collision) data, then the 0x43 commands, then some other stuff that I don't know much about yet (water areas...). So unlike the 0x42 commands I can't simply disable the 0x2E command, since it's also used to load valuable things like the collision map. Deleting the 0x43 commands and moving what's after to fill the void doesn't work, since some stuff seems to be referred by pointers somewhere else. I can't find a way to "NOP" them either, this area doesn't use the same command set as the level script, nor do I know how to make the script "jump" over them...

If anyone wants to take a look and experiment, the 0x43 commands for the Castle Grounds start at 0xFD8CAC and end at 0xFD8DAA in an extended ROM. After that is "other unknown stuff" that seems to include the water level around the castle.

I'm looking for a way to disable 0x43 commands (trees, the tower and the doors in that case) without making the water disappear, or crash the game.

Cellar Dweller, I remember you did some disassembly of the routines that loads the data referred by the 0x2E script command (collision map, 0x43 commands etc.). Would you know what could I do to disabled the commands between the 0x43 and 0x44 command without moving what's after, and still loading what's after?

Posted on 07-08-07 09:42 AM, in TT64 public beta it's here (rev. 4 of 07-08-07 09:51 AM) Link | Quote | ID: 53209

Level: 9

Posts: 9/12
EXP: 2674
Next: 488

Since: 02-22-07

Last post: 3968 days
Last view: 3533 days
Posted by HyperHacker
God damn you Ctrl+W. God damn you.

K, so... in MK64 I discovered the commands didn't behave as expected. Changing a one-byte Disable Culling command to a one-byte NOP broke other things. Turns out the level script actually generates GBI commands which are referenced by pointers elsewhere. By changing a Disable Culling command (which generates one GBI command) to a NOP (which generates none) I had changed the location of these GBI commands which broke the pointers. Maybe your problem is similar.

Actually my problem is that I don't know how to "NOP" commands in the collision/0x43 data since they're not using the same command set as the level script (nor GBI or geometry layout commands). And deleting the 0x43 objects and moving what's after to fill the void left makes the game crash.

I checked a FAQ and it looks like you can get star 6 first in most levels. Those you can't, it's because you need to open the cannons first on some other act.
That script dump is interesting. By debug menu I take it you mean level select?

Yes that's what I meant. Actually that's how TT64 activates the level select, by patching this command.

So level number is 32-bit? The only level modifier code I saw at BSFree is 16-bit (at 8032DDF8). 0064, 0065 and FFF7 freeze the game. Do you know where it's pulling this value from?
Also, yes, try selecting invalid levels on the level select screen, you go back to the title.

Interesting too that the menu is a level. Maybe we can make our own menus then.

The level number is 32-bit, but for normal levels (which are positive numbers) only the last byte is used since their numbers are under 256. I don't know where in RAM the level number is stored, but it can be assumed that the 0x26 and 0x27 warp commands are used to set this number when a warp is called.

Yeah it's pretty interesting to see how menus are using the same level script format, eventually we'll be able to make our own menus...

Now what do you think is up with the lack of 00 through 03 in this table?

Beta levels that were erased... Trust me, they're not in the ROM. Note that other numbers are missing in the level number sequence, suggesting other deleted levels. As you may have noticed before, the level select menu goes through all numbers, including deleted levels.

I recently found a table defining which level is which, it's at E8D98. Note that it's found in an area that's covered by the checksum. If you hack it, you may have to recalculate the checksum.

Here's the table:

00 00 00 05 04 00 06 08 01 0A 0B 03 0D 0E 0F 00 10 16 11 18 12 07 09 02 19 00 13 14 15 10 17 00 11 12 00 0C

This will assign the level numbers used by the game. For example, Bob-omb Battlefield is level 1 in the game. If you change 01 to another level, you'll see that Bob-omb Battlefield will get the name from that other level, and corresponding goal names will also change. Other weird things may happen, for example some camera angles will be different (like on the top of the mountain for example). The name change will also affect any other instances of that level, like in the "Score" level list in the menu and inside the castle.

Note that 00 is for unused level slots (the three first numbers are 00 incidentally, as well as others further down the list).

There is a lot of other important stuff around this address. For example, at E8DFC there's a list of 19 behavior pointers that essentially list all warp pointers.

13000AFC Door Warp Behavior
13003E3C Collect Star
13000720 Exit Podium Warp
13000780 Warp
130007A0 Warp (Pipe)
1300075C Fading Warp
13002F60 Warp
13002F64 Warp: Mario Start
13002F68 Warp
13002F6C Warp: Mario Start
13002F70 Level Exit
13002F74 Warp: Mario Level Start
13002F78 Warp: Mario Start Flying
13002F94 Warp
13002F7C Painting Exit (Success)
13002F80 Painting Exit (Failure)
13002F88 Warp
13002F84 Warp
13002F8C Level Exit From Hole

At E8E4C there's a table defining part of these warps behaviors.

01 02 03 03 03 04 10 12 13 14 15 16 17 11 20 21 22 23 24 25

Here's what some of the numbers means, according to some experimentation:

25=Thrown out the painting.
24=Successful painting exit
23=exit while recovering life, standing
22=star opening then crashes?
21=exit while recovering life, laying on ground
20=exit with sparkles?
1f=normal level start

BTW, you might find this code by Viper187 interesting:
8933B4A0 ????
8933B4A2 ????
8833B4A4 00??
Press the GS button before entering a painting and it will warp you to the specified location.
0000 0000 0000: Wherever the painting normally goes
0108 0802 000A: Shifting Sand Land pyramid
010C 2402 000A: Tall Tall Mountain slide

Interesting, it seems to include the level number, area number and warp ID (0x0A is the standard warp ID used for level starts)

Parasyte also found this at 8033B408:
At this address, you'll find a list of maybe 12 - 16 pointers. Just add 0x80000000 to each pointer, and of course you'll have a nice, valid mapped RAM address.

The first pointer, pointer-0, points to data for on-screen textures, water, and sky.
pointer-1 points to data for trees, doors, etc etc.
pointer-2 points to Mario's texture and model data.
pointer-3 points to yoshi.
pointer-4, I can't tell what it points to.
pointer-5 points to world model data.
pointer-6 points to the item boxes.
pointer-7 points to world texture data
pointer-8 points to the sky texture set

I'm pretty sure that this is the bank (segment) pointers list, defining the location in RAM of all banks loaded in a particular level, as Cellar Dweller found sometime ago.

Posted on 07-13-07 08:34 AM, in TT64 public beta it's here (rev. 2 of 07-13-07 08:34 AM) Link | Quote | ID: 54501

Level: 9

Posts: 10/12
EXP: 2674
Next: 488

Since: 02-22-07

Last post: 3968 days
Last view: 3533 days
Posted by CrashDance22
Well this thread hasn't had a new post in a few days (surprisingly), but VL-Tone, do you think it's possible to map those textures to the Blargg some time in the future? It shouldn't be more than wrapping the "jellybean" texture around the model, then sticking the eye textures where they need to go. And do you know what might be causing the level's geometry model to not load? Like I said, I think there's some sort of "loading restriction" for certain 0x24 commands.

For the Blargg, it may be possible, but I won't work on this anytime soon, I have other priorities. And also I don't think that the jellybean texture would fit well, I think it should stay red, but it definitely would need some eyes texture.

I don't really know why the level geometry model doesn't appear. But I suspect its model ID number is probably not meant to be used by 0x24 objects. What you could do is edit a 0x22 object to that it points to the level geometry, and use that model ID instead.

As I just posted in my latest blog entry, I'll release this weekend a new version of TT64, that will include a new feature, that is the ability to view the collision map at the same time as the level geometry.

Note that the level geometry is shown as wireframe, while the collision map is shown as solid polygons.

It's been a long time since I experimented with the collision data, and I never did any deep experimentation back when I cracked the format.

Here's what I found in recent days and some recapitulation of the format:

Command 0x0040 is first used to load the vertex list. It's followed by two bytes for the vertex count. Then you get the vertex list itself, where each entry is 6 bytes, 2 bytes for each axis, signed. After that, you have various lists of triangles, representing different terrain types.

Much like the 0x0040 command, you first have a two byte terrain command, followed by two bytes for the triangle count. Following the terrain type command and the triangle count, there's a list of triangles.

000E, 002C, 0024, 0025, 0027, 002D are 8 bytes long per triangle. The first 6 bytes define the triangle (with three 2 bytes vertex numbers), while the last two bytes are used for extra parameters. For example, with 0x000E, which defines the water currents, the two bytes are used to determine the direction and force of the current bellow the current triangle.

The rest of terrain types used in the game are 6 bytes long per triangle, simply defining triangles with three pairs of bytes that are vertex numbers referring to the list defined by command 0x0040.

Most terrain commands in the game seems to be of the 6 bytes variety.

Here's what I found about some of the terrain commands:

0000: Normal (Slippery in Slide levels, when 0x31=0006)
000E: Water currents (8 bytes per tri) the two last bytes of each triangle defines direction and force of current
002A: Un-climbable hill
0015: Climbable hills
0014: Slippery hill
0013: Very slippery hill
0012: Falling in void (Haunted House)
001B: Switches to area 1 (Used in Wet/Dry World)
001C: Switches to area 2 (Used in Wet/Dry World and Tall Tall slide to seemingly switch area)
001D: Switches to area 3 (Used in Tall Tall slide to seemingly switch area)
001E: Switches to area 4 (Used in Tall Tall slide to seemingly switch area)
0028: Wall/fence
0029: Grass/flat
002C: Lethal ice
0001: Lethal ice/ Lava
0005: Mario can hang from the ceiling
000A: Bottom of level (death)
0030: Flat
0036,0037: snowy ice stuff
002E: Icy
0033: Starting line in Princess Secret Slide
0034: Finish line in Princess Secret Slide
0079: Flat non-slippery floor in Princess Secret Slide
0065: Top of Bob Omb Battlefield mountain wide angle camera
0066: Walls Tiny Huge Island area 3
006F: Camera turn in Bowser Course 1
0070: Camera turns in BoB
0075: Camera stuff Cool Cool Mountain
007B: Vanishing walls
00D0: Limited camera movements in narrow hallways (part of Hazy Maze Cave)
00A6-00Cx: Painting warps areas (in front)
00D3-00F8: Painting warps areas (behind)
00FD: Pool Warp in Hazy Maze Cave

Not to repeat too much of what I said in my blog, but despite a comment saying I wouldn't implement collision and geometry editing before 2008 or 2009, I changed my mind and will do it sooner then expected, before the end of 2007, and probably in the next couple of months.

The collision map editor will be able to change the terrain type on a triangle basis, instead of simply changing the terrain command for a whole group, like the unreleased Mario Landscaper seems to do. (Though it may only be possible between commands that use 6 bytes triangle chunks, to avoid changing the length of the collision data.)

Posted on 07-23-07 06:01 AM, in TT64 public beta it's here Link | Quote | ID: 57034

Level: 9

Posts: 11/12
EXP: 2674
Next: 488

Since: 02-22-07

Last post: 3968 days
Last view: 3533 days
Posted by CrashDance22
Oh, I see. But I don't understand what you mean by editing a 0x22 object to point to the model ID. In fact, I don't even understand how 0x22 objects behave, load, etc., which got me stumped. And speaking of level objects, the case is quite different with actual level pieces, like in Tall Tall Mauntain. They're 0x24 objects to begin with, but then again probably just another 3D object... my point is that I have no problem applying level parts to those objects.

And about modifying collision data, I think that would be great for creating invisible mazes to crawl through and things like that, but would that allow us to apply a certain section of collision data from a level to a single model? For example, outside the castle you can move the castle spire, and it's collision data would still be in the same place, upon the castle. I'm wondering if there's a way to make it stick to the object realistically, but it's probably not possible since the collision data is in different groups?

0x22 commands are used to define where to find the geometry layout data for a particular Model ID.

Let's take Yoshi as an example. Here's a 0x22 list that includes Yoshi.

Note that this list is displayed with the "Extra info in object lists" option in the preferences, which is very useful for 0x22 lists.

Just below is the 0x22 command used for Yoshi.

The number 283 is only meaningful to TT64, it's not part of the ROM data, it refers to this particular combination of Bank ID/Geo Layout Pointer (12/1128 in this case).

The number 085 (Set Model ID) means that whenever a 0x24 command (or indirectly 0x42/0x43 commands) uses 085 as a Model ID in this level, the geometry data found at location 12/1128 will be used, in this case meaning Yoshi's Geo Layout data.

Here's the 0x24 command used to place Yoshi in Castle Grounds.

See that it uses 85 as a Model ID?

If you change the 0x22 command for Yoshi so that it still has 85 as a "Set Model ID" value, but instead points to Toad's geometry, each time you'll set a 0x24 command to use 85 as a Model ID, Toad will appear instead of Yoshi.

Does it make sense to you? I tried to make it simple, but it can be confusing, I understand.

Anyway, I just tried to change a 0x22 to use the level mesh, and it doesn't work, the model is invisible it seems in that case.

I wouldn't recommend editing 0x22 for now, as there are a few usability issues with them I have to fix. The Geo Layout Combo menu content is not accurate when it opens automatically, changes are only reflected visually in the editor when you refresh the level, and even then, the Model ID labels don't change like they should (TT64 is supposed to be smart enough to do that, but something needs to be updated to make it work).

As for the collision data for the castle tower, like I explained on my blog, it's stuck to the castle, moving the tower collision would move and distort the castle roof with it.

As most "interested" people might know, TT64 is now at version 0.5b and now includes a way to set Mario's size and to force the game to use the high-poly version only.

I should have posted here about the 0.4b update too, but I felt like repeating myself from my blog... http://web.mac.com/qubedstudios/iWeb/Site/Blog/Blog.html

Nonetheless here are the highlights of the two last releases.

This is the new interface, starting with 0.4b

Full res version: http://homepage.mac.com/qubedstudios/TT64Screen1.jpg

New features and improvements in 0.5b:

•Updated to Macromedia/Adobe Director MX 2004 10.1.1 (from 10.0) which reduced the size of the program by almost 50%!
•The update to 10.1.1 might also fix a few "crashing" bugs and some other issues.
•New feature to set Mario's size.
•A checkbox to force the high polygon Mario model to be used all the time.

Bug Fixes in 0.5b:

•Fixed a bug that caused a script error "#loch" when quitting.
•Fixed the "#forecolor" script error bug that would happen in certain circumstances when the ROM couldn't be open.
•The texture editor should now work correctly, it was broken in 0.4b, causing certain textures to be wrongly imported as 32x32.
•Also in the texture editor, saving the texture to ROM shouldn't cause a script error anymore.
•Reverting a texture from ROM should now update the thumbnail grid accordingly.

Other small bug fixes since v0.4b.

New features and improvements in 0.4b:

•TT64 can now display the collision map (but not edit it!).
•The object list and pop-up menu can now be sorted by alphabetical order.
•New interface layout brings the positioning widgets closer to the middle of the screen.
•The little menu icons in the parameter bar light up when selecting.
•Better lighting in software renderer
•Simpler object list, with an option to show the extra info found in previous versions.
•Auto-open default pop-up menus when selecting objects.
•Now uses the checksum to ensure the ROM is valid (can be disabled).
•Themes, if you get an overdose of glossiness, you can turn it off. Four themes are available.
•Some fixes and changes in the description labels.
•Improved documentation.

Bug Fixes in 0.4b:

•TT64 will no longer generate a script error when activating the wireframe mode in areas greater than 1.
•You can now Quit TT64 using the standard close box.
•Zooming with the camera widget now works correctly when the "Follow Selection" option is checked.
•The pop-up menu won't close when opening another menu.
•Fixed a bug where the 3d view would get incorrectly sized if the window was resized when the level menu was open.
•No more script errors when clicking on the empty part of the area selector.
•When pasting params, the object list and pop-up menu are now correctly updated.
•If the Drop To Ground button is clicked and the camera is in Orbit mode, the camera will follow the object as expected.

Many other small bug fixes since v0.3b.

Main - Posts by VL-Tone

Acmlmboard 2.1+3δ (2016-01-08)
© 2005-2016 Acmlm, blackhole89, Xkeeper et al.

Page rendered in 0.563 seconds. (336KB of memory used)
MySQL - queries: 81, rows: 105/0, time: 0.524 seconds.