11 March 2016 - Forum Rules
Started by Erockbrox, May 30, 2017, 08:03:19 PM
Quote from: KingMike on May 31, 2017, 09:46:57 AMGood. So you found one step.Now you need to use a debugger to find the ASM code that changes it.With the debugger, set a Breakpoint on WRITE to 7E0910.It will make the debugger pause and show you the instruction when that address is written to (note that there could be multiple times it will try to write, such probably setting the starting time, and the decreasing it during play. The latter one is probably the one you want.)Depending on what instruction it is, changes what you should replace it with.
Quote from: 90s comeback on October 16, 2021, 09:15:36 AMWhat about finding characters' sprites, is it the same?.
Quote from: FAST6191 on October 16, 2021, 03:35:08 PMIf simply busting out the tile editor and scanning the ROM, or one of the other methods if available for your system (the SNES is not as nice as some later stuff here with things like compression searching) has not worked then in some ways it is.You would probably want to find a point in the game where the sprite you want has not been loaded in VRAM (VRAM viewers are available in many emulators, it is how many sprite rippers get things). You can also see it unloaded (if starting a new dungeon, going into a different room, going back to menu, starting credits... anything you might have done to try to force corrupted sound or graphics to sort themselves is worth trying here) if you want. Do remember you have cheats and turbo mode when playing in an emulator.Anyway it will likely load in the same place in VRAM every time.You would get to just before it is loaded in VRAM, set the break on write to that location, do whatever in the game to get it to load and then the emulator should flash up saying "this thing just wrote the area you told me to watch". Hopefully it is a copy from ROM somewhere, if not then you get to follow it back a few steps to where it fished it out of the ROM (you need not even really understand the steps in between that for many things, though if it is (de)compression you are watching happen then you would want to as that will be necessary to know how it works).About the only thing I would note is different systems might have multiple methods of fishing things out of the ROM -- simple CPU directed memory reads are great and all but way before the SNES then hardware makers realised tying up the CPU fetching data when it could be crunching numbers instead was less than ideal, to that end we have Direct Memory Access aka DMA. Some other systems, usually ones based on a CD or that have a file system, will instead have a dedicated read command/memory area/handler but it is still going to be location in the ROM and how much of it to read.There are a handful of tracing (the act of working backwards using breakpoints and such is called tracing) guides for the SNES but I have not read them to see if I like them in recent times, though you can certainly have a scan through of what is here. I normally instead link https://www.romhacking.net/documents/361/ which is for the GBA, and for a command line activated emulator at that, but the principle is the same whether you are on a commodore 64 or Switch game released yesterday.
Quote from: FAST6191 on October 18, 2021, 09:31:02 AMThat is a different matter, though related to the stuff from before.The main problem you will probably slam into early is VRAM limits. There is only a limited amount and many devs pushed it to the limit (or were limited themselves and had to make cuts accordingly).Animation works in one of a few ways on consoles1) Whatever the sprite handler can do. Translate, scale, rotate from basic maths, though not everything will have everything, and flip/mirror in some better systems.2) Swapping sprites out. Can also be half sprites (top half and bottom half being different to save memory/act as a type of compression if the legs can stay the same and top half do say victory dance or attack).3) Changing palettes. Can make for pulsing effects, status indicators, and most will also have the option to make things clear. Rarely will the VRAM be altered in play but it is a potential option too.4) Background interaction. Think disappearing behind a layer (characters getting into bed is usually this as the sheets would be above the player).You would most likely be doing 2 but we have seen things like smoother walking done by 1. Larger size would necessarily involve 1) as well.To that end you would want to get more data into the VRAM from your additions (easier said than done if it is all otherwise being used, if it is not all being used that instant then you might be able to swap out and back), and get the game to play those new sprites. Later games might have an animation list type file (the DS has a few for instance) but anything from old to new can and likely will still be CPU code somewhere in all this and you then get to change that. The same thing recommended for the VRAM stuff above also works on OAM (OAM = object area memory, object/obj being an alternative term for sprite) and thus whatever writes the OAM is something you get to investigate.So yeah it tends to be done only when absolutely necessary but is also not the worst hack to learn on, or work up to see if it is viable. Do also bear in mind that if this is a character used throughout the game then the VRAM has to be free throughout the entire time, aka you will probably want to playtest rather more extensively than most sprite edits people do where level 1 seeing it work for 10 seconds is likely good enough.
Quote from: Erockbrox on May 30, 2017, 08:03:19 PMI recently played The Brainies for SNES and while I liked the game there are two things that I will need to do an order for me to continue playing it. 1) Give the player infinite time2) Give the player infinite lives
Page created in 0.065 seconds with 19 queries.