/vr/ - Retro Games

>>8720787
you sound like a shitty hacker

>>8720614
OP, the main hurdle is that graphics data is usually compressed, unless if it's used all the time (like for a player character's graphics). this means that searching the ROM directly will likely only net you a small amount of recognizable graphics and a bunch of random static.

to get at the graphics efficiently without having to reverse engineer the decompression routine you have a few options.

first, note that any graphics that are displayed on screen are uncompressed in video memory (VRAM). you can dump the PPU settings to figure out where to dump VRAM to get at your graphics.

secondly, backgrounds and objects (sprites) are displayed different. backgrounds use a background map to lay out the characters (8x8 graphics) and their palette. you need both the BG map, and the characters, and color generator memory (CGRAM) to fully decode the graphics. the map and characters are in VRAM, and CGRAM is its own special memory.
objects are specified with object attrubute memory (OAM) which is also its own special memory. it specifies what character to use, where to put it on screen, palette, HV flipping, priority, and size. the object character graphics are also in VRAM and palette in CGRAM.

what you can do is wait for a graphic you like to be on screen. if it is an object, you can the graphics from VRAM and dump OAM to exactly reconstruct a sprite. note that sprites are composed of a lot of objects moving together, and while how sprites are defined by the game is different from game to game, the way it has to get mapped onto OAM is the same, so it's possible to recover sprites without knowing any assembly.

backgrounds are easier because you don't have to piece them together one character at a time, the map in VRAM tells you everything.

it would help to know how computers work and something like C to make your own tools to accelerate the process.

lastly, all of this assumes you have access to a debugging emulator.