Points of Required Attention™
Smaghetti, a new Super Mario Advance 4 editor, is currently in development! Check out the thread HERE!

Please chime in on a proposed restructuring of the ROM hacking sections.
Views: 88,320,265
Main | FAQ | Uploader | IRC chat | Radio | Memberlist | Active users | Latest posts | Calendar | Stats | Online users | Search 03-29-24 04:35 PM
Guest: Register | Login

0 users currently in ROM Hacking | 2 guests

Main - ROM Hacking - How do you find the object-properties table? - SMB3 New thread | New reply


RetroRain
Posted on 11-12-08 03:33 AM (rev. 2 of 11-12-08 06:07 PM) Link | Quote | ID: 94165


Fuzz Ball
Level: 66

Posts: 338/994
EXP: 2432599
Next: 29252

Since: 09-30-07

Last post: 1907 days
Last view: 929 days
I'm hacking two games right now, SMB3 and Megaman, so I'm switching back and forth between the two.

How the hell do you find the object-properties data in Super Mario Bros. 3? Seriously. I've been looking forever, and I have had no luck. The blue X-block in the hills level. I want to make it an ice block. How do I find the table which specifics what type of block it is?

I have done read and writes to $E5, and to $603-605. I did manual searches in the hex editor, I did trace logging, and I also added some ASM code to $E5, to get the results I want, but then it will interefere later on. I should be able to just simply change the property of the block, and as far as I have looked, SMB3 Workshop doesn't have any support for this.

Is there a specific method for finding tables like this?

____________________
My YouTube Channel

Hamtaro126
Posted on 11-12-08 07:08 AM Link | Quote | ID: 94170


Cheep-cheep
Level: 33

Posts: 96/194
EXP: 212362
Next: 16817

Since: 05-02-07
From: Shelton, WA

Last post: 2445 days
Last view: 2288 days
It goes by SMB1's rules for attribute tables, It multiplys each tile attribute like this:

00-3F = Metatile Attribute using Palette 0

40-7F = Metatile Attribute using Palette 1

80-BF = Metatile Attribute using Palette 2

C0-FF = Metatile Attribute using Palette 3

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

Warning: The following in the bottom is long and is a tiny bit off-topic:

I tried making a new engine, But it's hopeless and they will not give me or you any help other than doing nothing, Because if you request a new engine, advanced romhackers will get pissed and refuse to help with it, (also applys to Romhacking.net!)

It's all because They usually cannot go to NESDEV to see how attributes work (See the new NESDEV forum rules by tepples, It says Piracy (as they called it) is not all allowed!. And therefore even the best romhackers couldn't EVEN make a new engine for attributes. Especially SMB1 and SMB3!

Also because in the past: I had actually spammed a bit in here and make repeat threads and pissed off people here temporarily

I read that hacking attributes is the WORST part of making/hacking games on the nes. Unless you and some of the people here find a way to study and learn about the attribute stuff properly and see how it really works: ''Do not bother''

(Sorry for the engrish! I am trying to clean my text a bit. But I usually make a couple or a few typos)

____________________
Mah boi, romhacking is what all true warriors strive for!

I wonder what's for dinner?

smkdan
Posted on 11-12-08 02:52 PM Link | Quote | ID: 94177


Ninji
Level: 36

Posts: 153/238
EXP: 288001
Next: 20109

Since: 05-26-07

Last post: 4035 days
Last view: 3984 days
breakpoints on $23C0-$23FF (or whatever nametable you want to check for) will show where the game sources its attribute data. You can then breakpoint on the RAM used to hold the attributes and follow the chain until you eventually see where the attribute data is coming from in the ROM. If the attribute writer makes sense to you you'll find it without issue.

hey that's quite a post hamtaro.


I tried making a new engine, But it's hopeless and they will not give me or you any help other than doing nothing, Because if you request a new engine, advanced romhackers will get pissed and refuse to help with it, (also applys to Romhacking.net!)


lol


It's all because They usually cannot go to NESDEV to see how attributes work (See the new NESDEV forum rules by tepples, It says Piracy (as they called it) is not all allowed!. And therefore even the best romhackers couldn't EVEN make a new engine for attributes. Especially SMB1 and SMB3!


This has to be a troll. Seriously no one can be this fucking stupid.

Dan
Posted on 11-12-08 03:32 PM Link | Quote | ID: 94178


Goomba
Level: 14

Posts: 24/28
EXP: 11710
Next: 1361

Since: 02-20-07

Last post: 5526 days
Last view: 4470 days
Posted by smkdan
This has to be a troll. Seriously no one can be this fucking stupid.


Believe it.

RetroRain
Posted on 11-12-08 05:59 PM Link | Quote | ID: 94181


Fuzz Ball
Level: 66

Posts: 339/994
EXP: 2432599
Next: 29252

Since: 09-30-07

Last post: 1907 days
Last view: 929 days
Posted by smkdan
breakpoints on $23C0-$23FF (or whatever nametable you want to check for) will show where the game sources its attribute data. You can then breakpoint on the RAM used to hold the attributes and follow the chain until you eventually see where the attribute data is coming from in the ROM. If the attribute writer makes sense to you you'll find it without issue.
No I don't want the attribute table. I know how to do that! I want the object-properties table. I shouldn't have used the word attribute.

For example, the table that defines a block if it is solid, water, a spike, lava, slippery ice, invisible, or air.

____________________
My YouTube Channel

smkdan
Posted on 11-13-08 03:32 AM Link | Quote | ID: 94197


Ninji
Level: 36

Posts: 154/238
EXP: 288001
Next: 20109

Since: 05-26-07

Last post: 4035 days
Last view: 3984 days
The 'specific' method would be breakpoints on reads from the level data (in PRG-RAM here i suppose), ignoring those that are used for graphics and other purposes. Eventually the read block is going to be tested whether it's through a table or IF-ELSE branches or bitfields and mario / other sprites will be affected. You have to keep track of where the read block from the level data is being passed around and when you find a ROM address you suspect is involved in interaction, try a cheat edit on it.

DahrkDaiz
Posted on 11-19-08 02:44 PM Link | Quote | ID: 94630


Nipper Plant
Sandwich Artist
Level: 46

Posts: 177/417
EXP: 672960
Next: 38814

Since: 02-22-07

Last post: 3459 days
Last view: 3379 days
No such table exists. blocks generally have 3 states:

solid,
not solid,
water

These states are determined mathematically based off 6 values in a table per object set. These values designate a range of blocks that act as solid and/or water.

Lava, ice, coins, etc etc are special cases. The game will check for a certain block table, in code, and handle it differently. How do I extend the block code to have more than one type of ice, lava, or other blocks? I create a routine that has a table of properties depending on object set, object #, etc etc and handle that object differently based on the environment. A good example is having underwater coins. Normally, coins cannot be under water except for in water stages, but I handle a certain block id that's in the water range. I then I increase the coin count, play the coin sound, change the coin into a water tile and wallah, under water coins.

Main - ROM Hacking - How do you find the object-properties table? - SMB3 New thread | New reply

Acmlmboard 2.1+4δ (2023-01-15)
© 2005-2023 Acmlm, blackhole89, Xkeeper et al.

Page rendered in 0.022 seconds. (340KB of memory used)
MySQL - queries: 67, rows: 93/94, time: 0.017 seconds.