The 15th Man Project: ASM Thread - Printable Version +- FF6 Hacking (https://www.ff6hacking.com/forums) +-- Forum: Esper World (https://www.ff6hacking.com/forums/forum-43.html) +--- Forum: The 15th Man Project (https://www.ff6hacking.com/forums/forum-52.html) +--- Thread: The 15th Man Project: ASM Thread (/thread-2211.html) |
RE: The 15th Man Project: ASM Thread - B-Run - 08-14-2013 We'd be glad to have the help. Thanks! The magic list is unclaimed at this point also, it technically remains to be seen if the character will use magic at all, but I would imagine people will want it. I had planned to tackle it at some point, but feel free to take a crack at it. We hadn't decided how we wanted to implement it. My original idea (which was beyond this project), was to totally rewrite how the game handles the magic lists to decrease the RAM needed for each, allowing us more space, but there's also the option of splitting up the rest around the unused RAM and creating functions for that specific character ID to read and write correctly. It really comes down to who's hacking it and how they want to do it. We are working from a fresh ROM for the project so you can do pretty much anything you want. As for the Colosseum, I have no experience with it, so I couldn't say how easy/hard it would be. RE: The 15th Man Project: ASM Thread - Eggers - 08-21-2013 I haven't been looking at / editing the code directly yet, but I've been thinking about how to add a new magic list. The way I see it, there are a few plausible ways to go. #1. The idea proposed by Edrin earlier in the thread. This should work, and be seamless to the player, and it should free up enough empty space in the memory. Quote:I had an idea where instead of having a byte per spell, having a byte per esper followed by a bit per spell, then let the game figure out which spells the character knows from there... So, to restate the idea, instead of storing in memory the %learned for each spell, we would store the MP earned (or AP earned, or whatever you want to call it) for each esper. And then we would calculate "does the character know the spell?" by a formula involving all the Espers that teach that spell. For instance, %learned for Bolt 1 would be: (AP-for-Ramuh * 10) + (AP-for-Bismarck * 20) + ... whatever (are there any others that teach bolt?). This would work. As Edrin said, there is also the matter of items that teach spells. We would have to basically treat each item as an esper. We still have room, I think? But it would mess with the ability of other modders to freely edit which items teach spells. #2. Spells only go up to 100%, but they're stored in a byte which can hold up to 255%. We could make each spell take up only 7 bits. This would mean we would need to do a little bit shifting every time the spell list is loaded. But it should free up more than enough room for an extra spell list (almost two). I can't see too many drawbacks to this, other than the difficulty writing it, which I hope wouldn't be TOO bad. It could be combined with Edrin's idea #1 for even more space saving. #3. Both the most interesting and least interesting idea. A brute force approach that may or may not have serious drawbacks. Expand SRAM and use it as extra working memory. I recently used SRAM to store a cache of palette-usage data for my palette hack, in space outside any save game. There are a little less than $200 bytes of free space of SRAM which can store something or other. What's even more interesting, though, is that you can expand the amount of SRAM to many times its original size just by editing one byte of the ROM. I don't believe anything stops us from using SRAM as extra working memory. According to docs, it takes only slightly longer to save/load SRAM, compared to regular ram (8 cycles versus 6). After expanding SRAM to 2x, 4x, even 8x or possibly 16x its original size, we could (maybe) use it to store anything we want. Both expand the size of save game, and use it as extra working memory, to store constantly-updated values of character stats, spells, and so on (which are then copied to a "save game" partition of SRAM, when you save). With this, we could add new spell lists, new spells, new Espers, even whole new characters, without much problem. There are hardcoded limitations that make it hard to have more than 16 character "slots", I'm aware of. Event scripts assume PCs are numbered 1-16, and 17+ refer to NPCs. But, still, it would be no problem to find room for a new spell list. Are there significant drawbacks to this? I've goggled for it. Many of the results pertain to real hardware. Most people who "know" seem to say it is no big problem to use SRAM as working memory on a real cart. Though few SNES games actually do it. It doesn't "wear out" or anything. It's just a kind of RAM. It costs less power to keep it active, as long as you don't actively read or write to it. That's why it's easier to back up by battery. The power savings go down, and it might even become less efficient than regular ram if you read/write it often. That might be why it's not OFTEN used as working RAM on real hardware. But it can be. On emulators, certain emulators may cause problems. Some emulators (ZSNES) can optionally NOT reload SRAM when you reload a save state. This is so you don't accidentally overwrite your save game. That causes problems, though, on the few games that use SRAM as working memory. So, it would be a problem under certain circumstances, for people who use emulators and save states with the wrong options set. It also could potentially be a problem for emulators for systems like the Wii and DS and PSP, which write files to flash media, which DOES wear out if written too often. But, I think those emulators don't actually write SRAM that often. They just save it in their own RAM, and write it when you exit the emulator. I don't know. There is actually pretty little information about this. The best way to figure it out might be just to test it on various emulators, and see how many problems it causes. But, if it worked, it could potentially facilitate a lot of things, including but not limited to the 15th character hack. RE: The 15th Man Project: ASM Thread - Eggers - 08-23-2013 Edrin: I'm currently making some changes to the OAM in the shop menu and other screens, for use in my palette hack. I'm wondering if maybe we should share information in some way. It could make life easier for both of us. Or we might want to make sure our patches are compatible, if we want to use the new/expanded palettes with the 15th man patch. Or, if you like this idea and find it feasible, it's even possible you could send me your notes and/or existing code, and I could be responsible for the menu oam part of the hack. Then you could switch your responsibility to the magic list, since you've already done a hack with the magic system. I don't necessarily want to take over from you. It depends on a number of things, including how attached you are to this particular project, how far along you are, how easy it would be for me to make use of your existing work, whether you like the idea of doing the magic instead... and so on. But we should probably at least collaborate in some way if we're working on similar things at the same time. RE: The 15th Man Project: ASM Thread - B-Run - 08-23-2013 I don't think we will be using your colors patch in the 15th Man Project as it is beyond the scope of what we are doing. The only reason we would do it would be if our sprite needed it, which it doesn't. But I am more than happy to share my notes if it will help you. Quote:D8/E917: Pointers to pointers! used to make calling simple since different characters have different length OAM data The main problem I have at the moment is that the Head and Foot tile IDs seem to be unique, some numbers repeat close to the end, but its only once you get into the extra NPC characters and the IDs for the save menu are different from the IDs in the shop menu... all that to say, there seems to be limited space for these IDs. I'm willing to bet I can track down the code for this and alter it to make it so I can add more IDs, but I haven't taken the time yet to do that. Its not insurmountable, just a lot more work that I had originally bargained for and I still don't know exactly how the code works so the solution path I take depends on how the code works for those IDs. All of that had nothing to do with what you are talking about... just wanted to give you to totality of where I am at. My plan is to move the whole of the OAM data (apart from the original pointers to pointers) to a new bank and expand the data from there. What this will mean is that this data will no longer be editable with FF3usME, it will have to be done manually. The only thing that may end up significantly altered as far as the actual data is concerned is the head and foot IDs. But since I haven't dug into the code yet, I don't know exactly what is going to change yet. Chances are I will make provision for 1-2 characters for the 15th Man project, then work on a full expansion later. Hope this helps... ... ...Happy Hacking! RE: The 15th Man Project: ASM Thread - Eggers - 08-23-2013 Cool. That is helpful info. Thank you for tracking down all those pointers to pointers. The info I've figured out overlaps with yours a bit, but I can supplement this. Quote:(standing still, facing left) Based on looking at the data you posted, and the data I've been manipulating myself, I'm 99% sure that first "unknown" byte is the number of sprites to load into OAM. N sprites worth of data immediately follow. Each sprite is a 16x16 tile (on these menus at least), and so the character head and feet make two tiles. That's why all blocks for character sprites begin with 02. Here's the OAM data for the hand cursor, for instance. 01 80 00 00 3E It begins with a 01, because there's only one sprite to load in this block of data. (I've also seen a piece of OAM data that just has a zero for the first and only byte, which loads an empty sprite.) One thing I notice in the data you posted is that all the X and Y values are set to the same value, which is probably a dummy value. Probably another piece of code is responsible for tiling them, and you'll have to find that. So, these tables don't determine the position on the screen. They only determine the palette and the location in VRAM where the graphics are supposed to be. (This is also true of the hand cursor, which is loaded in a dummy position, and then repositioned by other code.) Also, a note on the palettes. You may or may not be aware of this information, but since it's not in your post: Quote:Palettes: As you said, the bits 0000 1110 specify a palette from the eight palettes in memory. The first "digit" of that hex number is 3 in all the cases you listed. This means that none of these sprites will be horizontally or vertically flipped (those are the top two bits 1100 0000), and they will both have maximum priority (they will appear over top of sprites with lower priority -- those are the next two bits 0011 0000). The second hex "digit" is the one that has the palette, as well as one bit not related to the palette. The palette number in palette memory (CGRAM) is specified by the next three bytes. So, the second hex digit will be the CGRAM palette number, times two, sometimes plus one. In the save/shop/party screens, the character palettes are loaded into palette slots 2-7, rather than their usual slots 0-5 (which would match the character's "palette ID" in ff3usME). As an aside, there are CGRAM palette slots completely wasted on these menu screens. The cursor doesn't even use its own slot. Instead, it steals four colors from Mog's palette, even though there's at least one free palette available for it on each of these screens. But anyway, your values up there are pointing to palettes 2-7. Also, all of them have the last bit set (0000 0001), which is related to the location of the sprite's graphics in VRAM. Quote:The main problem I have at the moment is that the Head and Foot tile IDs seem to be unique The IDs should be unique, because they represent locations in video RAM. The character graphics have been loaded from their ROM location, or possibly from a cache in main memory, by another block of code. These OAM tables don't specify where the graphics are in the ROM, but they do specify where they are in video RAM (or where they are expected to be). To make this work, you'll also have to track down and edit the code that loads graphics data into VRAM. Good tutorials are here, if you haven't seen them: http://wiki.superfamicom.org/snes/show/Sprites http://wiki.superfamicom.org/snes/show/SNES+Sprites If you seem to be running out of space in VRAM, keep in mind that the last bit after the palette is basically a part of the name table ID / VRAM sprite address. It's basically the most significant byte of a 9-bit address, indexing an area of VRAM partitioned for sprites. The other 8 bits are in that other byte you labeled "ID". The format of OAM data is weird. Since all of the characters seem to have that final, after-palette bit set to 1. You can probably find room for more if you set it to 0, accessing the other half of the table. But you'll have to make sure not to overwrite the cursor or anything. VERY IMPORTANT, LIFE-SAVING INFORMATION FOLLOWS: I only recently discovered this, and it's made graphics hacking so much easier. http://www.romhacking.net/forum/index.php?topic=9249.0 It's a SNES emulator with a debug mode that lets you view video ram, palette RAM, OAM, and so on, in real time, as the SNES runs. This is so much easier for graphics-related hacking than Geiger's snes9x debug. I would never have successfully pulled off the menu hacking I've done recently if it wasn't for this. ~~ I also have some info on the weird queue system block C3 uses to insert sprites into OAM, which you'll probably have to work with, and which I've partially figured out. I started writing about that, but I realized it would be pretty long. I don't know if it's too tangential for this thread. Maybe I'll start a new thread on graphics hacking in the main hacking forum? RE: The 15th Man Project: ASM Thread - B-Run - 08-23-2013 (08-23-2013, 09:44 PM)Eggers Wrote: One thing I notice in the data you posted is that all the X and Y values are set to the same value, which is probably a dummy value. Probably another piece of code is responsible for tiling them, and you'll have to find that. So, these tables don't determine the position on the screen. They only determine the palette and the location in VRAM where the graphics are supposed to be. (This is also true of the hand cursor, which is loaded in a dummy position, and then repositioned by other code.) They are relative values. If you notice, the fanfare Y value is one less than the Y value of the standing, that's because during the fanfare pose the character "jumps" up one additional pixel. Editing these values does change the position of the sprite. That info about the sprites in the VRAM will be very helpful, thank you. My task, it seems, is going to be making sure the VRAM has the correct sprites in it and that the code knows how to find the right ones if they dynamically change. Like I said, I haven't looked at the code yet for most of this. I just tracked down the data. I will definitely take a look. RE: The 15th Man Project: ASM Thread - Eggers - 08-23-2013 It looks like our two projects probably won't overlap that much, in terms of code or data modified. You'll probably need to change different routines than me. The reason I offered to take over the menu part is that I eventually want to make a hack that has both expanded palettes and additional PCs. So if I was going to hack the menus later, I didn't want to have to do it from scratch in order to combine that with expanded palettes, reinventing the wheel. (That, plus I'm already hacking vaguely related code. And, plus I wasn't sure if you wanted to use an expanded palette for the new character.) But, probably your code for this hack would be helpful to me if you release it. I'd be able to make use of it with small modifications, assuming you're OK with people borrowing it. So, if you don't want to switch, I'll tentatively commit to adding a new magic list? Or I could just do the coliseum, if you want to do the magic yourself because of your experience with that code. I feel like the coliseum is a smaller contribution, though. For the magic, I lean toward the 7-bit solution. I don't want to take the risk of playing with the SRAM idea for a project that doesn't require it. The reverse Esper lookup thing you proposed is also clever, though with minor drawbacks if someone wants to add more magic-teaching items. Let me know if you want a hint for dealing with the sort of weird OAM queue, which I've been struggling with. I have notes. But you may not have to deal with that directly if you just modify an existing function that loads a list of data into the queue. Off topic, but have you posted anything about the other mod you're working on? I assume this isn't the one you alluded to. You can PM me if you prefer. Good catch about the relative offsets by the way. RE: The 15th Man Project: ASM Thread - SSJ Rick - 08-24-2013 wow you two would make a dangerous mix holy crap LOL RE: The 15th Man Project: ASM Thread - Eggers - 08-31-2013 Edrin: In the process of hacking the party select menu for my palette hack, I tracked down some pointers that should be helpful to you. I learned how/where this menu loads character graphic data, and also how it decides where to store it in VRAM. The pointers to the character sprite sheets are duplicated, and in bank C3 they are loaded from a different list, rather than the one in C0 which you located and identified in your expanded sprites thread. The pointers used in C3 begin at CF/F911. Each entry is 4 bytes long. The first two bytes are the bank byte (which is stored as a word, even though it's only a byte long, so there's always a wasted byte containing 00). The next two are the address within the bank. This is 0x58 long, so a total of 22 pointers, for the first 22 sprites (ending with gestahl). There's also a table accessed by C3 when it loads these sprites for the menu, which tells where in VRAM to store the corresponding sprite. This table begins at CF/F8E5. Each entry is two bytes long, and there are again 22 elements, for the first 22 sprites. These tables are both accessed from the function beginning at C3/6CE9, which is a loop that loads all the sprite data into vram. It is used by at least the party menu. I haven't verified whether it's also used by the other menus in C3. RE: The 15th Man Project: ASM Thread - B-Run - 09-09-2013 So real life and my hack are taking up most of my hacking time. Eggers, do you think youd still be interested in finishing the OAM expansion for me? I have a couple ideas as to how to implement the code, but feel free to do things your way as you have already proven yourself quite capable. I'm willing to help out with logic and ideas and any bit of code you might need, but if you could head it up I'd be grateful. Also, If you need help with testing I can do that for you as well. We don't NEED to be able to handle full expansion, we only need one full slot for Iris and Iris' fanfare pose, but if its easier to work the code around full expansion, you can do that as well. I am planning on dropping her in as sprite ID $7A which is the first definitely unused slot. We will likely be able to use a lot of other ones, but this is the first one that doesn't look like it ever gets called by either map data or event code. |