 Register - Login |
||
 |
Main - Memberlist - Active users - Calendar - Wiki - IRC Chat - Online users Ranks - Rules/FAQ - JCS - Stats - Latest Posts - Color Chart - Smilies |
|
Register - Login |
||
|
Main - Memberlist - Active users - Calendar - Wiki - IRC Chat - Online users Ranks - Rules/FAQ - JCS - Stats - Latest Posts - Color Chart - Smilies |
|
| Jul - Posts by messiaen |
| Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 ... 45 46 47 48 49 50 51 52 53 54 |
| messiaen Catgirl Level: 61     Posts: 232/1085 EXP: 1795237 For next: 81359 Since: 11-20-07 Since last post: 197 days Last activity: 183 days |
|
||
| Prepare to lose even if you can't understand a word of this! That guy is a "Fox News-style" ultra-conservative local reporter, which adds to the fun  . |
| messiaen Catgirl Level: 61 Posts: 233/1085 EXP: 1795237 For next: 81359 Since: 11-20-07 Since last post: 197 days Last activity: 183 days |
|
||
| Maybe, but the problem is finding unused bytes in the RAM Object to hold all this stuff. Also, with this simpler approach you just have to create a separate behavior for each Koopa. Look how handy this is with the 0x04 Jump command: Koopa-The-Quick Alternate Path/Star Behavior: 00 05 00 00 <-- The first two lines are copied from the usual Koopa Behavior: 11 01 20 41 <-- Perhaps this one isn't even needed 27 3E 00 00 07 01 16 A0 <-- Pointer to path 27 3F 00 00 0B D6 11 94 <-- X, Y 27 50 00 00 EE 08 00 00 <-- Z 04 00 00 00 13 00 45 88 <-- Proceed to the usual Koopa Behavior (after the first 2 commands) So, that's just 40 bytes for each new Koopa, and it could be stored somewhere in the level bank (0x0E), so TT64 wouldn't have trouble knowning that this 0x07 Bank is the one currently loaded. The same jump approach could be used for the behaviors which have collision pointers. Here is a template: If I have enough time, I'll try this week to compile a list of all the "moving platforms" behaviors that will work just by changing the collision pointer. These will probably be enough for the next release of TT64 before using this kind of ASM hacks. Edit: I'm done with the list. I used one of my custom objects, set all the collision pointers in the behavior bank to it and now I'm using Yoshiman's spawn code to test stuff. Most behaviors work nicely with custom models/collision data, so with a very simple behavior interface you can assign interesting effects to the new objects. --- Edit2: Here's another ASM trick that can be potentially VERY useful. Looking through Cellar Dweller's Notes, I saw that some behavior commands are unused. So, I replaced the code of the 0x12 command with a modified version of the 0x0C (simple JAL) command. However, this new command can jump to data inside one of the level banks using the segmented_to_virtual (0x80277f50) function, which returns the virtual memory address of a segmented pointer. Sample usage: 12 00 00 00 07 01 16 A0 # Address must be word aligned (multiple of 4) Here is basically how the 0x0C command works: 80384688: LW T7, 0x0004 (T6) <-- Load argument from 0x0C command 8038468C: SW T7, 0x001C (SP) <-- Store in Stack 80384690: LW T9, 0x001C (SP) <-- Copy to T9 80384694: JALR RA, T9 <-- JAL to Register T9 80384698: NOP <-- Delay Slot And the modified version in the custom 0x12 command: 80384E20: JAL 0x80277F50 <-- Segmented to Virtual function 80384E24: LW A0, 0x001C (SP) <-- Ran argument from 0x12 command into this function 80384E28: SW V0, 0x001C (SP) <-- Save in stack [Not sure if it's necessary] 80384E2C: JALR RA, V0 <-- JAL to Register V0 [V0 = return value from segmented_to_virtual] 80384E30: NOP <-- Delay Slot |
| messiaen Catgirl Level: 61 Posts: 234/1085 EXP: 1795237 For next: 81359 Since: 11-20-07 Since last post: 197 days Last activity: 183 days |
|
||
Some ******* **** from misc files:******* ASM. |
| messiaen Catgirl Level: 61 Posts: 235/1085 EXP: 1795237 For next: 81359 Since: 11-20-07 Since last post: 197 days Last activity: 183 days |
|
||
| The arguments from level comands are processed by 0x0C call before the "loop" area: ROM Addr: 0021E380 Hex Behav: 13004580 Description: Koopa Behavior [...] 21E3B8/0045B8 0C 00 00 00 80 2F BC 4C <-- Only called once. 21E3C0/0045C0 08 00 00 00 <-- "Loop" 21E3C4/0045C4 0C 00 00 00 80 2F D7 F8 <-- This is continuously being called 21E3CC/0045CC 09 00 00 00 <-- End The first thing the "802FBC4C" call does is to load the arguments from the 0x24 command (stored in the RAM object) and branch out accordingly. If you take this call out, the arguments won't be processed and you'll have a "Running Koopa". This is true for most objects: the 0x0C calls before the 0x08 command usually process arguments and set a few variables, while the call inside the 0x08 "loop" area is responsible for the object movement/behavior. I posted the list of behaviors with collision pointers which will work fine on custom objects in the Behavior thread. Try testing a few of these on imported objects by copying all the behavior and just changing the 0x2A collision pointer. Edit: Here is a commented disassembly of the "Moving Up And Down" (0x3B30) behavior call responsible for processing the arguments. Looking at these calls is a good way to discover the possible arguments for some object. Maybe in same cases it won't be hard to create tweaks with custom arguments. |
| messiaen Catgirl Level: 61 Posts: 236/1085 EXP: 1795237 For next: 81359 Since: 11-20-07 Since last post: 197 days Last activity: 183 days |
|
||
| Hello, I've set up a simple site with some of my Mario 64 hacking notes. It's still messy, but way better than dozens of isolated .txt files in my HD  . Most of it has already been posted to this board, but I'm updating the site with interesting information.This big checksum area disassembly (done with NEMU) is very useful if you want to search pointers, coordinates or floats that may be hardcoded. On a side note, I've started a simple utility that edits interesting values in the checksum area. Besides collecting values from Gameshark codes (any code from 80246000-80346000 is a good candidate), I'm doing some work finding Bosses star positions. They are mostly stored as floats using load immediate instructions, and some ASM changes are necessary to get more flexibility. This program will handle this by applying a few patches on the ROM, so all you'll have to do is input a decimal X, Y, Z position. In this link (which will be constantly updated) I posted some more detailed information about some of the bosses stars and a quick guide how to find the instructiosn that load the coordinates. I'm also interested in any codes that changes Mario physics (jump distances, height and all other parameters), so if you have anything on this it may be interesting to add a simple physics editor. |
| messiaen Catgirl Level: 61 Posts: 237/1085 EXP: 1795237 For next: 81359 Since: 11-20-07 Since last post: 197 days Last activity: 183 days |
|
||
| It's been a while since I've experimented with these things. The problem is that if you want enemies standing on a platform, the collision has to work all the time, otherwise they will just fall to the ground. In order to experiment with these, you can try to tweak a platform behavior with these parameters: 0E 45 xx xx <-- Drawing distance 0E 43 xx xx <-- (most likely) collision distance The 0E 43 xx xx parameter is mostly used on very big objects. When the behavior doesn't specify them, a default value is used. These big objects needs this otherwise will Mario collide with the object before the collision is loaded, resulting in a glitchy effect. Most likely this is something VL-Tone will have to deal with when importing big objects as individual objects with movable collision, so this is worth experimenting with. It would be much easier to test this using NEMU, however it doesn't work with the extended ROM (I'm trying some tweaks to see if I can get it to work, but no success yet). |
| messiaen Catgirl Level: 61 Posts: 238/1085 EXP: 1795237 For next: 81359 Since: 11-20-07 Since last post: 197 days Last activity: 183 days |
|
||
| That's what I tried to do in the "Flat" Lava Land patch: an extra copy of some of the platform behaviors with this collision setting tweaked so it could work with enemies. It worked fine, but doing this for "Platform Battlefield" would take a lot of time and possibly crash the game. When you extend the behavior bank, it's important to remember that it's loaded in all levels, so even though some extra bytes won't matter in Flatworld they might even crash another level. The behavior bank should probably be left untouched, with extra behaviors being loaded in a bank loaded only in the specific level which uses it. Since this is a planned feature for the next release, this will probably be easier to handle on the next release of TT64. Talking about crashes, one thing I noticed by loading more banks into Flatworld is that even though your level may work, you can still have mysterious crashes due to memoy limitations if you load too much stuff. |
| messiaen Catgirl Level: 61 Posts: 239/1085 EXP: 1795237 For next: 81359 Since: 11-20-07 Since last post: 197 days Last activity: 183 days |
|
||
| I seriously need to organize the music data into a document , but I'm glad some of messy notes helped you. I've updated the site mainly with some disassemblies of simpler collision rountines. Here is a product of this: a (crappy) custom collision terrain. It replaces the 0x0A (Death at the bottom) terrain, however it's possible to create new collision types with a bit more work. |
| messiaen Catgirl Level: 61 Posts: 240/1085 EXP: 1795237 For next: 81359 Since: 11-20-07 Since last post: 197 days Last activity: 183 days |
|
||
| (Toad's music) I can see what may be confusing you. First, all pointers are relative to the beggining of this track (0x7CA8F0). The "0x" before the number means it is a hexadecimal number. This signal is used in a lot of programming languages. For instance,, 0x7CA8F0 + 0x5B = 0x7CA94B. What may be confusing, if you are comparing the hex data of the song with my document, is that I've placed things in a linear order, while the format is very jumpy. To understand it you have to think of a "tree": The first ("1") block of data has the general properties, and points to track data ("2 and 3"). This data ("2" and "3") points to snippets the music data (the notes itself). I hope this helps a bit. About putting everything together in a .zip file, I think most notes aren't ready for it yet. I'm constantly updating and correcting stuff, and some of them needs more descriptions (the music files are particularly messy, I think there are even some comments in portuguese!). When I'm satisfied with most of the notes, I'll add a link in the first page to a big .zip file with everything for easier reference, ok? |
| messiaen Catgirl Level: 61 Posts: 241/1085 EXP: 1795237 For next: 81359 Since: 11-20-07 Since last post: 197 days Last activity: 183 days |
|
||
| It was worth about $7000. Then I cliked "Update Data" and now it's worth $1197.2 Shame on me. -------------------- Mario 64 notes @ http://sites.google.com/site/messiaen64/ |
| messiaen Catgirl Level: 61 Posts: 242/1085 EXP: 1795237 For next: 81359 Since: 11-20-07 Since last post: 197 days Last activity: 183 days |
|
||
| A conditional jump is an interesting idea, but I'm not sure if its possible to make it use the Model ID. What is stored in the "RAM object" isn't the ID, but rather the RAM pointer for the geo layout/polygon data. Making it use the arguments from the 0x24 command would be easier, the problem as you predicted is that they are already used for most objects, especially by platforms. What about implementing something like this: When you import new geometry to be used as independent solid object, TT64 saves (internally or somewhere in the ROM) a level-specific table of model IDs and their respectives collision pointers. From this list TT64 can generate (during the level editing, if it detects that the model id you're working with is a imported object) a new behavior (that will be in the level script bank) and combo (ie, combo Model 0x36 with Elevator Behavior) on the spot, using something like the template I posted earlier on. Do you think something like this would work or do you have something else in mind? -------------------- Mario 64 notes @ http://sites.google.com/site/messiaen64/ |
| messiaen Catgirl Level: 61 Posts: 243/1085 EXP: 1795237 For next: 81359 Since: 11-20-07 Since last post: 197 days Last activity: 183 days |
|
||
| Nice, the script dumper will be useful! Now I understand what you meant by static behaviors and why a conditional jump would be useful. I have an idea that might work. I was looking at the documentation for the 0x24 command, and there are 4 bytes for parameters [2 for each type?], but TT64 only edits one byte for each param. Am I right to assume that all objects loaded from level script only use 1 byte [the last one] for each param and that's why you supressed the other one? So, what about we use the extra byte in one of these parameters to save the model ID? This way, a conditional jump based on it would be possible. For instance, if an platform object uses parameter 1 = 01, TT64 would set it to xx01 (xx = Model ID). The conditional jump (or load collision) command would use this byte, and before jumping would reset it to 0, in order to avoid any further interference. I think this could be a solution to get a static behavior (ie, going up and down) which can be easily used for many models. It may even take less space than using the jump command. Edit: Another option would be to edit the 0x24 command so that it stores the model ID somewhere in the RAM Object (maybe in this seemingly unused parameter byte). Maybe this would make the process even easier (no necessary changes in TT64!). -------------------- Mario 64 notes @ http://sites.google.com/site/messiaen64/ |
| messiaen Catgirl Level: 61 Posts: 244/1085 EXP: 1795237 For next: 81359 Since: 11-20-07 Since last post: 197 days Last activity: 183 days |
|
||
| Thanks for this release, VL-Tone! It's very nice having the backgrounds for the levels. Is it a giant sphere that surrounds the scene? I'll have to disagree with you, the script dumper is a major feature, it's so much easier to read the data linearly! Hopefully, it will inspire people to experiment more with behaviors. Not having to deal with the M64Geometry files is a relief, and I didn't notice any difference in the loading time. However, I noticed that the backgrounds are hardcoded. I loaded a ROM with swapped background banks and it still displayed the default backgrounds. Any way to make this more flexible? Also, does the script dumper use a hardcoded list for level script/behavior banks ? I got a #getProp error when trying to access the Bob-omb script from the "Level Select" script dumper in a Flatworld-enabled ROM. Edit: I got a #mycolor bug, tried to replicate it and it still happens if you move the mouse a lot when TT64 is loading. -------------------- Mario 64 notes @ http://sites.google.com/site/messiaen64/ |
| messiaen Catgirl Level: 61 Posts: 245/1085 EXP: 1795237 For next: 81359 Since: 11-20-07 Since last post: 197 days Last activity: 183 days |
|
||
| I guess I'll just have to post 10.000 messages this week, then it will be ok. But I might need some help. -------------------- Mario 64 notes @ http://sites.google.com/site/messiaen64/ |
| messiaen Catgirl Level: 61 Posts: 246/1085 EXP: 1795237 For next: 81359 Since: 11-20-07 Since last post: 197 days Last activity: 183 days |
|
||
| Hi, I've decided to release a bunch of 'side' hacks I did in the last months: - Slide battlefield - Play as peach in Bob-omb - Bowser in Bob-omb - Bowser in Bob-omb (2) - Rainbow Road in Mario 64 - Water SMB1 Theme in Jolly Roger Bay - Squishable Mushroom Platforms - Custom Title Screen With the new version of TT64, it's easier to load them because you don't have to worry about deleting files. Download here. -------------------- Mario 64 notes @ http://sites.google.com/site/messiaen64/ |
| messiaen Catgirl Level: 61 Posts: 248/1085 EXP: 1795237 For next: 81359 Since: 11-20-07 Since last post: 197 days Last activity: 183 days |
|
||
| It should probably work, as long as your target ROM still has the original Bob-omb Battlefield level. What kind of problem did you have with it? Edit: I tested the 'Koopa Path' ROM (the one you have to edit) and it works with 0.5.99b, besides my readme saying that 'newer versions' aren't supported .-------------------- Mario 64 notes @ http://sites.google.com/site/messiaen64/ |
| messiaen Catgirl Level: 61 Posts: 249/1085 EXP: 1795237 For next: 81359 Since: 11-20-07 Since last post: 197 days Last activity: 183 days |
|
||
| Here is a Gameshark code that will give you unlimited posts: 81000664 0007 81000666 FFFF 81000668 FFFF 8100066A FFFF -------------------- Mario 64 notes @ http://sites.google.com/site/messiaen64/ |
| messiaen Catgirl Level: 61 Posts: 250/1085 EXP: 1795237 For next: 81359 Since: 11-20-07 Since last post: 197 days Last activity: 183 days |
|
||
| up up down down left right left right b a should also work for 30 posts. -------------------- Mario 64 notes @ http://sites.google.com/site/messiaen64/ |
| messiaen Catgirl Level: 61 Posts: 251/1085 EXP: 1795237 For next: 81359 Since: 11-20-07 Since last post: 197 days Last activity: 183 days |
|
||
| Gray it fast my period is coming. -------------------- Mario 64 notes @ http://sites.google.com/site/messiaen64/ |
| messiaen Catgirl Level: 61 Posts: 252/1085 EXP: 1795237 For next: 81359 Since: 11-20-07 Since last post: 197 days Last activity: 183 days |
|
||
-------------------- Mario 64 notes @ http://sites.google.com/site/messiaen64/ |
| Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 ... 45 46 47 48 49 50 51 52 53 54 |
| Jul - Posts by messiaen |
 |
Acmlmboard - 07/23/2013 b378.03 ©2000-2013 Acmlm, Xkeeper, Inuyasha, et al. |
| Query execution time: | 0.050292 seconds |
| Script execution time: | 0.089329 seconds |
| Total render time: | 0.139621 seconds |