News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Author Topic: FF1 MMC5 Disassembly Updates  (Read 221095 times)

Vanya

  • Hero Member
  • *****
  • Posts: 1787
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #500 on: April 15, 2020, 09:27:21 pm »
Nice!
Part of me wants to say it's worth it. (That's totally the lazy part!)
But part of me wants to say it's more trouble than it's worth.

But if you do it, you may be able to use the space more efficiently if you can incorporate icons and abbreviations.

Code: [Select]
DMG: XX HIT: XX%
SPELL: ---------
SPEC: @@@@@@@@@@

This is just off the top of my head without checking if it'll fit in the box.
For armor, it'd be DEF and EVD.
The spell line is for the obvious.
And SPEC is for elemental icons. (Assuming there is space to add them.)

Jiggers

  • Sr. Member
  • ****
  • Posts: 415
    • View Profile
    • My Ko-Fi Page
Re: FF1 MMC5 Disassembly Updates
« Reply #501 on: April 16, 2020, 12:44:33 am »
The shop CHR does have 8 possibly-unused tiles for element icons--but again the issue is I don't want the player to have to try to sell their weapons to see this info. And the menu CHR would have to be re-organized to display element icons there, because while it does have free space as well, I worry that trying to print the string with low bytes will confuse the drawing routine into doing more control codes... Assuming we can figure out how to get the armor/weapon equipment status box displaying different things!

(Also there's elemental weakness and defense for armor, weapons can inflict ailments now, and have category bonuses still... so much information! I'm really tempted to just leave all that to "play and find out" or leave it up to romhackers who like to make manuals...)
« Last Edit: April 16, 2020, 01:00:05 am by Jiggers »
I know exactly what I'm doing. I just don't know what effect it's going to have.

I wrote some NES music! Its a legal ROM file. - I got a Ko-Fi page too.

Vanya

  • Hero Member
  • *****
  • Posts: 1787
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #502 on: April 16, 2020, 07:32:20 pm »
Good points.
In that case, just leave the basic info.

I will try to convince of one thing that I think would be pretty easy to do.

Add the Critical stat to the equipment screen and keep it in the shop menus.
There should be just enough space in the equip screen to include Critical at the bottom if you shift the stats up one line.

Beyond that, maybe it would be possible to add space for spells underneath Evasion?

Maybe by using the spell orb icon followed by the spell name?
And maybe the spell orb icon used can be made to match the spell type?
And if there's no spell, maybe it can have the x icon and dashes like in the magic menu?
Maybe?

...

I'll shut up now. :P

Jiggers

  • Sr. Member
  • ****
  • Posts: 415
    • View Profile
    • My Ko-Fi Page
Re: FF1 MMC5 Disassembly Updates
« Reply #503 on: April 16, 2020, 11:59:42 pm »
XD I do want to display Critical somewhere...

I don't want to spend too much longer doing this, so let's see if we can work out a good-looking solution before I lose interest again.

Take the Equip menu. As you said, all the lines below the name and class can be shifted up one, along with the sprite. In the Inventory bags, the bottom box can be shifted up to hide the upper borders behind the larger box. That would allow the Damage/Accuracy/Defense/Evasion text to be shifted up one, leaving Critical to be snug against the bottom borders of both screens.

I am not in favour of this, because reason A: Work.

What I do not mind doing is shifting Accuracy up and slipping Critical in its place, so that the whole thing looks like:

Code: [Select]
Damage    ##  Defense ##
Accuracy  ##  Evasion ##
Crit.Rate ## 

With no blank rows between them, but with blank rows above and below like most boxes.

Both formats leave a gap on the armour side. What do we fill it with? Spell cast only makes sense while browsing the Inventory, because otherwise you could have 8 possible spells to cast with your equipped gear, and how do you display THAT!

So that leaves Elemental Defense and Weakness. And we only have 12 tiles to put that info in. So I would say Elemental Weakness is more pressing information--not to mention easier to display. "Weak: @@@@@@" And just hope people don't edit the game so that someone can wear armour that makes them weak to more than 6 things at a time!

But, at the risk of overworking myself... What if there was ANOTHER armour stat we could display? One that doesn't exist yet? Or one that SORT OF exists, but which armour has no real control over?

Idea 1: HP boosting gear. A +50 HP helmet with no absorb? I'd probably slap that on my white mage.

Idea 2: JUST DISPLAY MAG.DEF JIGGERS ITS ALREADY IN THERE.

Idea 3: Add Mag.Def stat to armour too.

...

Meanwhile, while I've got shop descriptions updating automatically... There is a weird delay when first selecting buy/sell. I think it has to do with re-drawing the description box, and either way, all the text needs to be updated to have lots of $FF blank spaces to overwrite the previous text without re-drawing the box every time you move the cursor, so I'll try that first.
I know exactly what I'm doing. I just don't know what effect it's going to have.

I wrote some NES music! Its a legal ROM file. - I got a Ko-Fi page too.

Vanya

  • Hero Member
  • *****
  • Posts: 1787
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #504 on: April 17, 2020, 01:46:54 am »
Do you mean like this?



That would work.
(Though I'd probably leave the character name and class one line lower than in the pic I uploaded.)



The only issue with adding that stat to armors is that right now magic evasion only increases by leveling up. So we would have to adjust the growth rates to each class and figure out how much each armor should provide.

I have done some pretty extensive research into the stats in FF1 before, so I wouldn't mind doing all the work figuring out these adjustments as long as you can make it work.

Deal?
« Last Edit: April 17, 2020, 01:59:26 am by Vanya »

Jiggers

  • Sr. Member
  • ****
  • Posts: 415
    • View Profile
    • My Ko-Fi Page
Re: FF1 MMC5 Disassembly Updates
« Reply #505 on: April 17, 2020, 03:14:51 am »
Yep, just like that, but name and class one row down. And Mag.Def. instead of M.Evasion, in case it needs to be over 100.
The only issue with adding that stat to armors is that right now magic evasion only increases by leveling up. So we would have to adjust the growth rates to each class and figure out how much each armor should provide.

I have done some pretty extensive research into the stats in FF1 before, so I wouldn't mind doing all the work figuring out these adjustments as long as you can make it work.

Deal?

Already done on my end. XD I know my stuff is unbalanced as heck, though. Framework! That's the goal.

Pushing it to Github in a moment. Equip screen is still screwy, but the shops should be finished and in need of bug testing. I may have just also accidentally cleaned out my saves, so I'll have to cheat to get the airship and money and stuff to check other shops for item descriptions.

And for some reason class names are magic spells.

I know exactly what I'm doing. I just don't know what effect it's going to have.

I wrote some NES music! Its a legal ROM file. - I got a Ko-Fi page too.

Vanya

  • Hero Member
  • *****
  • Posts: 1787
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #506 on: April 17, 2020, 01:49:52 pm »
I suggest "M. Evade" instead of "Mag. Def." since MDef implies that it reduces damage in the same manner as Defense does, but that isn't the case as far as I know.
IIRC it reduces the chances that damage spells will do 2x damage and that status spells will inflict.

Jiggers

  • Sr. Member
  • ****
  • Posts: 415
    • View Profile
    • My Ko-Fi Page
Re: FF1 MMC5 Disassembly Updates
« Reply #507 on: April 17, 2020, 06:10:36 pm »
I disagree with the usage of M.Evade, as it implies physically dodging magic instead of absorbing it, and its weird to think of pieces of armour helping with dodging... BUUUUT I changed it anyway because it looks better in the shop window.  :P And 'cos I think other games use M. Evade and its probably just what people are used to...? And you know more about all this stat stuff, so I'll take your advice.

AND ITS ALL DONE. Equip screens should be working again, classes aren't spells, the shop window and everything is all lookin' great!

I did change Evasion in the Shop window to Weight, since the formatting of having the minus sign floating so far ahead of the numbers was annoying me. The code to make it all look sleek would be too much effort (and ROM space, and CPU cycles... probably), and Weight gives the same information: This is how much your evasion will suffer with this piece of gear.

Its all up on GitHub again, Breaking Boxes. I'll merge it back into the Master version once I get the battle flickering issues sorted out.

Epic Games put out Just Cause 4 for free so I don't know when I'll get that done. >.> With any luck I'll get motion sick in five minutes, uninstall it after finding out there's no camera mods, and figure out the flickering by midnight. HAH.



Edit: Forgot to mention, the code that updates the stats in the Inventory bag screen re-draws all the text as well as the numbers every time you move the cursor. I TRIED to make this more slimming in general, like the shops: Just draw the words to the screen, and only update the tiles with numbers. And instead of thinking "Ah, I can just split it into two writes, and make it vertical, and not worry about over-writing the text in between1" I thought "Hey didn't I make a control code that ignores tiles? What if I made one like it, but that jumps ahead one tile for the next write?" ... so I did that, and it was taking like 2 seconds to print all the numbers, and I was all like WHAT NO WHY and then I re-did all the old inefficient code again to work with the new positioning and stats and all and then I was done and wondering WHY the faster stuff didn't work and so I went to look at it and GOSH there it was, every single damn "move forward one tile instead of drawing anything" was polling for menustall and thus doing a frame for EVERY TILE before updating the tiles on screen and so I fixed that but I'm sticking with the more inefficient code because bugger doing it all again.

So now there's a new way to draw text over text without re-writing it, that isn't currently used. I'll probably fix it up so its like printing empty spaces instead of spaces, so its 2 bytes in a string to jump over how ever many tiles.
« Last Edit: April 17, 2020, 06:16:56 pm by Jiggers »
I know exactly what I'm doing. I just don't know what effect it's going to have.

I wrote some NES music! Its a legal ROM file. - I got a Ko-Fi page too.

Vanya

  • Hero Member
  • *****
  • Posts: 1787
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #508 on: April 17, 2020, 09:05:16 pm »
I disagree with the usage of M.Evade, as it implies physically dodging magic instead of absorbing it, and its weird to think of pieces of armour helping with dodging... BUUUUT I changed it anyway because it looks better in the shop window.  :P

That made me lol. :3


I did change Evasion in the Shop window to Weight, since the formatting of having the minus sign floating so far ahead of the numbers was annoying me. The code to make it all look sleek would be too much effort (and ROM space, and CPU cycles... probably), and Weight gives the same information: This is how much your evasion will suffer with this piece of gear.

Good call. I didn't even think about it.
On a side note, can armor be given positive values or is the whole thing still hardcoded to subtract weight from your evasion?


Epic Games put out Just Cause 4 for free so I don't know when I'll get that done. >.> With any luck I'll get motion sick in five minutes, uninstall it after finding out there's no camera mods, and figure out the flickering by midnight. HAH.

Ha! I lol'd again. :P




Edit: Forgot to mention, the code that updates the stats in the Inventory bag screen re-draws all the text as well as the numbers every time you move the cursor. I TRIED to make this more slimming in general, like the shops: Just draw the words to the screen, and only update the tiles with numbers. And instead of thinking "Ah, I can just split it into two writes, and make it vertical, and not worry about over-writing the text in between1" I thought "Hey didn't I make a control code that ignores tiles? What if I made one like it, but that jumps ahead one tile for the next write?" ... so I did that, and it was taking like 2 seconds to print all the numbers, and I was all like WHAT NO WHY and then I re-did all the old inefficient code again to work with the new positioning and stats and all and then I was done and wondering WHY the faster stuff didn't work and so I went to look at it and GOSH there it was, every single damn "move forward one tile instead of drawing anything" was polling for menustall and thus doing a frame for EVERY TILE before updating the tiles on screen and so I fixed that but I'm sticking with the more inefficient code because bugger doing it all again.

So now there's a new way to draw text over text without re-writing it, that isn't currently used. I'll probably fix it up so its like printing empty spaces instead of spaces, so its 2 bytes in a string to jump over how ever many tiles.

Eewww. Glad it's fixed, tho. Well done.
I'll check out the new build and report back if anything is fubar.



!

The github doesn't seem to have been updated.
I'm still getting the spells for class names.
« Last Edit: April 17, 2020, 11:07:49 pm by Vanya »

Jiggers

  • Sr. Member
  • ****
  • Posts: 415
    • View Profile
    • My Ko-Fi Page
Re: FF1 MMC5 Disassembly Updates
« Reply #509 on: April 18, 2020, 01:28:51 am »
That would be because I'm an idiot who still doesn't know how this GitHub thing works. (Seriously though, why doesn't it work when I try to add files to the ignore thing? Atlas/Script.txt, mapfile.txt, labels.txt, FinalFantasy.dbg... so annoying. But it ignores Atlas/Script.bin just fine when THAT changes!)

I forgot to, you know, push it. Pressing Commit doesn't work without that. Grr.

I got that pre-battle flash out of the way, but I want to see the battle sprites fade in, too.



Except if I put the sprites in before the fade in, they don't show up, only this one little corner of the Fighter's head, in the trees???

I think I need a refresher on how to do sprite loading... Order of events, for screen being off, when to do OAM, when to turn things on... urgh...
I know exactly what I'm doing. I just don't know what effect it's going to have.

I wrote some NES music! Its a legal ROM file. - I got a Ko-Fi page too.

Vanya

  • Hero Member
  • *****
  • Posts: 1787
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #510 on: April 18, 2020, 01:31:06 pm »
No worries. That's just what happens to us late at night. ;)

That is wierd, but it does sound like you just have to shuffle some stuff around.

Jiggers

  • Sr. Member
  • ****
  • Posts: 415
    • View Profile
    • My Ko-Fi Page
Re: FF1 MMC5 Disassembly Updates
« Reply #511 on: April 18, 2020, 11:32:51 pm »
I'm stumped on this.

Something is filling Sprite / OAM RAM with $10. In between frames. So while sprites are being loaded properly, they're being overwritten before drawn...

Update: $10 is Mesen's decay value, so the sprites are decaying in RAM before I can turn the screen on. Whoops!

Update 2: The issue was in that the screen was not turned on until the palette started fading in, and the frames it was doing don't DMA the sprites, and between the last DMA and the screen getting turned on finally, they were no longer recognizable as sprites, instead dis-configured into horrendous, dripping strands of chaos known previously only to those who have glimpsed beyond the stars in the fleeting moments before their minds atrophied and their souls bellowed for forgiveness. I slipped it in and everything's great now!

How do I merge Breaking Boxes back into the master branch?? Did I do it?



Vanya--I wanna reply to your magic post but I got sidetracked and noticed I couldn't walk under a bridge with an NPC on top of it. Suggestions? Make NPCs not walk on bridges somehow? Set a mapjob_flgs when they walk on a bridge, then if that flag is set, let the player walk beneath them?

In the original FF with the bug where NPCs walk over the player, does their sprite cover the player's?

https://wiki.nesdev.com/w/index.php/PPU_sprite_priority

If the player's sprite going under the bridge is set to background-has-priority (hides sprite behind bridge tile), does that mean they'd cover up the NPC on top of the bridge? I have so much trouble parsing the language used in this wiki...

I'm adding a Bugs.txt file to keep track of things as well.
« Last Edit: April 19, 2020, 03:56:20 am by Jiggers »
I know exactly what I'm doing. I just don't know what effect it's going to have.

I wrote some NES music! Its a legal ROM file. - I got a Ko-Fi page too.

Vanya

  • Hero Member
  • *****
  • Posts: 1787
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #512 on: April 19, 2020, 02:51:11 pm »
Update 2: The issue was in that the screen was not turned on until the palette started fading in, and the frames it was doing don't DMA the sprites, and between the last DMA and the screen getting turned on finally, they were no longer recognizable as sprites, instead dis-configured into horrendous, dripping strands of chaos known previously only to those who have glimpsed beyond the stars in the fleeting moments before their minds atrophied and their souls bellowed for forgiveness. I slipped it in and everything's great now!

Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn!!





Vanya--I wanna reply to your magic post but I got sidetracked and noticed I couldn't walk under a bridge with an NPC on top of it. Suggestions? Make NPCs not walk on bridges somehow? Set a mapjob_flgs when they walk on a bridge, then if that flag is set, let the player walk beneath them?

Ideally, letting the player pass beneath them without being able to interact is the best way to handle it.
If that isn't possible then making them not go on bridges is a good option.
You could also try making them not stop when on a bridge so that they always cross it immediately.


In the original FF with the bug where NPCs walk over the player, does their sprite cover the player's?

No idea.


https://wiki.nesdev.com/w/index.php/PPU_sprite_priority

If the player's sprite going under the bridge is set to background-has-priority (hides sprite behind bridge tile), does that mean they'd cover up the NPC on top of the bridge? I have so much trouble parsing the language used in this wiki...

It says each sprite has these properties, so it should only affect the specific sprite(s) you use these settings on.


I'm adding a Bugs.txt file to keep track of things as well.

Good idea. I should have thought of that, too.




Update:
I can confirm that Stealing is borked.
Successful steal draws the command menu to the screen instead of the stolen message.
Nothing gets added to my inventory if I succeed. (Tested against imps only.)
And here's the bigger one, but I'm not sure if it's related to stealing or just the number of rounds of combat. (Need to test more.)
After stealing from all 3 imps and then winning the battle, the game crashed after fading out the battle scene. The music just hangs at the end of the fanfare.

Next thing is that the chicken Knife raised the Thief's Critical score to 522, then when I switch back to another weapon it stays above 500. Not really sure what's going on there.

In Bugfix.txt: ideally, there would be glove pointers on every enemy with a flickering effect of some sort.
Hopefully showing them all at once on the 9 enemy formation doesn't break the 8 sprites per scanline limit.
(I checked. Each pointer and hero are only 2 sprites wide. Even with all 9 enemies present, the limit is preserved.)

That's all for now. I'll test more later.

I noticed another thing I wanted to make sure and point out.
In the magic shops, the characters don't animate to show who can learn a spell.
Can the animations from the other shops be enabled for the magic shops too?
That would be another thing to save players from having to look up.
« Last Edit: April 19, 2020, 03:58:33 pm by Vanya »

Jiggers

  • Sr. Member
  • ****
  • Posts: 415
    • View Profile
    • My Ko-Fi Page
Re: FF1 MMC5 Disassembly Updates
« Reply #513 on: April 19, 2020, 07:15:08 pm »
"You could also try making them not stop when on a bridge so that they always cross it immediately."

That's something that I doooon't want to deal with. Making slippery slidey tiles was hard enough, part of the problem being looking ahead more than 1 tile and getting the player to stop... NPC movement is even more of a headache because of the loops and all, I bet. Constantly updating. They'd totally crash into other NPCs and walk over each other if near bridges...

I went the really wimpy easy way out. If the player's sprite is hidden in any way (in water or under a bridge or in a secret passage), they can't talk to NPCs. Can still open chests and interact with other things! And NPCs just won't cross bridges. They already can't go into water or secret passages, so it should be fine...

Got the battle flickering cleared up entirely! Only the weapon frame lag and cheering to fix up. Then please, no more animations!

"Next thing is that the chicken Knife raised the Thief's Critical score to 522, then when I switch back to another weapon it stays above 500. Not really sure what's going on there."

Problem is I used a macro without checking how the macro was really being used! Its treating Critical as a 2-byte stat to print 3 digits. Adjusting it to steal the substats code a bit more instead. A proper fix would be to re-arrange character stats again, make sure the string drawing codes are all up to date and orderly, and then go through the rest of the code to make sure every string is using the correct stat IDs ... >.< I'm getting lazy... bad coder...!

I also realized that while level up caps hitrate (accuracy) and damage at 200, equipping a weapon does not. *sigh* That's a whole new level of bugs to fix isn't it? Should I leave it be or make sure that swapping gear caps these stats? It shouldn't be too difficult to do.

"Can the animations from the other shops be enabled for the magic shops too?"

Added that to the Bugs.txt Ideas section to remind myself to look into it.



Playing around with box connectors...



I like the bottom, not so much the top... Made the two top boxes have curvier connections:



But still not feeling it. Think I'll just stick with the bottom, so I don't have to also connect the item and magic menus.

Or should the stat window just have the text be flush to the top border like the bottom is? (That would save the MOST space...)

I also just coded in another control code to basically do map decompression with printing tiles... XD $0B,$09,$FF -- would print 9 $FF tiles. Gonna see what bytes I can save with that.



Fixing bugs was annoying me so I added more features instead.

Sound test screen currently broken, I'll fix it eventually...

Press start in the equipment inventory window! Nothing will happen if you can't equip the weapon; but check it in the battle items selection instead. There are some differences with having to press another button in the battle items selection after pressing start to select a new item; working on it.
« Last Edit: April 20, 2020, 05:15:12 pm by Jiggers »
I know exactly what I'm doing. I just don't know what effect it's going to have.

I wrote some NES music! Its a legal ROM file. - I got a Ko-Fi page too.

Vanya

  • Hero Member
  • *****
  • Posts: 1787
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #514 on: April 20, 2020, 09:39:41 pm »
"That's something that I doooon't want to deal with. Making slippery slidey tiles was hard enough, part of the problem being looking ahead more than 1 tile and getting the player to stop... NPC movement is even more of a headache because of the loops and all, I bet. Constantly updating. They'd totally crash into other NPCs and walk over each other if near bridges...

I went the really wimpy easy way out. If the player's sprite is hidden in any way (in water or under a bridge or in a secret passage), they can't talk to NPCs. Can still open chests and interact with other things! And NPCs just won't cross bridges. They already can't go into water or secret passages, so it should be fine..."

Fair enough. I was thinking about how that would affect the NPCs random movement, but I think it's fine.


"Got the battle flickering cleared up entirely! Only the weapon frame lag and cheering to fix up. Then please, no more animations!"

Groovy!


"Problem is I used a macro without checking how the macro was really being used! Its treating Critical as a 2-byte stat to print 3 digits. Adjusting it to steal the substats code a bit more instead. A proper fix would be to re-arrange character stats again, make sure the string drawing codes are all up to date and orderly, and then go through the rest of the code to make sure every string is using the correct stat IDs ... >.< I'm getting lazy... bad coder...!"

LOL. Yeah, at some point you might want to do that.
Let me know if there is any tedious work you ever need to have done.
I may not be great at coding ASM, but I can at least help get some things out of the way.



"I also realized that while level up caps hitrate (accuracy) and damage at 200, equipping a weapon does not. *sigh* That's a whole new level of bugs to fix isn't it? Should I leave it be or make sure that swapping gear caps these stats? It shouldn't be too difficult to do."

My understanding is that the "Damage" stat the game shows you in the status menu is supposed to be capped at 255.
If you go over 255 it rolls over to 0, so that is definitely a bug that should be fixed.
If Accuracy also overflows as Damage does then I think it should also be capped at 255. If it doesn't have an overflow bug, then you may be able to leave it alone. As long as the battle formula is the same as the original, then it already caps Accuracy + Base Accuracy at 255.


"Added that to the Bugs.txt Ideas section to remind myself to look into it."

Groovy, 2!



"Playing around with box connectors..."

[IMG]

"I like the bottom, not so much the top... Made the two top boxes have curvier connections:"

[IMG]

"But still not feeling it. Think I'll just stick with the bottom, so I don't have to also connect the item and magic menus."

"Or should the stat window just have the text be flush to the top border like the bottom is? (That would save the MOST space...)"

Save the MOST space and make sure the equip menu matches up.
Actually, might be a good idea to make all the menus more consistent by making them all span the whole width of the screen.



"I also just coded in another control code to basically do map decompression with printing tiles... XD $0B,$09,$FF -- would print 9 $FF tiles. Gonna see what bytes I can save with that."

Good idea.



"Fixing bugs was annoying me so I added more features instead.

Sound test screen currently broken, I'll fix it eventually...

Press start in the equipment inventory window! Nothing will happen if you can't equip the weapon; but check it in the battle items selection instead. There are some differences with having to press another button in the battle items selection after pressing start to select a new item; working on it."

Intriguing.




Update:

Ok, the crash that happens after battles seems to have to do with something other than the number of rounds.
I get the feeling that it probably has to do with the number of boxes that get drawn.
Just fighting with 4 FIGHTERS by itself doesn't lead to a crash unless the battle goes on for a while (7+ rounds).
However, spending 2 rounds just covering and then wiping out the enemy in 1 round also leads to a crash.
Then, purposefully taking 3 rounds to beat 3 IMPS doesn't have a crash.
But, getting a level up after taking 3 rounds to beat 3 IMPS does lead to a crash.

Also, while testing out the cover ability I noticed that an icon appears over some of the characters.
Looks like the 2 little bubbles or sparks or whatever.
Tested this with the 4 FIGHTERS party BTW.
« Last Edit: April 21, 2020, 08:38:58 pm by Vanya »

Jiggers

  • Sr. Member
  • ****
  • Posts: 415
    • View Profile
    • My Ko-Fi Page
Re: FF1 MMC5 Disassembly Updates
« Reply #515 on: April 22, 2020, 10:04:31 pm »
Looks like probably all the skills need to be updated to use the new boxes; that will be the next thing I focus on for sure. (DoPhysicalAttack_NoAttackerBox might be the cause for Cover. Its using Box #4. That's probably the wrong ID.) Should be fixed now. - some bugs may still occur...

The two dot icon is s'posed to be Regen... I don't immediately see that I set up the icons to do anything with Cover, so that's likely a case of me pushing the skill buffers around in RAM. Should be fixed now.

I DID notice that the upper left Imp seems to ignore Cover mechanics... Very strange. Hopefully fixed it by swapping a compare around, but if not, I at least think I know where the issue is.. Edit again: Yep, that didn't do it... Okay, think I got it this time. Upper left imp = attacker ID $01. Fighter doing the defending was in slot 2 (since slot 1 takes most of the attacks, this was the faster way to test cover), so that ID was also $01, when it should have been $81. So if the fighter at the top was covering someone who got hit by the imp in the back row in the middle, THAT imp would also have bypassed cover!

Hopefully when I fix all the other issues, there won't be any end of battle crashes. I'm not going to look into that until everything else is working as intended. Just assume for now that if something looks weird in battle, the game will crash at the end of it.

Also fixed up the Pressing Start thing, so that you don't have to press Start when selecting a battle item to carry. Hint: Cheat yourself a Light Axe into your inventory by setting $5E1C to $01. Armor is um... still needing some tweaks.  :-[ Should be fixed now! Whether or not armor and weapons have the right elements and such is to be seen...



Stealing should also work now. While adding $10 battle-only spells, I forgot to shift the item tables appropriately, so stealing from an imp would say "HEAL" but mean "10 G" ... once that was fixed, it was still giving 300 G!


April 27, 2020, 09:38:01 pm - (Auto Merged - Double Posts are not allowed before 7 days.)


Not sure about this. I think I prefer the single-box layout, and I want to keep Critical displayed (why not here if its everywhere else now?) and I fixed Mag.Def to M.Evade like everywhere else (maybe not in level up displays yet.)

But what other stat could be displayed to make this more even?

I updated a lot of things in Bank $0F. My original Intro code was a bloody MESS, and now I think it runs a lot smoother. I'm not sure about the distance the letters pop up (2 frames of middle blue, 3 frames of light blue, then white background tile updates as the letter hits the final spot; for the first 4 of those frames, the letter moves 1 pixel up and to the left. The 3 light blue frames can't be helped, to my knowledge. Since the background tile drawing takes an extra frame, I tried to set it to drop out 1 frame, but then it was like the background tile was drawing 2 frames early??? I gave up. ANYWAY: if this is too much, I can adjust the Y position to update less, so the letters are not traveling as far.)

Sound test screen now displays again! (It was a JMP instead of a JSR...) Almost everything uses DrawComplexString now, instead of its own version... I almost wonder if I can set up some more variables to make it usable for drawing Battle box text to RAM instead of to the screen... THAT WOULD SAVE SO MUCH SPACE TO DELETE THE BATTLE TEXT ROUTINES but no. More important things right now.



Another small edit. This makes room for 8 more tiles in CHR, and puts the text and fancy-box at the same height.





There! I wanted to use that stat anyway. I'll upload to Github once I'm sure its working.

At the moment, the idea is that hitting an enemy gives 1 spirit. Getting hit takes away 1. Being confused and hitting another player, both lose 1. Getting hit while guarding, praying, parrying, focusing, runicing, hiding, etc., all give 1 instead of taking 1 away. Caps at $FF. Dying sets it to 0.

It will have no effect until someone decides to use it. I don't really know what I'd use it for. Making Pray work better? Giving a boost to abilities? Divide it by 4 and tack it on to evade, accuracy, speed, whatever? USE IT AS JOB POINTS? (Don't panic, I won't.)

That fills up the last unused byte of character stats, too. Right now it should be 0 so I don't know why its 47 in that screenshot.

Edit: And that should be the final edit to this post because its a beast now. Spirit works so far! I added some tweaks to Praying, since that makes the most sense. So Failing gives 10 Spirit, doing a Pray spell uses up 10. Spirit is used in the fail calculations--Random roll between Spirit and $FF, need at least 160 to succeed. So a spirit of 160 always succeeds. So pray 16 times and fail, and 17th will be the one! Killing an undead enemy gives +3, and being hit while covering an ally as a Knight/Fighter gives +7.

Also fixed Critical hit displaying in menus; it was always reading the first character's byte.
« Last Edit: April 28, 2020, 01:26:01 am by Jiggers »
I know exactly what I'm doing. I just don't know what effect it's going to have.

I wrote some NES music! Its a legal ROM file. - I got a Ko-Fi page too.

Jiggers

  • Sr. Member
  • ****
  • Posts: 415
    • View Profile
    • My Ko-Fi Page
Re: FF1 MMC5 Disassembly Updates
« Reply #516 on: April 29, 2020, 10:41:45 pm »
Animation lag in battle should be fixed now. I re-organized the whole thing, but the problem was that updating character sprites, the first 4 top tiles of the character were being automatically updated on screen--just because those tiles were already in OAM. Then the actual sprite buffer updating wasn't happening until the frame after, then the DMA to refresh sprites on screen... so it would APPEAR that the pose was loading a frame earlier than the weapon was being updated.

Some changes to the sprite updating routine was done, so that 6 tiles can be written, and OAM DMA can happen within the same VBlank. It JUST wraps that up around cycle 260 of scanline 260. XD Cutting it SO close.

Being able to push the sprite to the stack, then pull it during VBlank would be a lot easier (8 tile updates are possible this way!), but with the way teleports and the WARP spell work, I don't fully trust doing that. If half the stack is full from someone wandering into thirty teleport pillars on the Castle of Ordeals, then loading up 6 tiles could potentially cause an overflow, crash the game after battle or when using WARP again, who knows exactly...

So, taking suggestions for how Teleport could work instead, if anyone's familiar with how it works already.

And confirmation that the animations are working would be good too! I tried to compare it to vanilla, and I THINK its fine, but I want to make sure.

Its strange, because it uses $08 to swap between the poses, based on if bit $02 is set. But that ends up with 1 frame with the weapon over the shoulder, 2 frames forward, 2 back, 2 forward, 1 back, then standing...

00001000 - Backward
00000111 - Forward
00000110 - Forward
00000101 - Backward
00000100 - Backward
00000011 - Forward
00000010 - Forward
00000001 - Backward
00000000 - done!

So I'm wondering if I should bother trying to make it more even? 2 frames backward, 2 forward, 2 backward, 2 forward, done?



Update 1:

Modified that. Now its 2 frames back, 2 forward, 2 back, 2 forward. I moved sprites around in OAM a little bit, mostly so that weapons/magic can display at the same time if that ever needs to come up. There's now 2 tiles between characters--the idea was that I could put some sprites above their heads when they're crouched, poison bubbles, sleepy Zs, stun shivery-lightning things... then I remembered the palette restrictions. So not sure what good that was.

I guess the best way would be to turn off the ailment sprites when action is underway. You only really need them when browsing menus to see what you should/can do. So once the turn begins, turn them off? That way they can just stay grey.

If the fixed bank is spacey enough I could also stick another palette change in for sprites... No that's dumb, because the cursor needs to be in the same area of the screen.
« Last Edit: May 01, 2020, 02:10:34 am by Jiggers »
I know exactly what I'm doing. I just don't know what effect it's going to have.

I wrote some NES music! Its a legal ROM file. - I got a Ko-Fi page too.

Vanya

  • Hero Member
  • *****
  • Posts: 1787
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #517 on: May 01, 2020, 01:32:45 am »
I'll have a look at things when I get a chance.
(Just got a Genesis Mini and I'm modding it into my dedicated retro console!)

About SPIRIT stat: So it's sorta like the character's morale/faith?
It's an interesting use of a stat and very different from the other games in the series.
I have some reservations about adding in a stat that fluctuates based on actions in battle.
That is more the domain of Final Fantasy 2.

That said, it is an interesting idea.
My purist side says change it into a more standard stat.
Make it a counterpart to INTELLECT and have INTELLECT affect black magic and SPIRIT affect White magic.
Then make both INTELLECT and SPIRIT affect MAGIC EVADE.

On the other hand, the designer in me says rename it to something more representative and less potentially confusing for veteran players and carry on with more interesting ideas.
Maybe have it affect most if not all of the special abilities that you added to each class?


About the attack animation: I'm kinda meh about it. Seems fine to me as is.

Jiggers

  • Sr. Member
  • ****
  • Posts: 415
    • View Profile
    • My Ko-Fi Page
Re: FF1 MMC5 Disassembly Updates
« Reply #518 on: May 01, 2020, 03:26:08 am »
Meh means I didn't screw it up, so I'll take it!

"My purist side says change it into a more standard stat." -- But... editing the level up code... is a nightmare.  :P

I was never keen on White and Black magic using different stats. What games do that? I think FF14 used to, or maybe still does. But here, its just wasting a byte of character stats. Its not like FF6 where you can sort of pick what stats level up with you. The only character it would even matter for is Red Mage. One stat for all magic boosting is fine by me; hell we haven't even gotten that working yet, since the math scares me too much to figure out what to do with it and where to put it in!

"Morale" is a GREAT name for it, though! Since Enemies have that. Could gain some for the whole party by winning a battle, lose some by running away. Having it change in battle does kind of suck--if its that important. Choosing 160 for the Pray effect to work was, I thought, a fairly good compromise, instead of it being the straight 50/50 chance it was before... A bit more like 1/3rd a chance to succeed, making it a tad riskier, but also raising the ease of success with every failure...

But in general, I plan to make it more fun--a nice boost when you have it, but not punishing if you don't. Like a limit break sort of thing! (Those would come at the worst times in FF9, making it nearly pointless except for long boss battles.)

Its also why I don't have any plans to put messaging for the stat in there. Rather than have something players want to meta game and build up by doing nonsensical actions (covering the party for 10 turns instead of killing the last enemy), its just tucked away on the Status screen being all mysterious.

"Maybe have it affect most if not all of the special abilities that you added to each class?" -- Definitely. Although Stealing is already pretty much based of FF6's algorithms and I don't want to risk breaking it for the 600th time, I suppose I could slip in a tiny boost there. 1/8th morale or something. A damage boost to Rush, when I get that worked in. Maybe a damage boost for Parry too. Intelligence boost for Focus. Even Runic has a 50/50 chance to fail against a Fiend/Chaos, and Morale could be used to make that a higher chance in the player's favor. Lotta neat things someone could do with this sort of stat.
I know exactly what I'm doing. I just don't know what effect it's going to have.

I wrote some NES music! Its a legal ROM file. - I got a Ko-Fi page too.

Vanya

  • Hero Member
  • *****
  • Posts: 1787
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #519 on: May 01, 2020, 01:39:20 pm »
Separate Black and White Magic stats: Final Fantasy 2, 3, 4, and I think also 11 all have separate stats for the two main categories of spells.

FF7 also has separate stats, but this time Magic and Spirit contribute to Magic Attack and Magic Defense respectively.

And FF9 has a Spirit stat that primarily affects various special abilities and how long Trance lasts.

So like around half the games do this or some variant thereof.
All of them function like normal stats in their respective games.
Yours seems to work kinda more as Brave and Faith do in FFT.


Quote
-- But... editing the level up code... is a nightmare.  :P
[/b]
I totally thought of this as I was writing. :P

Scary math: Leave that to me. I can at least tell you what the math should be doing.
Intellect, in particular, should be an easy one to implement despite not having a clear intention beyond it contributing to spell potency.
For most spells, it should probably just add like 1/8th or 1/16th to spell power.
Any spell that doesn't have a spell power probably shouldn't be affected by Intellect.
Spells cast from items probably shouldn't get a boost from INT either.


Morale: I think that's probably the best way to handle it. It matches up a bit with aspects of FF2, FF9, and FFT and I think that's a good thing to have in their granddaddy.