Hi, and welcome to the forum!

Yes, the view in 1-1 is set to not scroll vertically, so the camera sticks to the bottom of the view.

Vines (and other sprites, like the spinning jump board, and maybe others) disable this vertical scrolling restriction, allowing the camera to scroll vertically (until it touches the bottom of the view: then the camera gets locked again).

These sprites don't disable scroll control sprites, only the view scroll control settings.

The purpose of the scroll controls next to the star coin is to move the camera down when the player comes from the usually hidden platforms above, in order to lock the camera to the bottom of the view again. I think the camera doesn't scroll enough in order to get locked in that place.

The vertical scroll control sprites work like this:

There are two sprites: the left limit and the right limit. Together they form an imaginary "line". If mario is horizontally between the two sprites, and under the line, then the camera won't go up the line (as if the line acts like the top of the view).

If Mario gets on top of the line by going through the line, the camera doesn't go up either.

If Mario gets on top of the line by not crossing the line, the camera will go up. If Mario crosses the line from top to bottom, the camera will "lock" again under the line, like it does in 1-1.

That's for the "top" scroll limits. These sprites have a setting that can make them act as a "bottom" limit, which acts pretty much the same way.

There's also the horizontal scroll control sprite. That one works the same as the vertical ones, except it's specified as one sprite at the bottom of the line with the height as a setting, instead of two sprites one on top and one at the bottom.

The "gaps" on the bottom scroll control sprites purposes are:
The first one is so that the camera follows Mario down the hole, the second one is so that the camera doesn't "jump" up when Mario goes up the second hole.

They did it this way so the camera stays locked vertically in the whole level, except if Mario goes down that first hole.

If you want to see it for yourself:

First remove the "holes" so that there's only one scroll control line across the whole level. You'll see the camera doesn't go down when you go down the hole, and you die. (If Mario gets down the camera, he dies, even if it's not the bottom of the view).

Then remove all the bottom scroll control lines. You'll see the camera goes down in the hole, but it also goes down in other places in the level, and it feels more "ugly".

Hope this helps

There's an additional setting in the sprite that allows you to offset the limit in pixels (I don't remember if it was up or down). If you look closely you'll see the offsets for the top and bottom limits make it exactly one screen high. (The DS screen is 256x192 pixels). They used that to make the camera not locked to the exact blocks, but slightly offset.




Yes, there's some "smoothing" going on so it's still fluid.

There was a time back when we were running abxd 2.x that the goomba was NSMB styled, and there was a Koopa too.

The code got lost in the upgrade, I don't think I have it anymore. Maybe I should redo it back

Deleted posts still count as posts, but they are -15 karma instead of +1 karma, that's it.

* Dirbaio closes this.

Please read tutorial How to get MvsL hacks to work. Multicart and Download Play, everything is explained in there.

And please stay on-topic, Mario Kart 7 has nothing to do here.

Yep, it doesn't...
So... dunno.

Anyway I thought I had closed this

...except it emulates GBA instead of NDS?? Of course emulating a NDS requires more power than a GBA.

I didn't know about nds4ios before

I just tried it out in my iPad4, it is a bit slow, yep, but since it's a DeSmuME port, I don't find that surprising at all. DeSmuME is pretty slow, its devs seem to value accuracy more than speed. nds4droid is slow too.

Shame iOS doesn't allow emulators on the store, nor installing apps from places other than the store. Installing this thing was... challenging, with the date change trick.

I maybe should jailbreak.

There's none.

I remember one hack that made noteblocks with invisible springboards on top of invisible ground. I think it was Clone Tag Team. It didn't work quite well because you could grab the springboards, but that's probably your only option if you want bouncy stuff

Build 378 now out!

Sorry  Piranhaplant, the build bot is broken if you invoke it from the website, but if I log into the server and run it manually from the terminal it works. I think it has to do with the stupid PHP timeouts. Blarg.

And thanks a lot for fixing the bugs!

You have to apply the .xdelta patch to a ROM and then open the patched ROM in NSMBe. You can't open xdelta patches directly.

If you did that and you still can't edit the levels, it's because he changed the gamecode in the ROM header. You will need to change it with an hex editor.

Open an unedited NSMB ROM, go to File Browser, select header.bin and click on Hex Edit. Copy the first 16 bytes (the first row).

Then open the NSMB3 ROM in the editor, hex edit header.bin again and replace the first 16 bytes with the 16 bytes you copied before. Make sure you're replacing, not adding bytes (otherwise all the data after moves and everything breaks). Then save, close and reopen NSMBe, and you should be able to see the levels.

Are you sure you did it right? I meant edit the ROM with an external hex editor program, NOT the hex editor in NSMBe.

- Download XVI32
- Open an unmodified NSMB rom in XVI32
- Copy the first 16 bytes
- Close XVI32
- Open the NSMB3 ROM in XVI32
- Replace the first 16 bytes with the ones you copied before
- Save and close XVI32
- Open the edited NSMB3 ROM in NSMBe, now you'll be able to edit levels.

How about posting it in the right forum to begin with?

That's not useless. It's VERY USEFUL

There are some special objects in Tileset 0 that make a camera not enter a 16x16 block even if it has objects. See More oddities with those 16x16 blocks. Make sure you have none of these

Make sure you have no scroll control sprites either, or other sprites that could affect. I see the boss wall tiles at the left, is this a boss room? Boss sprites mess with the camera a lot...

These are pretty good questions.

Yes, it's impossible to "move" code in RAM, because you'd have to fix all the jumps and pointers in the code, which is pretty hard to do reliably. This means we wouldn't be able to replace a function with a bigger one, and adding hooks is pretty much impossible.

So, this is how I solved this problem:

The ARM9 binary is divided in 'sections' that go to different places in RAM. There's a small code that executes right when the game boots that decompresses the rest of the ARM9 binary and copies the sections to their right places in RAM according to a table.

Then there are overlays. These are placed in RAM after the ARM9 sections, they're loaded on demand but they can be simply viewed as more sections.

Then the rest of the RAM is reserved for the 'arena', which is used for dynamic memory by the game.

For example, in NSMB USA ROM, 0x02000000-0x020986E0 is used for the ARM9 binary, 0x020986E0-0x021901E0 is used for overlays, and the rest is the arena.

So, the easiest way to add more code is to add a new section after the overlays, and change the arena start address to make space for it. This is what NSMBe does: All your code gets compiled to an .elf file which is then converted to .bin and inserted into the binary as a new section as-is.

(Yes, we're taking away space from the arena here. This will cause the game to go out-of-memory if the code we're inserting is quite big. However, it seems NSMB is not quite memory heavy, I've been able to insert as much as 100kb of code without having the game crash, I don't know where's the limit but it seems high enough for our purposes)

Then, to make hooks and function replacements work, NSMBe reads the function name list from your code and patches some instructions in the NSMB binary:

To make function replacements (nsub_02xx) work, it just replaces the first instruction of the original function with a jump (B instruction in ARM ASM) to our new function. The rest of the old function code stays there, but it will never get executed because all calls to that function will hit the jump and go to our new function

Hooks are a bit more complicated. The editor takes the instruction at the hooked address and replaces it with a B instruction. That B instruction points to a small piece of code that contains the replaced instruction (so it doesn't get deleted so we don't break the code), saves all registers to stack, calls the hook function, pops all registers to stack, then jumps back to the next instruction of the original code.

All this weirdness is to avoid crashes if the hook function overwrites any registers. It sucks because then you can't easily write a hook that modifies the value of a register, which is sometimes useful.

So, that's it, that's how the injection works
Hope you understand it more now.

You can also look at NSMBe's source code if you're curious. These are the two most interesting files:

Arm9BinaryHandler.cs handles decompressing and adding sections to arm9.bin

PatchMaker.cs handles reading the result of the compilation, making the patches and adding the section to the arm9.bin.

LOL good question. I don't know. Maybe the hammer bro sprite's data is not really in that sprite set, but is available everywhere? Or maybe the game forces Sprite Set 3 to value 1 when it wants to spawn a hammer bro? I think hammer bros only spawn in levels in later worlds, and other values from Sprite Set 3 aren't used in later worlds?



Just find the Class ID table and hex edit it. I think there's info about it in some threads. Test spawning a sprite to see if it works.

But I'm not sure if editing the Class ID table will do what you want. I think sprites that spawn other sprites use the Class ID, not the Sprite ID.

No. It's YOUR responsibility to know the right place for the thread and post it there, especially if you know you're not posting it in the right place, which it seems you do...

Closing this thread.

Mario Builder, lol.

Maybe you'd love to take a look at Supar Mario Bros X. Pretty much the same thing but looks more polished IMO

Yes, that's how function calling in ASM is done. You'll find that in *any* ARM ASM code, not just NSMB or DS games