Hi! I'm quite newbie to nesdev forum and in development in general. I'm trying to understand how super mario bros 3 collision works. Right now I'm using fceux hexedit to see RAM and ROM. My previous thoughts was collision map was embedded in the map info starting at 0x6000. But this seems not to be correct or something is missing. In world 1-1, one of the first boxes you can jump (address 0x6303) has the hex value 0xE3. In world 1-castle (not the ship one), the solid silver tiles are 0xE4. If I change it to 0XE3 if mario touches it, is killed. So obviously, the values does not mean the same thing. Is there any other table/address I should look at? thank you very much!
Knowing how Mario games work, there's a good chance different tiles do different things depending on tileset. Can't really tell you anything more precise than that, unfortunately. So, your best bet is to do more research, going to different types of levels, changing things, and seeing if you can see a pattern emerge.
Hi! I'm quite newbie to nesdev forum and in development in general. I'm trying to understand how super mario bros 3 collision works. Right now I'm using fceux hexedit to see RAM and ROM. My previous thoughts was collision map was embedded in the map info starting at 0x6000. But this seems not to be correct or something is missing. In world 1-1, one of the first boxes you can jump (address 0x6303) has the hex value 0xE3. In world 1-castle (not the ship one), the solid silver tiles are 0xE4. If I change it to 0XE3 if mario touches it, is killed. So obviously, the values does not mean the same thing. Is there any other table/address I should look at? thank you very much!
The only problems I've come across are that sprites like the fire-cannon-things on ships don't die properly, so the hitboxes don't leave after the fire disappears. other than that, it works aight.
If you happen to be TASing a hack that uses different addresses (for example, SMB 3mix), you might have to find the addresses yourselves, or you could ask me if I'm still around.
I should probably mention what it does. It:
I actually started looking into the basic glitch behind that a few days ago (I had the idea months ago but forgot to investigate it or tell anyone about it), and let the TASvideos community know about it. I realised that such a thing would be possible in many games as a result of reading NES documentation (this is the page that got me thinking along those lines); if you're reading the controller repeatedly until you get two values the same (in order to work around the DPCM/controller conflict), then if the controller reads a different output each time (because you're mashing the controller really fast), it's going to get stuck in a loop, potentially allowing for the code that handles the start of a frame running recursively. If the game isn't designed to expect that to happen (and if the code in question isn't really laggy, why would it?), bad things happen, and it was a case of finding a game in which the bad things in question would happen to let us win instantly. total_ did a lot of work in getting the glitch in question to work on SMB3; I had no idea which games it would work in, and was happy to see it working in such a well-known game. I'm not that clear on the details of how it works in the exact case of SMB3, except that the game somehow naturally starts running the controller ports, so you can hold a combination of inputs that (when interpreted as code) jump to the credits. All this happened while SGDQ was running, and the TASbot schedule got changed in order to add the run in because it's such a mindblowing thing to watch. As a fun fact, we pretty much needed TASbot in order to test out the glitch; very few emulators are capable of handling it correctly, so much of the testing was done on an actual NES by getting TASbot to test out our ideas.
You shouldn't need a degree in computer science to get into this hobby.
Am I to understand that the 2-second SMB3 TAS can't be submitted yet? Is it just because emulators are lacking sub-frame inputs or is there also an accuracy issue?
+fsvgm777 never censoring anything.
