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

Oh? Cool then, it seems sprites that spawn other sprites do use the Sprite ID.

Please let us know if you find this behavior using other sprites..

The *view*?? What.

Could you share more details please? I don't see how the view width can affect the stairs...

oh LOL.

These are some files in uiStudio folder. Maybe someone else knows the filenames?

But anyway you won't be able to do much with them, they're made with very very few tiles. For example the bricks background is made with just a few brick tiles repeated all over the place.

What all this means is that you won't be able to replace these backgrounds with any image you want.