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

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

Vanya

  • Hero Member
  • *****
  • Posts: 1637
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #480 on: March 04, 2020, 05:50:12 pm »
Ah. I've been there many times.

No worries. I'm still going to keep messing with it on my end.

Got any useful notes to share?
My ASM skills are a bit lacking, so any wisdom would be appreciated. :3
« Last Edit: March 04, 2020, 05:55:41 pm by Vanya »

Jiggers

  • Sr. Member
  • ****
  • Posts: 354
    • View Profile
    • My Ko-Fi Page
Re: FF1 MMC5 Disassembly Updates
« Reply #481 on: April 04, 2020, 01:52:53 am »
Phew. Sorry, no real useful notes. Kinda late in saying that...  :-[

The feeling to get back into coding started up, and after letting it fester for a week, here I am... fixin' bugs. dest_x and dest_y don't seem to be used in drawing battle boxes, so now btldraw_max isn't sharing the same variable slot as btldraw_width_counter. Progress!

I'll figure out again how to use Github to update, but I got both the gear window and enemy names working again!

Attacking is broken. Boxes don't undraw properly when Praying. (Attacking is fine if done BEFORE praying. Praying did the party-wide regen spell, check the logic with that.) Magic probably still doesn't use the correct spell.

Will I get these fixed? Will I even remember what I was doing by tomorrow?? Suspense!
« Last Edit: April 04, 2020, 02:25:14 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: 1637
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #482 on: April 04, 2020, 04:02:36 am »
LOL <3
Glad you found a bit more inspiration.
I'm still unpacking from my move last month.
I have too much crap. :P

If you can get an update up on the git, I'll take some time to test it at least.

Jiggers

  • Sr. Member
  • ****
  • Posts: 354
    • View Profile
    • My Ko-Fi Page
Re: FF1 MMC5 Disassembly Updates
« Reply #483 on: April 06, 2020, 01:28:30 am »
I didn't even realize I had left changes un-uploaded since last time...

Current version up in the Breaking-Boxes branch!

A lot of the freezing was because I accidentally left the "# Hits!" box as ID 1, after structuring boxes in a way that 0 and 1 can't be used. This makes perfect sense in the context of how battle boxes are drawn... somehow.

And the magic issue was that I figured out I could cut down on the number of JSRs to draw the defender... then um, I guess forgot to take them out after working in the single call needed. :P So it was printing the defender twice, which was making it think that the background behind the defender's name was, well, the defender's name.

So the agenda is:
* Double check that the text inside boxes is not flashing to mostly black tiles and icons. This means that the game is taking too long to do something and isn't getting to WaitforVBlank before its already done drawing 2/3rds of the screen! Gotta fit all the battle logic and box buffering done before that scanline is hit.

* Change all the FlowClock spell stuff back to the original Stone stuff. Re-instate the stone palette in menus.

* Work in the palette changes for the battle screen. Palette address $3F0E needs to be the chosen box background colour at frame start, then switch to $10 once the backdrop is drawn, then switch back between drawing the last warrior and the rest of the battle boxes.

* Make sure the stone poses are loaded into tile CHR. Work out how to draw the warriors as stone, hide their sprite, then clear the tiles and re-instate the sprite when cured. Might have to push them out of the fake-3d alignment to do the tiles.

* Finally, tackle the animation logic again to make things load and flow better. Cheering after battle is still taking too many frames between poses.

Anything I forget?
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: 1637
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #484 on: April 06, 2020, 04:50:45 am »
Not that I recall.
I'll have a look at this sometime tomorrow in between finishing fixing up my living room/library and clearing my stuff out of the dining room and into the office where it all belongs. :P

And I'll keep an eye out for the things you mentioned above.

Jiggers

  • Sr. Member
  • ****
  • Posts: 354
    • View Profile
    • My Ko-Fi Page
Re: FF1 MMC5 Disassembly Updates
« Reply #485 on: April 09, 2020, 03:30:11 am »
I think I got most of Stone re-instated... What was the original text for using a Soft in the menu?

Next I need to figure out why trying to use a Soft in battle crashes the game while saying you're trying to use "Bolt".  Could potentially be a problem with me deciding to streamline the in-combat item use routine. I think I saved some bytes and made it so pure, soft, and eyedrops don't use the same "cured!" message at least...

Re-did the grey palette and reversed the cursor sprite so that the dark/light palettes all align properly. No more negative stoned warriors.

Also, curious to note... if someone is stoned, and you go to the weapon shop, they'll become coloured again. I'm not sure there's any way to fix this? I went with stone using the cheer pose, because its like, you got frozen in battle, so its more active-looking. Crouching is used for everything else, looks boring to me. But if cheering is used to indicate "can equip" in shops, and you bring a stoned guy in, their static cheer makes it look like they can equip everything--but they only come into colour when highlighting something they really can equip. So... bug, or feature? I could put the check for the "can equip" flag after the check for Stone...?

Fixed an oopsie with the re-arranged DrawComplexString routine where a string would be canceled early if the ailment icon wasn't healthy-heart.

And can I just say how insane it is, all the work I've done so far just to get one extra palette for the warriors in battle? Completely re-wrote the text boxes, how graphics are loaded, and mucking around with scanline timers... Taking out Stone was perfectly reasonable, but noooo... XD

So far loading the magic box is the only thing I noticed that flashes the black tiles over the text. I think this can be solved by just putting a WaitForVBlank somewhere in the decompression of magic stuff, mebbe.



Edit: AHA.

    JSR SetBtlDrawWidthCounter ; make sure strings don't write over the box borders
    JSR DrawBox_WaitForVBlank
    JSR FormatBattleString     ; decompress the string to the box's innards in RAM   
    JSR DrawBox_WaitForVBlank  ; < started too late
    JSR JigsBoxDrawToBuffer    ; copy the box to the screen buffer

Despite precautions, the magic box battle string is done being formatted some 30 scanlines after the point that sprites and background tiles swap. I'm going to see if I can work in a control code to wait for VBlank at a certain time inside the formatting.



Edit 2:

Might have gone overboard with the whole thing... But, now the issue is this:



Drawing the box to the buffer itself, starting after waiting for VBlank and doing audio for the frame, takes too long. I need to figure out how to split it in half.

Or I could undo ALL of that...



And just have the letters be in the same spot in both CHR pages. That leaves 3 rows of tiles for the battle icons and stone sprites in the background CHR. But leaves no room for adding, say, another enemy graphic or something neat like that to the background tiles... Thoughts?
« Last Edit: April 09, 2020, 06:20:11 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: 1637
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #486 on: April 09, 2020, 09:27:44 pm »
Quick Response:
I say go with the simpler solution (assuming I'm understanding everything that is going on); leave the letters all in one spot.

Jiggers

  • Sr. Member
  • ****
  • Posts: 354
    • View Profile
    • My Ko-Fi Page
Re: FF1 MMC5 Disassembly Updates
« Reply #487 on: April 09, 2020, 10:14:56 pm »
Another fix is to just not update audio for the frame immediately before setting up the buffer. Its 1/60th of a second. Cutting out the APU updates gives 2-3 extra rows of screenwriting time. Which just tells me that my edits to the APU are horribly inefficient...  :'( But its another work around.

The audio lag from before was more pronounced than 1/60th a second, right? I think it had something to do with the HP updating, so it was like 8/60 more like.

So here's my old code, with no audio for the preceding frame.


Edit: AH!

Using static X and Y to swap RAM, but still no audio:


Kasumi on the NesDev discord pointed out that I could save about 4 cycles each swap by having X stay 1 and use Y as 0 to swap the RAM back and forth. So I did that... saves about 10 scanlines??! Which is just enough to let the audio stay in for this frame!! Woo!

Using static X and Y to swap RAM, but WITH audio:


Edit 2:

And they suggested another edit that saves more cycles:
Using INY instead of INC tmp, plus audio:


Now ain't that cool?

New future problem:
I need to figure out how to delay box buffering until AFTER the first box in the top right corner is drawn. Then, for larger boxes (hopefully only Magic, but I think the Scan box might be pushing it too), work out a way to split this buffering into 2 frames. Which is gonna mean some more delicate use of zero page RAM. Need to figure out how much audio updating is using the temp stuff, at least. Can probably use cursor coordinates for some of the box work.

Logic is:
Draw the round counter box with chosen background colour.
Swap to grey for battle characters.
Do buffering of boxes and anything else while the enemies and characters are drawn.
Swap the box background colour back at the same time the sprite CHR is chosen for background tiles?
« Last Edit: April 09, 2020, 11:27:18 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: 1637
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #488 on: April 10, 2020, 05:27:00 am »
Yes, very cool. Also painfully obvious I have a lot to learn still when it comes to ASM and how everything works.

At the very least I can say that the logic seems sound to me.
No idea how to do all that, tho.
You need to make sure the palette swap happens on the first scanline after the whole round counter box is fully drawn and then again on the next scanline after the whole battle area is done.
I'm pretty sure there is a way to know which scanline you're on, but again no idea how.

Good luck!

Jiggers

  • Sr. Member
  • ****
  • Posts: 354
    • View Profile
    • My Ko-Fi Page
Re: FF1 MMC5 Disassembly Updates
« Reply #489 on: April 10, 2020, 04:38:27 pm »
Palette swapping mid-frame is SUCH a pain in the fluff.

How do we feel about removing the round counter box and just putting that info in the "Ready?" box? Something like:
Code: [Select]
  Round  1
   Ready?

  Yes   No


Its not a terribly useful feature to have it displayed all the time (Really I think its there because I wanted to see if I could make it, then kept it because no one complained.) It helps for knowing when Regen spells might fall off, but otherwise... no real purpose.

Update: Yeah, looks like with the palette update and everything, removing the box tiles from the background CHR would make the screen shake effect much cleaner! So there's another reason to take that box out.

Quote
I'm pretty sure there is a way to know which scanline you're on, but again no idea how.

Oh, figured that out long ago.

Code: [Select]
   LDA InBattle
    BEQ OnIRQ
        LDA #160
        STA $5203

OnIRQ:             ; IRQs point here, but the game doesn't use IRQs, so it's moot   
@LoopForever:
    LDA $5204      ; high bit set when scanline #160 is being drawn
    BPL @LoopForever

MMC5 registers, I think! Writing to $5203 with the scanline number sets a flag in $5204.



While I wait for help on this, I might uh... add one more feature. >.<

Pressing Select in the shop could display some text based on the item the cursor's pointing to. Display equipment stats, spell effects, item effects...



Super easy, barely an inconvenience.

Now I just need to write all the description strings!

Another question: Should this be the default behaviour? That is, soon as you're looking at an item its displaying stats/description, instead of "What do you want?" and it updates as you scroll through items?
« Last Edit: April 10, 2020, 09:23:26 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: 1637
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #490 on: April 11, 2020, 01:10:06 am »
Round Counter Box -> If it makes things easier, then removing the counter and having it show the info another way would be just fine by me.

Item Effect Description Feature -> YES!!! Y-E-S-!-!-! <3 <3 <3

Item Effect Description Default -> Double: YES!!! YES!!! Y-E-S-!-!-! Y-E-S-!-!-! <3 <3 <3 <3 <3 <3

Having information about the equipment in the shops would be fantastic.
It's that sort of thing that is taken for granted in later generations that is actually an awesome thing.
My laziness in not having to look this stuff up rejoices at the mere thought.

Jiggers

  • Sr. Member
  • ****
  • Posts: 354
    • View Profile
    • My Ko-Fi Page
Re: FF1 MMC5 Disassembly Updates
« Reply #491 on: April 11, 2020, 01:40:12 am »
XD That does seem to be the preference! Alright... will figure out how to make that work smoothly. I might disable it while selling, but allow the start/select to function for viewing stats... Or else replace the shop's title with "YOU ARE SELLING NOW"... or do neither and assume the player isn't an idiot? That works too. There is a confirmation before selling and you have to choose SELL first, so... yeah...

Have I gotten all magic spells explained alright?

Code: [Select]
'        |~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~|
CURE     | Lightly recover ^   HP for one    ^  party member.  |
HARM     | Lightly damage  ^ undead enemies  ^ with holy magic.|
SHIELD   |Enchant target's ^      armor.     ^                 |
BLINK    |Creates a double ^  image of the   ^     caster.     |
FIRE     | Lightly damage  ^    one enemy    ^    with fire.   |
SLEEP    | Attempt to lull ^   all enemies   ^   into sleep.   |
LOCK     | Attempt to trap ^    one enemy    ^    in place.    |
BOLT     | Lightly damage  ^    one enemy    ^ with lightning. |
LAMP     |  Recover from   ^    blindness.   ^                 |
MUTE     | Attempt to stop ^   all enemies   ^  from casting.  |
BOLT [S] |Protect the party^ from lightning. ^                 |
INVIS    | Turn the target ^    invisible.   ^                 |
ICE      | Lightly damage  ^    one enemy    ^    with ice.    |
DARK     |  Slight chance  ^     to blind    ^   all enemies.  |
TEMPER   |   Harden the    ^ target's weapon.^                 |
SLOW     |Attempt to limit ^   all enemies'  ^     attacks.    |
CURE 2   |Strongly recover ^   HP for one    ^  party member.  |
HARM 2   | Strongly damage ^ undead enemies  ^ with holy magic.|
FIRE [S] |Protect the party^    from fire.   ^                 |
REGEN    | Recover party's ^  HP over time.  ^ [Lasts 3 turns] |
FIRE 2   | Strongly damage ^   all enemies   ^    with fire.   |
HOLD     | Attempt to stun ^    one enemy.   ^                 |
BOLT 2   | Strongly damage ^   all enemies   ^ with lightning. |
LOCK 2   | Attempt to trap ^   all enemies   ^     in place.   |
PURE     |  Recover from   ^     poison.     ^                 |
FEAR     |May cause enemies^     to flee.    ^                 |
ICE [S]  |Protect the party^    from ice.    ^                 |
VOICE    |  Recover from   ^magical muteness.^                 |
SLEEP 2  |Higher chance to ^ lull one enemy  ^   into sleep.   |
FAST     |Grant the target ^ more chances to ^ attack per turn.|
CONFUSE  | Attempt to vex  ^   all enemies   ^  into insanity. |
ICE 2    | Strongly damage ^   all enemies   ^    with ice.    |
CURE 3   | Greatly recover ^   HP for one    ^  party member.  |
LIFE     |  Recovers from  ^      death.     ^                 |
HARM 3   | Heavily damage  ^ undead enemies  ^ with holy magic.|
REGEN 2  | Recover party's ^  HP over time.  ^ [Lasts 4 turns] |
FIRE 3   | Heavily damage  ^   all enemies   ^    with fire.   |
BANE     | Attempt to kill ^   all enemies   ^   with poison.  |
WARP     |Return the party ^ to the previous ^ level, or exit. |
SLOW 2   | Greater chance  ^  to limit one   ^ enemy's attacks.|
SOFT     |  Recover from   ^      stone.     ^                 |
EXIT     |Return the party ^   to the exit.  ^                 |
SHIELD 2 | Enchant party's ^      armor.     ^                 |
INVIS 2  | Turns the party ^    invisible.   ^                 |
BOLT 3   | Heavily damage  ^   all enemies   ^ with lightning. |
RUB      | Chance to erase ^    one enemy.   ^                 |
QUAKE    | Chance to send  ^   all enemies   ^ into the earth. |
STUN     | Greater chance  ^     to stun     ^    one enemy.   |
CURE 4   | Recovers all HP ^and ills for one ^  party member.  |
HARM 4   |Massively damage ^ undead enemies  ^ with holy magic.|
RUB [S]  |Protect the party^   from death.   ^                 |
REGEN 3  | Recover party's ^  HP over time.  ^ [Lasts 5 turns] |
ICE 3    | Heavily damage  ^   all enemies   ^    with ice.    |
BREAK    | Chance to turn  ^    one enemy    ^   into stone.   |
SABER    |   Harden the    ^ caster's weapon.^                 |
BLIND    | Greater chance  ^     to blind    ^    one enemy.   |
LIFE 2   |  Recover from   ^   death with    ^     full HP.    |
HOLY     | Heavily damage  ^   all enemies   ^ with holy magic.|
WALL     |Protect the party^    from all     ^    elements.    |
DISPEL   |Remove resistance^to elements from ^    one enemy.   |
FLARE    |Massively damage ^   all enemies.  ^                 |
STOP     |  Slight chance  ^     to stun     ^   all enemies.  |
BANISH   |  Slight chance  ^     to kill     ^   all enemies.  |
DOOM     | Greater chance  ^     to kill     ^    one enemy.   |

I'm confused about the grammar with Slow... is it "enemies' attacks" or "enemy's attacks"?

Some notes:
I'd like to re-jigger the Regen spells to better explain that potency is increased for each one as well. May not be possible.
Its hard to explain slight vs. greater chance with things that just rely on the target's HP being low enough to hit. :I
Light/Strong/Heavy/Massive damage okay? Wasn't sure of a good medium-potency qualifier word.
Some of the "attempt" descriptions can be changed, maybe? Not sure.

Also, as many of these lines are repeated... First, this wasn't originally my intention, I actually was considering allowing 5 single-break lines for spells, but then while seeing what fit into blocks of 17 characters each, I realized it was actually kind of hard to be verbose about it.

SO then... I remembered something FF2 does that I liked. It used extra item IDs for just... words. Certain town names pop up, and they're slipped into the dialogue string the way items are displayed in menus. So I've added in a "Common String" control code ($06) for these. Places names, character names, short phrases, whatever could be used more than a few times, can be called instead with this code, saving huge amounts of space in the dialogue banks. 8,688 bytes still in Bank A to cram with tables.



Updated the Github!

Short note to mention I re-arranged some code with the FormatBattleString stuff so its just a little easier to read through it and its not jumping around with branches and extra jumps quite so much. So if anything breaks with battle messages and not the boxes themselves, reminder to look there first.

Second thing: Folks on the NesDev Discord have gone over some stuff and helped get me set up with doing the palette change! This has two visible effects. The first being a weird flash at the start of battle, which I looked into and couldn't understand yet. The second being a constant line of white/grey pixels right at the top of the boxes. I don't know what it is or how to fix it.

Otherwise...? I think its basically done. Everything above the boxes should turn out grey.

I can start working on converting sprites to background tiles and so on after the weekend! I need to look into how to shift a sprite while loading it into CHR. Characters 2 and 4, if shifted 8 pixels to the right when loaded into background CHR, should match up with their sprites easily.



Ngnrnn...



Turning this into this is very vexing. I was able to shift the whole thing over 4 pixels, but I need to do that then shift another 4...

UPDATE!

So as I was trying the 50th Random Thing and thinking, "Disch would be disappointed in me right now, I don't know what I'm doing, this next thing isn't gonna work, I should give up and beg for help, I'm not good at coding after all..." Well!

« Last Edit: April 12, 2020, 12:51:42 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: 1637
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #492 on: April 12, 2020, 04:33:02 pm »
Cool stuff. I'll have a closer look later.
Right off the bat, tho. The "Slow" grammar is fine.

For the funky spells that rely on enemy HP being low (BTW, why the hell did they bother to implement the D&D spells that rely on the number of Hit Dice you can target?), you can say it affects weak enemies only. That should get the idea across without specifying the exact number of HP it cuts off at.

You might want to think of changing those HP reliant spells anyway.
They are not really very useful and I think most people would end up happier with spells that just work better on single targets.
Also, I suggest changing the Doom spell's name to Death.

OK. I'll have a closer look at all of these tonight. ;3

Jiggers

  • Sr. Member
  • ****
  • Posts: 354
    • View Profile
    • My Ko-Fi Page
Re: FF1 MMC5 Disassembly Updates
« Reply #493 on: April 12, 2020, 10:21:08 pm »


A lot more poking around and making sure its loading and unloading right for everyone. Lots of screen flicker still, but I fixed the timing of the palette write so that one line is offscreen. All sorts of tiny bugs with the stone process that I need to sort through. And sprites need to be adjusted to better fit the background tile layouts so its seamless.

But, nearing the end of this whole ordeal!

Good idea for the "only effects weak enemies" thing, I'll work on that. I'm not touching the spells though, someone else can do that if they want to. Groundwork's there for editing, they can make them super high hit-rate normal ailment spells or something!
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: 1637
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #494 on: April 14, 2020, 03:31:06 am »
Nicely done!!
I'll be the one messing around with the spells ... a lot. ;P

Variable targetting isn't included in your work, right?
If not, that's definitely something I'll want to try to tackle.
I think it would have been included if time had permitted.
Plus, I see it as a QoL improvement that would be beneficial for most users.

Let me get your opinion since you've been neck-deep in the battle code for a while now.
I figure that, at the very least, I'll need to add two new targeting types (variable enemies and variable allies) and new code to handle switching between single target and all targets.
Does that sound viable to you?

Jiggers

  • Sr. Member
  • ****
  • Posts: 354
    • View Profile
    • My Ko-Fi Page
Re: FF1 MMC5 Disassembly Updates
« Reply #495 on: April 14, 2020, 10:30:41 am »
It isn't YET... I think pushing left/right to swap between players and enemies and just re-loading the targeting from there might work? The rest is really just re-writing some spell logic to work differently. Cure becoming a single-target Harm for instance. A lot of groundwork for player vs. player attacks has been laid out by my updates to Confuse. And Reflect is planned... so I think it was always going to come eventually.

"new code to handle switching between single target and all targets" - HM... That would be a larger effort I think. Rather than each spell having a defined target byte that says what it can and can't target, each spell would have to... well, I guess the target byte would have to be used differently? Only 4 bits? "Can target all enemies", "Can target one enemy", "Can target all players", "can target one player"... oh, 5: "Only targets caster."

And then the matter of adjusting potency based on targets left. I don't really know how I'd do that, but my first thought is division is a no-no; possible, but highly annoying and takes up more space. So you'd figure out what the single-target potency is, divide it by 9 for enemies, 4 for players, (possibly another spell byte* to keep track of both), and then when it comes time to do the spell, multiply by... uh, 4 or 5, not sure which. Math isn't my thing.

* Depending what the max potency is, one byte could be fine, with low/high bits for enemy/player targets. NUKE has a potency of 100. If max potency for high or low bits is $F, times 9, then NUKE could have a single-target potency of 135. Intelligence stat could make up the difference to make the spell as effective as vanilla FF when targeting all enemies, if coded in right.

Or there's probably a way to do it with a small table...

But, gonna focus on what the list of bugs first. Getting closer to Stone working. There's another spot where the palette swap is coming in too late in a frame, when a character walks forward or back. I suspect that has to do with loading new sprite tiles. Since stone characters are background, there could be some funky overlap with sprites when the screen shakes; I set sprites to show up behind background tiles, I'll see how that looks. (Edit: Think it looks pretty good. Scroll is only 1-3 pixels extra, but not reversed, so it won't shake in a way that a character on top will move down over a character below--only a below character moving up. 3d battlefield effect preserved!)
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: 1637
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #496 on: April 14, 2020, 04:42:38 pm »
I'm not really thinking of adding in the more advanced targetting of Final Fantasy 2.
It seems like more trouble than it's worth at the moment.
I'd like to stick to having just 2 new targeting values; one for enemies only, and one for allies only.
Otherwise, you'd obsolete several spells.

Spells still use a targeting byte, no?

This:
Quote from: slickproductions
IV- Targetting Byte ;
 The Targetting byte simply denotes the Targetting system of the magic
  01 = All Enemies
  02 = One Enemy
  04 = Spell Caster
  08 = Whole Party
  10 = One Party Member

Wouldn't it be simpler just to use the existing bits?
For example, if I set the 01 and 02 bits, then I can just check for 03.
I'm pretty sure the existing code doesn't handle that bit combination.
Then it's just a matter of allowing the player to switch targetting by pressing a button.
For the sake of simplicity, pressing select might be a good option.
But if there's room for it, left/right on the enemy/party is more consistent with the other games in the series.

I agree about the spell potency.
Multiplication is easier.
I think that the factor to use when multiplying the potency should be based on the number of remaining targets.

For example, for a 'Variable Enemy' targeting byte (03), the multiplier would equal the maximum party size minus the remaining number of enemies plus 1.

So let's assume the enemy party uses the '9 small enemies' formation.
Let's say there are 5 enemies on the field left alive.
The spell potency for a variable enemy target spell that is set to target the whole enemy party, in this case, would be 9 - 5 + 1 = 5x.
If all the enemies are alive the multiplier would be 1x (9-9+1).
If one enemy is left, the multiplier would be 9x (9-8+1).

There is one issue, though, maximum spell potency would vary depending on the size of the enemy formation.
The '2 large, 6 small' formation would have a maximum spell potency of x8.
It would be x1 for the major boss battles.

So instead of calculating things based on the actual formation size, we just always assume it's 8 and make sure to have an underflow check for the '9 small' formation.

That way the minimum multiplier is always 1x and the maximum is always 8x.

For 'Variable Party' targeting, we have 2 options:
Have an entirely separate subroutine that does the same thing and as the 'Variable Enemy' version, but uses a 4x multiplier instead. (That would be terribly inefficient.)
Or, have some extra code that converts the multiplier.
4 party members = 8-4+1=5x. -> 2x4=8 -> 8-8+1=1x.
3 party members = 8-3+1=6x. -> 2x3=6 -> 8-6+1=3x.
2 party members = 8-2+1=7x. -> 2x2=4 -> 8-4+1=5x.
1 party members = 8-1+1=8x. -> No Need to Convert

So this is what I would need to do:
-Add some code to the targeting subroutines to check for the two new targetting bytes.
-Add new subroutines that allow switching between single and group targeting if either of the variable target bits is used.
-Add new code to the spell logic that applies a targeting multiplier if either of the variable target bits is used.
-Recalculate the potency of all spells that will use either of the new variable target bits.

Is that about the gist of it?
Am I missing anything important?



On a side note, I believe the simplest form of multiplication and division in ASM is bit shifting.
But, by itself, it can only do doublings.
00000001 (1) -> 00000010 (2)
00000100 (4) -> 00001000 (8)

But the in-between values can be accomplished by taking account of remainders.
So if we want to multiply by an uneven factor; say 5.
We bit shift twice and then add the original value.
So 1 x 5 looks something like this:
00000001 (1 x2) = 00000010 (2 x2) = 00000100 (4)
00000100 (4 +1) = 00000101 (5)

If I understand it correctly, it then just becomes a matter of managing values.



Good to hear!
I think that the changes to the battle system are going to be the highlight of this work and the 3D-ish-ness of it is a great visual indicator that this is above and beyond the average.

Jiggers

  • Sr. Member
  • ****
  • Posts: 354
    • View Profile
    • My Ko-Fi Page
Re: FF1 MMC5 Disassembly Updates
« Reply #497 on: April 14, 2020, 08:47:03 pm »
Too much math, brain hurts... (also waking up at 8 AM after sleeping at 4...)

I'll respond to that when I can--just wanted to post this again. https://www.youtube.com/watch?v=N5M1uq3y0u4 Because while showing a friend I realized the treasure chests close while the dialogue box pops up...! Grr another bug to fix...



Magic descriptions should be up in shops now. And stone should work in battle maybe? Apart from flickering issues.

I haven't checked Onrac or Leifen because getting there is a pain. I think I've fixed all spacing and spelling errors for the rest of the spells. Tried my best to center the text, but if something is really looking off, let me know--its either a DTE space I didn't catch*, or just looks off and needs one less or more space to align things nicer.


(* I forgot about DTE when cleaning up the Atlas code and tagging it all, so I was adding spaces like crazy thinking, "I must have deleted the first space on every new line when macroing this together..." NOPE then I had to remove all the spaces I added... So might have missed some.)
« Last Edit: April 15, 2020, 12:03:41 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: 1637
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #498 on: April 14, 2020, 10:47:40 pm »
Gawd! I did that this morning, too!
Never good. We should get to bed at more decent times like 1 am. :3

Take your time. :)

Jiggers

  • Sr. Member
  • ****
  • Posts: 354
    • View Profile
    • My Ko-Fi Page
Re: FF1 MMC5 Disassembly Updates
« Reply #499 on: April 15, 2020, 05:33:44 pm »
Finished setting up the descriptions for weapons and armor.

I don't really want to display Critical here without it being displayed somewhere else in the status menu. A stat that can only be viewed in shops? Dumb. But re-writing the whole equipment screen's stat display to show Critical would be... uegrhrhghh... So I'm thinking just take the whole display out.

Likewise, I can't display all the elemental weakness, strengths, and information like spells cast...



Now since this display is manual--that is, if you edit the weapons, you will have to also edit the display's references...



I would have to write some code to do the following:
* Check shop type for weapon/armor (easy, already does that)
* Check item to get ID (easy, already does that)
* Use the ID to check the stats and save them in RAM
* Start building a string with the Damage, Accuracy and Critical text in RAM
* Swap banks to 0E
* Convert the stats to decimal one at a time
* Get the output and put it into the string in RAM
* Then write that string to the box.

Is it worth it to set that up, or should I make people suffer with updating weapon stats in 2 places?
... now that I say it, it sounds like its worth it... bother.

Anyway more screenshots!



Huh... that doesn't look write right (edit: how tired am I?)! Whoops, looks like I swapped Defense and Evasion around! Silly me.



Centered the text downwards a little more and updated all the strings to show the proper stats.

Next: Do the thing I talked myself into doing, or make it display all this without pressing start/select? Or ignore it and go back to fixing up battle flickering...

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.