/vr/ - Retro Games

>>10826206
cannot be overstated how lovely the Mesen debugging tools are to work with, way above any other options currently.

>>10037195
mmhmm those homie chrono trigger tiles
>>10039010
thx
>>10039212
> move the backgrounds from SMB1
mmmmm ya sorta kinda can't. SMB has one printed background that repeats a bunch of times, you can move stuff in that, but you will move ALL backgrounds. results could look gnarly in some places: the game was essentially built and planned around that one repeating background.

>>9895784
>That way you can concentrate on just your code using a debugging tool that's probably a lot better than what your emulator has.
I'm pretty sure the Mesen debugger is the best 6502 debugger in existence, and i've used a few of them. At the very least, the FCEUX debugger / memory viewer is more than adequate for running a couple instructions through to see how they act. The hell are you on about?
> I'd suggest extending the health bar. That's relatively easy
How do you know? You would have no idea before you dove into the code how easy or hard it is. Maybe it uses sprites and all the slots are taken up. Maybe it uses 8 sprites on the same scanline and you can't add anymore without making it a flashy mess. Maybe it uses half a byte with 16 values and there is zero room for expansion without rewriting half of the fucking game. It's stupid to make assumptions like this.
> This is something you can easily find code/instructions/help on how to do
From where? Who the hell has documented Hector for the NES?
> git gud
the man is writing 6502 ASM and editing ROMs successfully, which is a tremendous accomplishment in itself; and here you are giving terrible advice. the fuck have you ever done?

>>9862990
>dissambleries
dis-a-WHAT?!
anyway, yes, this assembles in ASM6F and you can run it in Mesen with full labeling like so. Enjoy:
https://nesblast.com/smb/smbdisasm.zip

>>9853554
sup

>>9639741
>ASM6
ASM6F

>>9608180
it's easier than ever to get into homebrew, communities are welcoming, emulator debuggers are amazing, resources are helpful, even youtube videos aren't garbage anymore and with enough patience and practice you can learn to hack or make anything.
if you just want to play video games though instead of making them, why is that an issue?
> While you fags shriek and squeal about shaders vs crts and hardware vs emulators
if there were no passionate retro enthusiasts who would play said projects or buy said games that you make to? ...i don't see a problem here?

>>8087323
calling FCEUX a "low accuracy emulator" is a bit harsh and unjustified, but yeah, Mesen is a clearly superior choice for development and romhacking in just about every way.

>>8056597
indeed it does. good luck. ask questions!

>>8047179
it was surprisingly easy to crack. once i found the level number at $55, i just set a read listener for that address, ignored a few cases where it reads while you're in the level, and found a CMP #$04 after the level is beaten. Bingo. Changed it to 0.
I don't know for sure if the entire game works honestly, i played until like level 20 or so.
Also, if you haven't tried Mesen, the debugger is wonderful. I don't bother much with FCEUX anymore.

>>7982741
hi, dude who explained it here
>>7980243
i don't think that's the case: "N2ATBL" is probably referring to "nametable 2", which would indicate graphics. What i don't see is any of the sound registers ($4000-$4016) being manipulated, in fact, there is only one store instruction at the very end. It doesn't "look" like sound code either: i'm actually writing some as we speak.
Anyway, It's not enough code to determine what it is doing in any context, there are some branch conditionals leading to subroutines and different labels, but, you can't gather anything meaningful from that screenshot alone. I'm not saying it's Definitely Not part of the "sound engine", but, i don't see anything indicating that.

>>7914998
> stand-alone patch
he means patches that can be combined together. unfortunately there is no such thing: if two patches change the same part of the game to achieve two different results it's game over. there's no "automated patch collision tester" as far as i know, you'd have to conduct that work by hand, or you know, just try it and see if the game breaks.
> It would have to be a bit “smart” wouldn’t it?
yeah. that would be an interesting and fairly difficult problem to solve. IPS' are generally unaware of the format of a game: they just change the right bytes compared to an exact copy of the original. patches that would work together change small parts of the game without rearranging the larger structure of it.
> Or rely on an assembler to automatically organize code and labels.
I suppose something like this could be built, but, it's hard for a disassembler to know what is code and what isn't. instructions and data look the same as far as it knows. emulator debuggers solve this by acutally running the code and making educated guesses about what's what.
SMB is a special case though, because a full disassembly exists, unlike most games. if two patches used this to change the overarching structure of the game, combining two IPS patches just wouldn't work. it might be possible to build some disassembler / DIF analyzer that pieces together similar parts of the game and finds what you're trying to change from each patch, but, that would be a project and a half. good luck.
TL;DR it might be possible kinda in some situations but it would be very difficult to organize / build something that does this automatically.

>>7779590
If a company really felt motivated they could go after you for graphics assets, which is why the SMB decompilation doesn't come with the CHR part, for example. Code is absolutely fine though.

>>7361839
> decompile
you can absolutely decompile anything. it's up to you (humans) to document make sense of the opcodes though. It is a long and tedious process, and few games have full documented decompilations. Many games have partial ones in regard to level data or specific mechanics.
https://datacrystal.romhacking.net/
> obtain the source code
Not possible. If a game was compiled in C for example, it may be possible to reconstruct the functions used. "source code" also implies comments and other documentation used during development: that type of information you can never get from reverse engineering a ROM because it was never in the ROM in the first place.
This was done for the GBA pokemon games:
github.com/pret
> you have to figure it out through a lot of reverse engineer fuckery and guesswork
yep. no way around that. however:
there are programs and emulators that make this process easier. Mesen here allows you to step through the code line by line, document memory addresses, and eventually make sense of what you are seeing. Here is SMB reassembled with full labeling, for example.

>>7273501
i'll do it for half that. shoot

>>7209034
The Mesen debugger is wonderful. I do most of my work in there.
Otherwise, for disassembly, i use this, but not often:
masswerk.at/6502/disassembler.html

>>7192435
> Pokemon
yeah, super mario bros, mario 64, etc etc...
a game has to basically be a worldwide phonemenon to have enough people with enough interest to dissemble an entire game.
personally i would not have the patience for that. If you're interested, there are tools, and people to point you in the right direction. maybe you should start one! that would be awesome.

>>7034235
NESdev wiki good place to start. If you've never played a piano before, you ain't playing Clair De Lune anytime soon. Start with the Nerdy Nights tutorial, make some simple demos, and work your way up from there. Have fun with it!

>>6944364
> I've seen the code. It's shit. That's why it plays so badly.
LOL no you haven't. Neither game has even been disassembled; barely any games have. $x2 yourself

>>6642298
SMB already has a complete and pretty comprehensive reverse engineered disassembly