[JonGandee]

I don't want to make multiple topics, so here you go.

How do I remove flashing effect from fire flower and super star?
How do I disable Bowser's front hitbox?
How can I make it so the screen scrolls only if Mario is in the middle of the screen?
How do I make it so if Fire Mario takes damage, he only goes back to Big Mario and not back to Small Mario?
How can I make the title screen just on a blank background with no demo?
How do I stop the bottom pixels on the UI from glitching when the screen scrolls?

[ThroughT1m3]

Have you tried messing with the disassembly? It is well documented and everything your asking can easily be done with some work and patience. Just a thought. There is a patch on rhdn you can download to make Mario go back to super after being hit. I would suggest crediting the author if you use it.

[JonGandee]

Oh, thanks. But unfortunately, I'm not really good at disassembly.

[Jorpho]

Oh, thanks. But unfortunately, I'm not really good at disassembly.

Have you even looked at it yet?  Perhaps with time you can learn and develop your skills.

In any case, a lot of those things you listed are going to involve assembly code. If you were hoping for a quick and easy editor with a nice GUI or something, then there is no such thing.

[JonGandee]

I'm pretty good at using utilities.

[bogaabogaa]

Since you like to do it you need to use a debugger. As a new user I would suggest to use the mesen utilitie. That one is amazing at emulating games and even better at debugging them. When doing changes with the debugger you can even save the changes as IPS or the ROM itself.

The emulator does a good job presenting the meaning of the opcodes and such but you might need to consult the nesdev wiki or other guides you can find when you google them to make more sense of the game. The first thing I would look at is how the ROM is mapped to the CPU bus.

Hitboxes are calculated with the CPU. The flashing are PPU routines that update values at PPU address $3f00. This should not be the first thing you are looking at. Since you can only write data to the ppu over register $2007.
Here you can look up the PPU registers in more detail. http://wiki.nesdev.com/w/index.php/PPU_registers

The scroll register is covered in the PPU registers too 

You like to change the player state when you get hit. This sounds like a beginner friendly task. Search RAM to find where the value is that get effected when you get hit or eat a mushroom. You can find it with the build in cheat finder. You know the value goes up when you increase the state and does reset when you get hit. Else you can consult documentation of the ROM. But searching yourself will give you needed skills for tasks like this.

With UI you probably mean the HUD. This is a sprite 0 hit event there and this is the location where the PPU will write to the scroll register. I don't think this can be improved till you convert to some mapper with proper IRQ handling. But I am not sure may be there is a way to make it better.

To stop the Demo you look for the trigger. Just look at the RAM values and use a breakpoint what code will start it. Then disable the routine with a RTS or overwrite the JSR with 3 NOP.

To make the screen black you change the tile mapping along tile attribute. This can probably even be done with a editor. Since it uses the first stage as a title screen. You might need to write some costume code to load a different map to the nametable. This is less beginner friendly.

Wish you much fun and luck learning the Mesen utilities.


Update:
Alongside you can learn some text editor utilities. I would recommand notepad ++ That one can also do syntax highlighting what helps to see what line is good for what purpose when writing code. Asar does have some nice assembly highlighting..
You will read code in the debugger utilities and you should get used to write some yourself. Here I prepared a injection patcher to make Mario stay big when get hit with fireflower.
You can open the main.asm with the text editor. I would recommend to use that to make changes as it is simple to keep track of what you did and a great way to learn.

To patch a ROM put the SMB1 in the ROM folder. Name it SMB1.nes. Then click the bat file.
https://www.dropbox.com/s/qkjvgy5u9rw1enx/SMB%20JU%20PRG0%20Example%20Damage%20Downgrade.zip?dl=0

I also disabled the flashing.. but it is not as easy to just remove the timer where you are frozen on screen. Sure it is possible but requires more research. Things like this are time consuming. I hope you are stubborn enough so you can make changes like this one day.

Here the Rom info for the ROM to patch. Hopefully you make a hack for the same ROM.

Code: [Select]

Database match: Super Mario Bros. (World)
Database: No-Intro: Nintendo Entertainment System (v. 20180803-121122)
File SHA-1: EA343F4E445A9050D4B4FBAC2C77D0693B1D0922
File CRC32: 3337EC46
ROM SHA-1: FACEE9C577A5262DBE33AC4930BB0B58C8C037F7
ROM CRC32: D445F698

update:
Since I did take away the easy edit. I did not leave a clue what to go after and is beginner friendly. There is a RAM offset at $73f. Have a look how that ones behavior when walking around. Set a breakpoint on it. Check what happen when you change compare values just before you have write breaks on that value. It should help you to cross a other thing off the list.

[JonGandee]

Thanks, but this all doesn't look too easy.

[bogaabogaa]

But you did find the memory viewer right? You can right click a address once the debugger window is open to set a breakpoint. If you don't try or keep learning the resources provided you will never get it done. Then you should have asked in the help section if someone can do it for you since you are to lazy or feel not worth the effort or something. Everything is hard if you don't know how to do it. Any day is a good day to improve you skill by something.

[FAST6191]

Have you not tried looking through one of the very nice commented disassemblies?
https://gist.github.com/1wErt3r/4048722
Unlike most games where you are very much on your own (or whatever you can glean from game genie guides, the wiki here and such like) then that is pretty much something you can follow along with as a lay person. Most of what you want there is also stopping things from happening (the last one might take some effort and understanding) so you don't even have to figure much out as much as NOP (short for no operation, basically makes the device carry on as it was and go to the next instruction without changing anything) or jump past the code you don't want/to the end result you want (there are some around here that upon coming to a fork in the road will be able to tell you all about road building, and that allows them to do some terribly impressive things, but most of the time you will only care about being able to pick the direction).

Worst that happens with that is some of the phrases are not necessarily what the manual, community or general phrasing might use and you get to try some others, or scan around for something else that uses it.
If you want to spend 5 minutes learning how to figure out what instructions are being executed at a given time in the game by using a debugging emulator then even better still (the game might be playing the "you have an invincibility star" song but shortly after that it will probably be figuring out something with the flashing graphical routine and you can then follow along with the assembly in text form). Spend a few hours learning how to set breakpoints and so much the better.

"I'm pretty good at using utilities."
So is everybody, give or take 5 minutes to get use to the level design flow for any random game. The trouble comes in that unless someone has thought to make the hacks you want and encoded them in then you are only going to be able to edit within the scope of the editor. You then get to get your hands dirty.

On "middle of the screen" then I should probably link a favourite document
https://docs.google.com/document/d/1iNSQIyNpVGHeak6isbP6AHdHD50gs8MNXF1GCf08efg/pub?embedded=true



For some general "how I would approach it"
How do I remove flashing effect from fire flower and super star?
Flashing is something that is done. Figure out what changes and hone in on that. I would use a debugger but you might find it in the disassembly too.

How do I disable Bowser's front hitbox?
Hitboxes can sometimes be software defined in file formats (many fighting games are this) but for a game like this it is probably code. I would instead look at the fireball code.

How can I make it so the screen scrolls only if Mario is in the middle of the screen?
Scrolling is a thing that is done, but it probably has a condition that it only occurs at a certain screen location, and even then for bosses and end of level is likely fixed. Commented disassembly probably has a nice thing. You will probably want to be changing numbers here rather than blanking instructions and skipping things.

How do I make it so if Fire Mario takes damage, he only goes back to Big Mario and not back to Small Mario?
Some have done this before if memory serves. Anyway mario has different state values. A cheat probably even exists to be always a certain size. Find this memory location and what changes it. Alternative what happens when hit/collision/hit hazard? Something will change from fire mode to small, however you would want to set it to just big mario.


How can I make the title screen just on a blank background with no demo?
As you will probably not be able to blank out data without breaking the rest of the game you get to attack the code. Being one of the first things in the game then demo mode is fairly well covered in the commented disassembly.


How do I stop the bottom pixels on the UI from glitching when the screen scrolls?
I recall some looking at this before. Still this is an actual thing that might take some knowledge and understanding of the hardware, though you might get lucky and it is one of the easier programming errors to sort https://textexpander.com/blog/the-7-most-common-types-of-errors-in-programming-and-how-to-avoid-them/

[JonGandee]

Oh, this could help.