 |
|
Main
| FAQ
| Uploader
| IRC chat
| Radio
| Memberlist
| Active users
| Latest posts
| Calendar
| Stats
| Online users
| Search
| |||
| Views: 88,439,138 |
Main
| FAQ
| Uploader
| IRC chat
| Radio
| Memberlist
| Active users
| Latest posts
| Calendar
| Stats
| Online users
| Search
|
04-19-24 10:14 PM |
|
| Guest: Register | Login | |||
| 0 users currently in ROM Hacking Related Releases | 2 guests |
| Main - ROM Hacking Related Releases - TT64 public beta it's here | New thread | New reply |
| VL-Tone |
| ||
 Micro-Goomba Level: 10 Posts: 9/12 EXP: 3290 Next: 1124 Since: 02-22-07 Last post: 6095 days Last view: 5660 days |
Posted by HyperHacker 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.
Yes that's what I meant. Actually that's how TT64 activates the level select, by patching this command.
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...
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
Interesting, it seems to include the level number, area number and warp ID (0x0A is the standard warp ID used for level starts)
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. |
| CrashDance22 |
| ||
|
Micro-Goomba Level: 11 Posts: 7/15 EXP: 4553 Next: 1432 Since: 06-25-07 Last post: 6093 days Last view: 6067 days |
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. ____________________ Where have all the good hackers gone these days? Maybe they'll be back... |
| VL-Tone |
| ||
|
Micro-Goomba Level: 10 Posts: 10/12 EXP: 3290 Next: 1124 Since: 02-22-07 Last post: 6095 days Last view: 5660 days |
Posted by CrashDance22 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.) |
| CrashDance22 |
| ||
|
Micro-Goomba Level: 11 Posts: 8/15 EXP: 4553 Next: 1432 Since: 06-25-07 Last post: 6093 days Last view: 6067 days |
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? ____________________ Where have all the good hackers gone these days? Maybe they'll be back... |
| VL-Tone |
| ||
|
Micro-Goomba Level: 10 Posts: 11/12 EXP: 3290 Next: 1124 Since: 02-22-07 Last post: 6095 days Last view: 5660 days |
Posted by CrashDance22 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. |
| CrashDance22 |
| ||
|
Micro-Goomba Level: 11 Posts: 9/15 EXP: 4553 Next: 1432 Since: 06-25-07 Last post: 6093 days Last view: 6067 days |
I can't believe this thread hasn't gotten a new post since last week. XD
It's obvious that everyone is hanging out at your blog. Anyway, I sort of understand how 0x22 commands work now, but not completely. Thanks for explaining it though, maybe we can make that level mesh work sometime. Also, I discovered a new bug in the texture editor (can I post bug reports here or does it have to be at the blog?). It has to do with using the alpha texture in the same png as a custom texture. With some textures like coins and flames, white alpha represents shown pixels, and black represents trasparency. With other transparent textures like the castle windows and trees, it's the opposite. Is this a bug or just the way the rom reads textures? Because it's annoying when I find out I have to invert my alpha colors when transparent/shown pixels are opposite in-game. ____________________ Where have all the good hackers gone these days? Maybe they'll be back... |
| CrashDance22 |
| ||
|
Micro-Goomba Level: 11 Posts: 10/15 EXP: 4553 Next: 1432 Since: 06-25-07 Last post: 6093 days Last view: 6067 days |
In addition to the texture alpha bug, some textures get their alphas inverted whenever I import a png, but the only one I've seen do this is the flame smudge/burn mark texture behind the flame sprites in the basement. ____________________ Where have all the good hackers gone these days? Maybe they'll be back... |
| CrashDance22 |
| ||
|
Micro-Goomba Level: 11 Posts: 11/15 EXP: 4553 Next: 1432 Since: 06-25-07 Last post: 6093 days Last view: 6067 days |
Ok this thread is obviously dead... which is why we have this!  ____________________ Where have all the good hackers gone these days? Maybe they'll be back... |
| Main - ROM Hacking Related Releases - TT64 public beta it's here | New thread | New reply |
© 2005-2023 Acmlm, blackhole89, Xkeeper et al. |
|
MySQL - queries: 72, rows: 90/91, time: 0.016 seconds. |
