Search
Members
HelpUsers browsing this thread: 1 Guest(s)
The 15th Man Project: ASM Thread
08-14-2013, 10:22 AM
Child of Vector
 |
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.
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.
Let's Hack FF6 Stream: https://www.twitch.tv/b_run_
FFVI - Children of Vector: http://www.ff6hacking.com/forums/showthr...p?tid=2386
Monster AI Upgrade Patch: http://www.ff6hacking.com/forums/showthr...p?tid=2673
MMMMMagic 2.0: http://www.ff6hacking.com/forums/showthr...p?tid=3330
![[-]](https://www.ff6hacking.com/forums/ff9/collapse.png)
08-21-2013, 12:56 AM
Imp
 |
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.
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.
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.
08-23-2013, 02:17 PM
|
Imp
|
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.
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.
08-23-2013, 04:28 PM
|
Child of Vector
|
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.
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!
Quote:D8/E917: Pointers to pointers! used to make calling simple since different characters have different length OAM data
45 E9 - Terra
57 E9 - Locke
69 E9 - Cyan
7B E9 - Shadow
8D E9 - Edgar
9F E9 - Sabin
B1 E9 - Celes
C3 E9 - Strago
D5 E9 - Relm
E7 E9 - Setzer
F9 E9 - Mog
0B EA - Gau
1D EA - Gogo
2F EA - Umaro
41 EA - Soldier
44 EA - Imp
47 EA - Leo
4A EA - Bannon
4D EA - Esper Terra
50 EA - Merchant
53 EA - Ghost
56 EA - Kefka
59 EA - Soldier 2
OAM pointers for various things:
(byte 3?)
D8/E945 - Terra
5C EA 10 - Save Screen
5C EA 10 - Pary Select
5C EA FF - Unknown/Unused
5C EA 10 - Shop
65 EA 10 - Shop Fanfare
5C EA FF - Unknown/Unused
D8/E957 - Locke
Locke
6E EA 10 - Save Screen
6E EA 10 - Party Select
6E EA FF - Unknown/Unused
6E EA 10 - Shop
77 EA 10 - Shop Fanfare
6E EA FF - Unknown/Unused
D8/E969 - Cyan
80 EA 10 - Save Screen
80 EA 10 - Pary Select
80 EA FF - Unknown/Unused
80 EA 10 - Shop
89 EA 10 - Shop Fanfare
80 EA FF - Unknown/Unused
D8/E97B - Shadow
92 EA 10 - Save Screen
92 EA 10 - Pary Select
92 EA FF - Unknown/Unused
92 EA 10 - Shop
9B EA 10 - Shop Fanfare
92 EA FF - Unknown/Unused
D8/E98D - Edgar
A4 EA 10 - Save Screen
A4 EA 10 - Pary Select
A4 EA FF - Unknown/Unused
A4 EA 10 - Shop
AD EA 10 - Shop Fanfare
A4 EA FF - Unknown/Unused
D8/E99F - Sabin
B6 EA 10 - Save Screen
B6 EA 10 - Pary Select
B6 EA FF - Unknown/Unused
B6 EA 10 - Shop
BF EA 10 - Shop Fanfare
B6 EA FF - Unknown/Unused
D8/E9B1 - Celes
C8 EA 10 - Save Screen
C8 EA 10 - Pary Select
C8 EA FF - Unknown/Unused
C8 EA 10 - Shop
D1 EA 10 - Shop Fanfare
C8 EA FF - Unknown/Unused
D8/E9C3 - Strago
DA EA 10 - Save Screen
DA EA 10 - Pary Select
DA EA FF - Unknown/Unused
DA EA 10 - Shop
E3 EA 10 - Shop Fanfare
DA EA FF - Unknown/Unused
D8/E9D5 - Relm
EC EA 10 - Save Screen
EC EA 10 - Pary Select
EC EA FF - Unknown/Unused
EC EA 10 - Shop
F5 EA 10 - Shop Fanfare
EC EA FF - Unknown/Unused
D8/E9E7 - Setzer
FE EA 10 - Save Screen
FE EA 10 - Pary Select
FE EA FF - Unknown/Unused
FE EA 10 - Shop
07 EB 10 - Shop Fanfare
FE EA FF - Unknown/Unused
D8/E9F9 - Mog
10 EB 10 - Save Screen
10 EB 10 - Pary Select
10 EB FF - Unknown/Unused
10 EB 10 - Shop
19 EB 10 - Shop Fanfare
10 EB FF - Unknown/Unused
D8/EA0B - Gau
22 EB 10 - Save Screen
22 EB 10 - Pary Select
22 EB FF - Unknown/Unused
22 EB 10 - Shop
2B EB 10 - Shop Fanfare
22 EB FF - Unknown/Unused
D8/EA1D - Gogo
34 EB 10 - Save Screen
34 EB 10 - Pary Select
34 EB FF - Unknown/Unused
34 EB 10 - Shop
3D EB 10 - Shop Fanfare
34 EB FF - Unknown/Unused
D8/EA2F - Umaro
46 EB 10 - Save Screen
46 EB 10 - Pary Select
46 EB FF - Unknown/Unused
46 EB 10 - Shop
4F EB 10 - Shop Fanfare
46 EB FF - Unknown/Unused
D8/EA41 - Soldier
58 EB FE - Save Screen
D8/EA44 - Imp
61 EB FE - Save Screen
D8/EA47 - Leo
6A EB FE - Save Screen
D8/EA4A - Bannon
73 EB FE - Save Screen
D8/EA4D - Esper Terra
7C EB FE - Save Screen
D8/EA50 - Merchant
85 EB FE - Save Screen
D8/EA53 - Ghost
8E EB FE - Save Screen
D8/EA56 - Kefka
97 EB FE - Save Screen
D8/EA59 - Soldier 2
A0 EB FE - Save Screen
Terra
D8/EA5C - Standing
02 80 01 00 39 80 11 02 39
D8/EA65 - Fanfare
02 80 00 04 39 80 10 06 39
Locke
D8/EA6E - Standing
D8/EA77 - Fanfare
02 80 01 08 37 80 11 0A 37 02 80 00 0C 37 80 10 0E 37
Cyan
D8/EA80 - Standing
D8/EA99 - Fanfare
02 80 01 20 3D 80 11 22 3D 02 80 00 24 3D 80 10 26 3D
Shadow
D8/EA92 - Standing
D8/EA9B - Fanfare
02 80 01 28 3D 80 11 2A 3D 02 80 00 2C 3D 80 10 2E 3D
Edgar
D8/EAA4 - Standing
D8/EAAD - Fanfare
02 80 01 40 35 80 11 42 35 02 80 00 44 35 80 10 46 35
Sabin
D8/EAB6 - Standing
D8/EABF - Fanfare
02 80 01 48 35 80 11 4A 35 02 80 00 4C 35 80 10 4E 35
Celes
D8/EAC8 - Standing
D8/EAD1 - Fanfare
02 80 01 60 35 80 11 62 35 02 80 00 64 35 80 10 66 35
Strago
D8/EADA - Standing
D8/EAE3 - Fanfare
02 80 01 68 3B 80 11 6A 3B 02 80 00 6C 3B 80 10 6E 3B
Relm
D8/EAEC - Standing
D8/EAF5 - Fanfare
02 80 01 80 3B 80 11 82 3B 02 80 00 84 3B 80 10 86 3B
Setzer
D8/EAFE - Standing
D8/EB07 - Fanfare
02 80 01 88 3D 80 11 8A 3D 02 80 00 8C 3D 80 10 8E 3D
Mog
D8/EB10 - Standing
D8/EB19 - Fanfare
02 80 01 A0 3F 80 11 A2 3F 02 80 00 A4 3F 80 10 A6 3F
Gau
D8/EB22 - Standing
D8/EB2B - Fanfare
02 80 01 A8 3B 80 11 AA 3B 02 80 00 AC 3B 80 10 AE 3B
Gogo
D8/EB34 - Standing
D8/EB3D - Fanfare
02 80 01 C0 3B 80 11 C2 3B 02 80 00 C4 3B 80 10 C6 3B
Umaro
D8/EB46 - Standing
D8/EB4F - Fanfare
02 80 01 C8 3F 80 11 CA 3F 02 80 00 CC 3F 80 10 CE 3F
Soldier
D8/EB58 - Standing
02 80 01 E0 37 80 11 E2 37
Imp
D8/EB61 - Standing
02 80 01 E8 35 80 11 EA 35
Leo
D8/EB6A - Standing
02 80 01 04 35 80 11 06 35
Bannon
D8/EB73 - Standing
02 80 01 0C 3B 80 11 0E 3B
Esper Terra
D8/EB7C - Standing
02 80 01 24 39 80 11 26 39
Merchant
D8/EB85 - Standing
02 80 01 2C 37 80 11 2E 37
Ghost
D8/EB8E - Standing
02 80 01 44 35 80 11 46 35
Kefka
D8/EB97 - Standing
02 80 01 4C 39 80 11 4E 39
Soldier 2
D8/EBA0 - Standing
02 80 01 E0 35 80 11 E2 35
sprite arrangement, 9 bytes each, 2 sets for each character
(standing still, facing left)
D8/EA5C: unknown
D8/EA5D: X position of head tile
D8/EA5E: Y position of head tile
D8/EA5F: head tile ID (start of 4-tile block)
D8/EA60: palette and other things; palette uses (0000 1110) bits
D8/EA61: X position of foot tile
D8/EA62: Y position of foot tile
D8/EA63: foot tile ID (start of 4-tile block)
D8/EA64: palette and other things; palette uses (0000 1110) bits
("fanfare" pose, both arms up, facing left)
D8/EA65: unknown
D8/EA66: X position of head tile
D8/EA67: Y position of head tile
D8/EA68: head tile ID (start of 4-tile block)
D8/EA69: palette and other things; palette uses (0000 1110) bits
D8/EA6A: X position of foot tile
D8/EA6B: Y position of foot tile
D8/EA6C: foot tile ID (start of 4-tile block)
D8/EA6D: palette and other things; palette uses (0000 1110) bits
Palettes:
35 = 0
37 = 1
39 = 2
3B = 3
3D = 4
3F = 5
Terra
D8/EA5C - Standing
D8/EA65 - Fanfare
02 80 01 00 39 80 11 02 39 02 80 00 04 39 80 10 06 39
Locke
D8/EA6E - Standing
D8/EA77 - Fanfare
02 80 01 08 37 80 11 0A 37 02 80 00 0C 37 80 10 0E 37
Cyan
D8/EA80 - Standing
D8/EA99 - Fanfare
02 80 01 20 3D 80 11 22 3D 02 80 00 24 3D 80 10 26 3D
Shadow
D8/EA92 - Standing
D8/EA9B - Fanfare
02 80 01 28 3D 80 11 2A 3D 02 80 00 2C 3D 80 10 2E 3D
Edgar
D8/EAA4 - Standing
D8/EAAD - Fanfare
02 80 01 40 35 80 11 42 35 02 80 00 44 35 80 10 46 35
Sabin
D8/EAB6 - Standing
D8/EABF - Fanfare
02 80 01 48 35 80 11 4A 35 02 80 00 4C 35 80 10 4E 35
Celes
D8/EAC8 - Standing
D8/EAD1 - Fanfare
02 80 01 60 35 80 11 62 35 02 80 00 64 35 80 10 66 35
Strago
D8/EADA - Standing
D8/EAE3 - Fanfare
02 80 01 68 3B 80 11 6A 3B 02 80 00 6C 3B 80 10 6E 3B
Relm
D8/EAEC - Standing
D8/EAF5 - Fanfare
02 80 01 80 3B 80 11 82 3B 02 80 00 84 3B 80 10 86 3B
Setzer
D8/EAFE - Standing
D8/EB07 - Fanfare
02 80 01 88 3D 80 11 8A 3D 02 80 00 8C 3D 80 10 8E 3D
Mog
D8/EB10 - Standing
D8/EB19 - Fanfare
02 80 01 A0 3F 80 11 A2 3F 02 80 00 A4 3F 80 10 A6 3F
Gau
D8/EB22 - Standing
D8/EB2B - Fanfare
02 80 01 A8 3B 80 11 AA 3B 02 80 00 AC 3B 80 10 AE 3B
Gogo
D8/EB34 - Standing
D8/EB3D - Fanfare
02 80 01 C0 3B 80 11 C2 3B 02 80 00 C4 3B 80 10 C6 3B
Umaro
D8/EB46 - Standing
D8/EB4F - Fanfare
02 80 01 C8 3F 80 11 CA 3F 02 80 00 CC 3F 80 10 CE 3F
Soldier
D8/EB58 - Standing
02 80 01 E0 37 80 11 E2 37
Imp
D8/EB61 - Standing
02 80 01 E8 35 80 11 EA 35
Leo
D8/EB6A - Standing
02 80 01 04 35 80 11 06 35
Bannon
D8/EB73 - Standing
02 80 01 0C 3B 80 11 0E 3B
Esper Terra
D8/EB7C - Standing
02 80 01 24 39 80 11 26 39
Merchant
D8/EB85 - Standing
02 80 01 2C 37 80 11 2E 37
Ghost
D8/EB8E - Standing
02 80 01 44 35 80 11 46 35
Kefka
D8/EB97 - Standing
02 80 01 4C 39 80 11 4E 39
Soldier 2
D8/EBA0 - Standing
02 80 01 E0 35 80 11 E2 35
#$D8 loaded (possible bank pointers)
C3C26F
C3ED5D
C3C22F
C3B318
C37C0B
C3C0E2 - Shop menu Bank loaded
C3B213
C378BD
C376BC
C362C9
C33490
C3194c - Save menu
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!
Let's Hack FF6 Stream: https://www.twitch.tv/b_run_
FFVI - Children of Vector: http://www.ff6hacking.com/forums/showthr...p?tid=2386
Monster AI Upgrade Patch: http://www.ff6hacking.com/forums/showthr...p?tid=2673
MMMMMagic 2.0: http://www.ff6hacking.com/forums/showthr...p?tid=3330
|
Imp
|
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.
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:
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.
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?
The info I've figured out overlaps with yours a bit, but I can supplement this.
Quote:(standing still, facing left)
D8/EA5C: unknown
D8/EA5D: X position of head tile
D8/EA5E: Y position of head tile
D8/EA5F: head tile ID (start of 4-tile block)
D8/EA60: palette and other things; palette uses (0000 1110) bits
D8/EA61: X position of foot tile
D8/EA62: Y position of foot tile
D8/EA63: foot tile ID (start of 4-tile block)
D8/EA64: palette and other things; palette uses (0000 1110) bits
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:
35 = 0
37 = 1
39 = 2
3B = 3
3D = 4
3F = 5
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?
08-23-2013, 10:54 PM
|
Child of Vector
|
(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.
Let's Hack FF6 Stream: https://www.twitch.tv/b_run_
FFVI - Children of Vector: http://www.ff6hacking.com/forums/showthr...p?tid=2386
Monster AI Upgrade Patch: http://www.ff6hacking.com/forums/showthr...p?tid=2673
MMMMMagic 2.0: http://www.ff6hacking.com/forums/showthr...p?tid=3330
|
Imp
|
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.
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.
08-24-2013, 12:12 PM
Emperor
 |
wow you two would make a dangerous mix holy crap LOL
"Sometimes ninjas do wrong to each other, and in dat way the force of tha earf' comes around da moon - and at that presence, da dirt, it overshadows the grass, so you're like, I can't cut dis grass, there's no sun comin' through. So in order to enable each other the two fruits have to look each other in da eye and understand we can only be right, as da ripe is wrong, you know what I mean?"
-HNIC
08-31-2013, 02:46 PM
|
Imp
|
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.
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.
09-09-2013, 10:16 AM
|
Child of Vector
|
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.
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.
Let's Hack FF6 Stream: https://www.twitch.tv/b_run_
FFVI - Children of Vector: http://www.ff6hacking.com/forums/showthr...p?tid=2386
Monster AI Upgrade Patch: http://www.ff6hacking.com/forums/showthr...p?tid=2673
MMMMMagic 2.0: http://www.ff6hacking.com/forums/showthr...p?tid=3330
« Next Oldest | Next Newest »
Users browsing this thread: 1 Guest(s)
2017