lol that is amazing
Yes it’s hardcoded to target res, I verified this (as indicated in the conversation log in which I originally identified the oddity, which is probably in my doc somewhere)
It’s in the melee magic patch folder
so it is
now I’m wondering if the issue is FE7 only?
I think it’s just 7but I could be wrong
7 has that bug where the area in the VRAM for HP bar tiles isn’t wiped before the bars are drawn, resulting in garbage graphics during battle animations. AFAIK 6 and 8 don’t have this problem.
They were just really sloppy when they made 7, but since 7 is the most popular anyway, I write all the FEditor code for it first, which results in all of the FEditor code for it being sloppier than it is for 6 and 8 as well.
Maybe FE fans just like nasty garbage in general
Well I can tell from personally debugging several areas of the ROM 7 has pretty sloppy code all around and I think other assembly (not ASM) hackers would agree. The code that I replaced with this patch is like a third of the length of the original ended up NOP’s like 16+ bytes. I literally checked the weapon level for all four magics, OR’d them, and checked if it was 0. Since they intended for classes to strictly either be magical or physical, why not just have a bool for it in the class struct? Even if space was an issue(which it’s clearly not seeing as how the ROM is half the maximum size with random free space squeezed in) it’s a single bit; they could’ve packed it easily and it would’ve taken less code to do it. Sloppier, bigger, and less effective code seems to be the trend of 7
8 is superior but I think because you originally debugged a lot of 7 because of your waifu 8 ended up with less doc and inevitably less popularity among ROMhackers. Oh well
Edit: oh btw, my hack only checks if the CLASS has the bit so you can use the same bit for a different ability if it’s CHARACTER only like a “Lord” bit or something
Yup, I found that out when I tried to make Ninian specifically have Mag. Oh well, no biggie at all. In fact this raises a pretty interesting prospect; since the class/character abilities are fused, could we free up a fuckton more bytes in both by splitting them apart? Still sharing the useful functions. We don’t really need the ability to give a character the mounted aid system, for example, or the ability to declare a class a “boss”
I can edit it to check for characters also if you want, I mean I have enough space for it hehehe
To answer your question, yes you definitely can split them up and I was actually going to say to you that if you free up the 4 bytes from the palette pointer you can give characters their own bitmap and give the C&C bitmap over completely to classes which would be pretty useful and cool
Edit: actually now that I think about it the game differentiates class and character ability by ORing the two values so you can make EVEN more abilities if you say if the bit is set for the class AND character effectively doubling the amount of abilities you can apply but they’d have to be both applicable to characters and classes. Just a thought.
I probably shouldn’t have but I made another version that uses the byte that gets wasted from the portrait value in the character and class struct for those who don’t want to use up an ability. For characters its +7 bytes into the struct, for classes it’s +9 bytes in(it’s the byte that’s labelled as “UNKNOWN” after the portrait value). Leave it as zero for physical units, change it to any nonzero integer for magic.
PATCH