messiaen
Catgirl
Level: 68
   
Posts: 166/1085
EXP: 2596326
For next: 132474
Since: 11-20-07
Since last post: 8.1 years
Last activity: 7.2 years
|
|
| Nice! I remember downloading Genecyst from Zophar and playing Sonic at mediocre speed at in my 486! Too bad back then my internet access was very limited, so I didn't know nothing about ROM Hacking. A few weeks ago I tried acessing the Zophar website and it was down, so I thought the site was officially dead. Good news (at least for the nostalgy). |
messiaen
Catgirl
Level: 68
Posts: 167/1085
EXP: 2596326
For next: 132474
Since: 11-20-07
Since last post: 8.1 years
Last activity: 7.2 years
|
|
Hi, here is my modest contribution:
382. Goomba's Body
It is partially hideen by the Goomba's head. Also, texture 384 isn't a dead Goomba, but rather a blinking Goomba. During the game, the face texture is quickly switched to produce the blinking effect. So:
384. Goomba Face Texture (Blinking)
The Goomba's feets aren't a texture, but polygon colors. The offsets for its colors are A9ACEC and A9ACF4. |
messiaen
Catgirl
Level: 68
Posts: 168/1085
EXP: 2596326
For next: 132474
Since: 11-20-07
Since last post: 8.1 years
Last activity: 7.2 years
|
|
I would say take your time to implement things correctly, as these are crucial decisions to the future of TT64. I'm curious about the output generated by the importer, how is the generated data organized? How can much can be done about textures with manual editing? Also, could you explain more this:
"- Multiple objects import, though I'm not sure if they would be imported as individual, moveable objects, or simply added to the level geometry."
What do you mean by "movable objects" ? If you are thinking of a modular approach with new objects/behaviors like I've been experimenting with, I really wouldn't recommend it. The game can't handle it properly when you try to insert more complex models, which leads to slowdown and sometimes unpredictable bugs. But if you are thinking something like a "internal" TT64 format which will be then translated to the final polygon/collision data, then this could lead to more flexibility.
Regardings the interface for the importer, perhaps in the future you could couple it with a "bank selector", as you already have all objects/banks sorted in the SM64GeoLayoutPtrs.txt file. Something like a "Create New Level" feature, in which you select the level to replace and start with just the shared banks loaded.
Keep us updated on your progress and problems/questions you may be facing!
|
messiaen
Catgirl
Level: 68
Posts: 170/1085
EXP: 2596326
For next: 132474
Since: 11-20-07
Since last post: 8.1 years
Last activity: 7.2 years
|
|
Here is the deconstructed Goomba Geo Layout. This probably will be useful for creating new (modified) enemies. Maybe in the future it could be expanded to an "enemies" Geo Layout thread.
All offsets are absolute:
200FB4: 1600 0001 0096 0064 <-- Sets shadow
200FBC: 0400 0000
200FC0: 1D00 0000 0000 4000 <-- Scale Polygons
200FC8: 0400 0000
200FCC: 1301 0000 0000 0000 0801 D760 <-- Not polygons, but RSP settings (*)
200FD8: 0400 0000
200FDC: 1301 0000 0000 0000 0000 0000
200FE8: 0400 0000
200FEC: 1400 0000 0000 0000 <-- "Triggers" 0x0D scaling?? (**)
200FF4: 0400 0000
200FF8: 1504 0000 0801 B690 <-- Body (not animated). Uses texture #382.
201000: 0500 0000
201004: 0500 0000
201008: 0400 0000
20100C: 0E00 0002 8029 DB48 <-- Calls Blinking Function (common to many objects)
201014: 0400 0000
201018: 1301 0030 0000 0000 0801 B5C8 <-- Head (***)
201024: 1301 0030 0000 0000 0801 B5F0 <-- Blinking Head (***)
201030: 0500 0000
201034: 1301 FFC4 FFF0 002D 0000 0000 <-- Foot 1 position (x,y,z)
201040: 0400 0000
201044: 1301 0000 0000 0000 0801 CE20 <-- Foot 1 (****)
201050: 0500 0000
201054: 1301 FFC4 FFF0 FFD3 0000 0000 <-- Foot 2 position (x,y,z)
201060: 0400 0000
201064: 1301 0000 0000 0000 0801 CF78 <-- Foot 2
201070: 0500 0000
201074: 0500 0000
201078: 0500 0000
20107C: 0500 0000
201080: 0500 0000
201084: 0100 0000
The Bank 0x08 pointed by this object starts at 0xA8181C.
(*) BC00 0002 8000 0040 <-- "MOVEWORD" RSP command. According to Mupen's RSP plug-in, the fourth byte argument = NUMLIGHT, so it probably affects lightning properties.
(**) I have to check this again, but without the 0x14 the 0x1D scaling doesn't work. At least that was my experience with custom non-animated models. This has to be tested again.
(***) The second byte is the distance between the body and the head. Normally in a 0x13 command it would be the X position, however the animation of this node makes the object rotated. Each head uses a different texture, and they are alterned in order to get the blinking effect.
(****) Foot 1 color offsets = 0xA9ACEC/0x194D0 and 0xA9ACF4/0x194D8 [absolute/relative to bank]
Here is a simple modification:
 |
messiaen
Catgirl
Level: 68
Posts: 171/1085
EXP: 2596326
For next: 132474
Since: 11-20-07
Since last post: 8.1 years
Last activity: 7.2 years
|
|
Nice! I was having a hard time adding body parts to the Goomba, perhaps the 0x10 command will help. Here's the Bob-omb enemy Geo Layout, it is very similar to the Goomba:
Starts at offset 0x201088. Bank 08 = 0xA8181C.
1600 0001 00C8 0046 <-- Sets Shadow
0400 0000
1D00 0000 0000 6000 <-- Scaling
0400 0000
1301 0000 0000 0000 0000 0000
0400 0000
1301 0000 0000 0000 0000 0000
0400 0000
1301 0000 0000 0000 0000 0000
0400 0000
1400 0000 0000 0000 <-- See previous post
0400 0000
1504 0000 0802 2D08 <-- Main body (not animated)
0500 0000
0500 0000
1301 0000 0039 FFC4 0000 0000 <-- Position for Foot 1
0400 0000
1301 0000 0000 0000 0000 0000
0400 0000
1301 005B 0000 0000 0000 0000 <-- Another position parameter for Foot 1 (*)
0400 0000
1301 0000 0000 0000 0802 3270 <-- Foot 1
0500 0000
0500 0000
0500 0000
1301 0000 0037 003E 0000 0000 <-- Position for Foot 2
0400 0000
1301 0000 0000 0000 0000 0000
0400 0000
1301 005B 0000 0000 0000 0000 <-- Another parameter for Foot 2 (*)
0400 0000
1301 0000 0000 0000 0802 3378 <-- Foot 2
0500 0000
0500 0000
0500 0000
1301 0000 0000 0000 0802 3480 <-- Top part (trigger)?
0E00 0002 8029 DB48 <-- Calls Blinking function (used by many objects)
0400 0000
1304 0000 0000 0000 0802 2B58 <-- Eyes
1304 0000 0000 0000 0802 2B88 <-- Blinking eyes
0500 0000
0500 0000
0500 0000
0500 0000
0500 0000
0100 0000
(*) The foot is rotated, so the "X" parameter is actually a "Y". Using negative numbers (ie, above 8000) will increase not only the foot Y position but also the amplitude of the movement (?).
Do you have any clue why so many empty 0x13 commands are used? |
messiaen
Catgirl
Level: 68
Posts: 172/1085
EXP: 2596326
For next: 132474
Since: 11-20-07
Since last post: 8.1 years
Last activity: 7.2 years
|
|
| Here you have v0.2 with a 2-star sample level! Release is on the first post. |
messiaen
Catgirl
Level: 68
Posts: 173/1085
EXP: 2596326
For next: 132474
Since: 11-20-07
Since last post: 8.1 years
Last activity: 7.2 years
|
|
Sorry, the last uploaded file had a stupid last-minute edit bug (an empty object enabled on a few acts) which would crash the level at a certain point, so I uploaded the corrected version.
I changed a bit my behavior approach for this release. Instead of forcing the objects to be visible all the time, I let the game handle it and created a special set of behaviors which are to be used very sparingly, only on the objects which will have enemies on it. The volcano behaviour has this setting by default, because when using the 0x32 scaling command the game engine doesn't take in account the scaling to calculate drawing distances, resulting in awkward effects.
Hope you enjoy this one!
Edit: For version v0.3, expect the possibility to add more than 100 0x24 objects in the level! After a lot of testing, I finally found a solution, I made all the 0x24 objects linear and used a "pseudo" 0x80 command at the beggining of my level script (the same as in Flatworld) to point TT64 to the new level script entry-point. |
messiaen
Catgirl
Level: 68
Posts: 174/1085
EXP: 2596326
For next: 132474
Since: 11-20-07
Since last post: 8.1 years
Last activity: 7.2 years
|
|
I'm not sure if the following are bugs or something that needs to be implemented, but I would like to know how jumps (0x06) in the level scripts are handled. I tried insert a jump inside a jump and that works in SM64, but not in TT64. I also tried repointing one of existing 0x06 jumps to an extended part of the level script to get more room for 0x24 objects, but again this worked in the game but not in TT64. In both cases, I got a #getProp error. Are the level script jumps hardcoded in TT64?
And for the suggestion itself: what about a debug box so you can see what command and/or offset triggered the error? |
messiaen
Catgirl
Level: 68
Posts: 175/1085
EXP: 2596326
For next: 132474
Since: 11-20-07
Since last post: 8.1 years
Last activity: 7.2 years
|
|
I have a suggestion to make the level terrain/collision data a bit more modular, so that TT64 could handle level meshes (object groups in the original .obj file) in its interface.
The 0x15 call display list command already can give a modular aspect to each object group in the .obj file. What about if you separated each object group in the main 0x40 collision vertex list by a fake (pseudo) vertice? Or even two, one at the beggining and one at the end of each object.
These fake vertices could contain pointers to the respective 0x15 Geo Layout command and also to the respective triangle group in the collision data (I'm supposing each object has its own triangle command). With this data, it would be easier to make TT64 move/rotate/scale/delete object groups.
If this doesn't sounds good, then ignore it, it's just a idea I had earlier on  .
|
messiaen
Catgirl
Level: 68
Posts: 176/1085
EXP: 2596326
For next: 132474
Since: 11-20-07
Since last post: 8.1 years
Last activity: 7.2 years
|
|
Amazing stuff!
The list at 0xE8D98 seems to be related to the "select act" white screen. Swapping Bob-omb's value for Snowman's Land will only change that screen. If you set any level to "1B" (Peach's secret slide value) the act selector won't show up, but I'm not sure which act you end up on.
Some time ago Yoshiman found some data in RAM which is used by the Tox Boxes to determine its movement. In the ROM, it is found at 0xEB8A8-EB8CC (this is probably just for one of the parameters, the data seems to begin at 0xEB850). Probably there are lots of interesting data used by objects in nearby areas.
I also found some data used by the King Bob-Omb:
0xF28F0-0xF2903 (in RAM, begins at 803378F0): I'm not sure what it does. 0xF28FC seems to be read a lot (try placing a breakpoint there). It's probably a floating point number.
From 0xF2904 to 0xF2917, there is a list of RAM pointers, and they are used by the King Bob-Omb like this:
802A7D40: LW T7, 0x7904 (AT) <-- Loads value from 80337904 and stores at $t7
802A7D44: JR T7 <-- Jump to value stored at register $t7
The last pointer (at 0xF2914) is responsible for creating the dialog box when the King is thrown off the cliff (more info on the ASM thread).
---
At 0xED9CC, begins a long list of pointers mainly to Bank 0x07. I placed a few breakpoints in these values, and indeed some of them are hardcoded collision pointers. For instance, at RAM 80332A0C, we have "070113F0". This is the pointer for the Bob-Omb's Bridge collision data. If you look at its behavior, there isn't any 0x2A collision pointer. |
messiaen
Catgirl
Level: 68
Posts: 178/1085
EXP: 2596326
For next: 132474
Since: 11-20-07
Since last post: 8.1 years
Last activity: 7.2 years
|
|
Sorry for bumping this but I've found a very cool video (hosted on NicoVideo) in the Japanese forum! It's a sort of SMB 1-1 hack using the Flatworld. There is also a hyper slide made with "Slide Battlefield" patch on the same video.
Another video features stunning Paper Mario-style textures.
The patches are available for download at the Wiki.
Here is a screenshot:
And the Castle Grounds from the second video:
The butterflies looks fantastic!
Edit: Here is the link for these patches. |
messiaen
Catgirl
Level: 68
Posts: 179/1085
EXP: 2596326
For next: 132474
Since: 11-20-07
Since last post: 8.1 years
Last activity: 7.2 years
|
|
The table starts at 0x8032DD98. Placing a breakpoint at it and stepping through the code will help us find some meaningful values. So far, I haven't found nothing interesting.
This if from Cellar Dweller's generalnotes.txt:
for most code: (low text)
ram - rom = 0x80245000
ram = 0x80245000 + rom
rom = ram - 0x80245000
By the way, if you are considering making TT64 edit the checksum area, some Gameshark codes contain really interesting stuff. For instance:
0x6BD4 - NOP to Skip Intro (4 bytes)
0x6D98 - NOP to Skip Lakitu (4 bytes)
0x10018 - Ammount of lives to start (last 2 bytes, it's an ADD Immediate instruction)
These codes were created by Viper, I just found the respective ROM offsets. The "Skip Intro" and "Skip Lakitu" could be very useful, otherwise if you change the Castle Grounds script most likely the intro will crash the game. There's also a bunch of codes to change the number of stars needed to open each door in the castle, these also would be useful.
|
messiaen
Catgirl
Level: 68
Posts: 181/1085
EXP: 2596326
For next: 132474
Since: 11-20-07
Since last post: 8.1 years
Last activity: 7.2 years
|
|
Now with the polygon importer coming I'm probably not going to work on this anymore except for testing stuff, but here is a video with an interesting mushroom platform behavior and a few other things, such as a custom title screen and modified goombas:
<object width="425" height="350"> <embed src="http://www.youtube.com/v/9V2V_9IzwHs" type="application/x-shockwave-flash" width="425" height="350"> </embed> </object>
Also, I found this interesting simple level created with the v0.3 ! |
messiaen
Catgirl
Level: 68
Posts: 182/1085
EXP: 2596326
For next: 132474
Since: 11-20-07
Since last post: 8.1 years
Last activity: 7.2 years
|
|
I did some tests and the snow at "Cool Cool Mountain" is created by a function called in the Geo Layout. So, maybe you achieved the snow effect on Bob-omb when experimenting with the main terrain Geo Layout. I'll see if I can do the same.
I know this may be a bit off-topic, but if there are more level characteristics besides the ones we already know, perhaps this command is worth looking at:
[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]: ??
Look at struct_area.txt from Cwellar Dweller's Hacking Notes:
void *off0x1c /* 4 @ 0x1c pointer to a array of four eight byte structures defined by command 0x28 */ |
messiaen
Catgirl
Level: 68
Posts: 183/1085
EXP: 2596326
For next: 132474
Since: 11-20-07
Since last post: 8.1 years
Last activity: 7.2 years
|
|
I looked at the ROM produced by the MAC extender and now I understand why the patches won't work on a MAC. As was noted before, all empty spaces are filled with "FF" in the MAC version, instead of "01" in the Windows version.
So, whenever there's a "01" in what was originally empty space in the ROM, the PPF patcher will ignore it (the patch is a "compare" file), so the patched ROM on MAC will have a "FF" instead.
Since the second release, the Behavior Bank is moved (for extension) to an empty area, so that's why it will crash very soon instead of just in the modified level.
Edit: Speaking about extenders, I compiled the console version of Cellar Dweller's alternate extender, so if anyone wants the binary just send me a PM. One of the advantages is that it takes less than 5 seconds to extend the ROM. Also, I compiled an alternate version which produces the same output as the MAC extender, so in the future you can apply patches produced by MAC users. Since the next version of TT64 will use a lot the empty space, this will be a serious issue. |
messiaen
Catgirl
Level: 68
Posts: 184/1085
EXP: 2596326
For next: 132474
Since: 11-20-07
Since last post: 8.1 years
Last activity: 7.2 years
|
|
Actually, if you enable an object with an "empty" behavior (that is, behavior 0x0000, which is the Star Door one), the game will crash when you get near it. I don't think having extra disabled objects will slow down the game, because they are just ignored. It wouldn't make sense to allocate RAM space for a object which won't be displayed in a specific act.
However, certain behaviors (ie, enemies) can use a lot of CPU power, so if you put too many of them at once the game may slowdown. Also, if you pay attention, most moving enemies have a very simple behavior when you aren't near them. When you get near them, a most active (and CPU consuming) behavior is triggered.
After a lot of testing, I finally discovered that what was killing my test level experiments was forcing the game to load the collision when very far from Mario. Upon disabling this, even a level with 150 objects (not very close to each other) will run ok. But with the polygon importer we may test more the limits of the game. |
messiaen
Catgirl
Level: 68
Posts: 185/1085
EXP: 2596326
For next: 132474
Since: 11-20-07
Since last post: 8.1 years
Last activity: 7.2 years
|
|
The mushroom uses its regular texture, but for some reason I'm too lazy to look the stem color isn't correct. And about your question:
However, there's no collision to it. It's a very complex model, so the game probably won't handle it very well, unless something very simple (like a collision box) is used.
Just for fun, I'll see what is possible to do with behaviors/scaling using this. Perhaps with enough work on the main level scripts, it's possible to create a interactive title screen using warp pipes! |
messiaen
Catgirl
Level: 68
Posts: 186/1085
EXP: 2596326
For next: 132474
Since: 11-20-07
Since last post: 8.1 years
Last activity: 7.2 years
|
|
Yes, in that version all objects have a "maximum" collision distance setting. So, not only every object has to calculate how far they are from Mario, but they have also to load the collision. This is a trick I used so that enemies can detect the collision, otherwise they would just fall off to the ground.
Since objects are very simple, you can get reach a reasonable amounts of objects without slowing down the game, but try then placing a few enemies and you have problems.
In the game, thee collision distance setting really depends on how big is the object. The bigger the object, sooner you have to load the collision, otherwise you will touch the object and its collision isn't loaded yet. That's what happened when I first created the collision for the mushroom platform, it wouldn't work unless you get VERY near it, because it's a very big object which needs a reasonable setting for this parameter. Then I found a good setting and everything worked ok. Also, you can notice that whenever there are moving platforms, there's never a ground moving enemy on it, because that would require too much extra CPU power.
That's why some collision is separated from the objects (ie, the volcano), this way the game can only load the graphics and use the main level terrain collision, which doesn't have to calculate its distance with Mario. Most of the time, the "Static & NOT Solid" behavior is used for such objects. This is pretty much a "null" behavior, but it does one thing: it keeps the object on screen all the time. |
messiaen
Catgirl
Level: 68
Posts: 187/1085
EXP: 2596326
For next: 132474
Since: 11-20-07
Since last post: 8.1 years
Last activity: 7.2 years
|
|
Actually, I never played Mario Sunshine, so I'm not sure how it goes. My idea was to make a sort of "super loading script" at the moment the title screen is loaded, so all necessary banks/ASM are loaded to start the game. Anyway, I just reminded that getting rid of the first menu screen would be very difficult, because it's used to select which file to play and it probably initializes a lot of stuff.
Perhaps it would be more realistic to change the Castle Grounds. [dream mode on] I don't know how the shared scripts are handled in memory, but maybe it could be possible to do a warp pipe in the Castle Grounds to switch between Luigi and Mario (it would just load an alternate version of Mario's bank) ! [dream mode off].
And here is some title screen fun!
Platform Battlefield 0.4 is released! Check out first post for details! |
messiaen
Catgirl
Level: 68
Posts: 188/1085
EXP: 2596326
For next: 132474
Since: 11-20-07
Since last post: 8.1 years
Last activity: 7.2 years
|
|
Ops, actually it's #mycolor (no spaces between my and color), but if it's hard to track down this, perhaps you could include some note in the documentation saying that if you get this bug simple opening TT64 again one or two times will do the trick.
There is also something strange in the way newly-added descriptions work. For instance, if I set some new behaviors and give them the appropriate descritions using the Alt Key, they will show up in the behavior listing, but only as long as I actually have objects which use them in the level. If I remove one of these objects, close TT64 and open the level again, TT64 won't show up this behavior in its list and I will have to manually type it again, unlike regular behaviors which are shown even in levels which don't use it.
Also, I know this is sort of a hidden funtionality, but I couldn't edit the 0x17 commands using the Alt Key. I tried to change 0x0A background banks, and while the "Save" button was triggered when I typed the new offsets for this command, no modification was made to the ROM when I saved it. |
