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

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

Vanya

  • Hero Member
  • *****
  • Posts: 1752
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #620 on: July 09, 2020, 04:27:59 am »
Lol. That list will get handled when it gets handled. :P
I look forward to hearing some more tunes.
Can I request a simple chocobo song like the short one in FF3?
I'd like to have some form of chocobo presence in some capacity for this project and more so in my future branch. :D

Jiggers

  • Sr. Member
  • ****
  • Posts: 405
    • View Profile
    • My Ko-Fi Page
Re: FF1 MMC5 Disassembly Updates
« Reply #621 on: July 09, 2020, 05:59:03 pm »
AbsoLUTEly not. No. I must be firm about this! I WILL NOT DO A SHORT CHOCOBO SONG LIKE FF3.

IF I DO IT I WILL ADD THE FULL SONG.

I can think of few things more annoying than hearing only the first few bars of the chocobo theme over and over...  :P So yeah, if I have time, eventually, I'll do the whole thing!

The song I'm working on now isn't really for this hack... its just a song I wrote ages ago and wanted to hear how it would sound on the NES, and using a tracker is too difficult for me. So its a fun side-project for myself! But I'll post the mp3 here when its done.
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: 1752
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #622 on: July 09, 2020, 10:05:39 pm »
LMAO! I figured you might say something like that. :P

You have trouble tracking your song, so you're programming it manually in ASM?
Do you know how backwards and awesome that is? lol

Now I'm curious to hear your song.

Jiggers

  • Sr. Member
  • ****
  • Posts: 405
    • View Profile
    • My Ko-Fi Page
Re: FF1 MMC5 Disassembly Updates
« Reply #623 on: July 10, 2020, 06:10:33 am »
Its a workflow thing. I've already had so much practice doing it this way, learning a new way would take longer. Its dumb!

This took me longer because I'm still half blind and a billion things can go wrong when you can't tell the difference between a B and a 6, but...

https://cdn.discordapp.com/attachments/689010633924280370/731088107465605130/MagicStorm_MIDI.mp3 -- original, for reference.

https://cdn.discordapp.com/attachments/689010633924280370/731082697363161128/MagicStormFF1-MMC5.mp3 -- full conversion

https://cdn.discordapp.com/attachments/300491322895368192/730878304076300409/MagicStormFF1.mp3 -- what you'd probably hear on a normal NES, since only the Famicom can actually handle the MMC5's extra audio channels apparently?

Its interesting how the song changed to fit the 5-track format. The new arpeggiated bassline... the new lead up melody to make the intro less boring... the MMC5's square channels trying their best to do electric guitar power chords, but somehow using the original's bassline as a rhythm instead... If I had DPCM, I'd use the old bassline, use the bass square as some kind of trilling chord-filler, or a deeper organ note. Not sure! But this is what I can do right now, so this is what I did.

Regular updates should resume someday soon!
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: 1752
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #624 on: July 12, 2020, 04:58:12 am »
Oh, wow! I like it!
I it would make a great dungeon theme. Maybe even for a final dungeon.
You sure you don't want to include it in this hack?

Rabite890

  • Jr. Member
  • **
  • Posts: 30
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #625 on: July 12, 2020, 02:57:20 pm »
Was wondering if it'd be possible to have a second class change event in the game or if it's limited to one time.

It would also be kind of neat to do things like in Seiken Densetsu 3 where you have branching paths for your class. Maybe a split from the Knight is Dark Knight or Paladin for example.
« Last Edit: July 12, 2020, 03:49:13 pm by Rabite890 »

Jiggers

  • Sr. Member
  • ****
  • Posts: 405
    • View Profile
    • My Ko-Fi Page
Re: FF1 MMC5 Disassembly Updates
« Reply #626 on: July 12, 2020, 04:28:34 pm »
Oh, wow! I like it!
I it would make a great dungeon theme. Maybe even for a final dungeon.
You sure you don't want to include it in this hack?

Thanks! But... not this one. The melody in the second half is actually the title screen melody for a game I've been wanting to make for... almost 8 years now. Been making the music for it for that long, so all the themes are intertwined at this point. But I probably have enough other songs to fill out a full conversion hack when all the features are done for this!

Was wondering if it'd be possible to have a second class change event in the game or if it's limited to one time.

It would also be kind of neat to do things like in Seiken Densetsu 3 where you have branching paths for your class. Maybe a split from the Knight is Dark Knight or Paladin for example.

It certainly is possible... Right now, the classes are limited to 16. So two ways to do it: One, limit starting classes to 4, the first class change to 4, then have the branching class paths for the other 8. (Or branch from the starting classes, then focus back into 4 UberClasses? Doesn't FF3 kind of do that with the Sage and Ninja? Its like, why pick any other class at this point? Just use these 2.)

The other way is to expand classes beyond the 16 limit.

First, character stats would need to be re-organized again to separate the class and byte sprites. There's a few battle-only stats that could be moved around to make this space.

Then, level up data needs to be in its own bank. I should do this anyway since I need to re-work how stats are calculated...

Map and battle graphics would need room, which is where the limitations might get tricky. I'd like to keep the battle graphics in the same bank with the magic and weapon sprites--I had to take out some other graphics already, to make room for 16 class sprites, but I don't know how much room is left.

There's 32 item IDs left for class names, so that's good. What might be rough is weapon and armor equipment permissions, spell permissions, and especially making room for unique skills and code for all those to work. But still lots of space for all that. Just organization and making it work. I haven't even finished the skills for the starting classes yet!

So I'll see how much of that I can support by moving data around to make room for it! This is the kind of thing I want to make easier for people who pick up the project when I'm done with it.
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.

Rabite890

  • Jr. Member
  • **
  • Posts: 30
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #627 on: July 12, 2020, 04:47:57 pm »
Thanks! But... not this one. The melody in the second half is actually the title screen melody for a game I've been wanting to make for... almost 8 years now. Been making the music for it for that long, so all the themes are intertwined at this point. But I probably have enough other songs to fill out a full conversion hack when all the features are done for this!

It certainly is possible... Right now, the classes are limited to 16. So two ways to do it: One, limit starting classes to 4, the first class change to 4, then have the branching class paths for the other 8. (Or branch from the starting classes, then focus back into 4 UberClasses? Doesn't FF3 kind of do that with the Sage and Ninja? Its like, why pick any other class at this point? Just use these 2.)

The other way is to expand classes beyond the 16 limit.

First, character stats would need to be re-organized again to separate the class and byte sprites. There's a few battle-only stats that could be moved around to make this space.

Then, level up data needs to be in its own bank. I should do this anyway since I need to re-work how stats are calculated...

Map and battle graphics would need room, which is where the limitations might get tricky. I'd like to keep the battle graphics in the same bank with the magic and weapon sprites--I had to take out some other graphics already, to make room for 16 class sprites, but I don't know how much room is left.

There's 32 item IDs left for class names, so that's good. What might be rough is weapon and armor equipment permissions, spell permissions, and especially making room for unique skills and code for all those to work. But still lots of space for all that. Just organization and making it work. I haven't even finished the skills for the starting classes yet!

So I'll see how much of that I can support by moving data around to make room for it! This is the kind of thing I want to make easier for people who pick up the project when I'm done with it.

That sounds like a lot of work. I was kind of afraid of that. And from the sounds of things, having equipment for each of the upper promoted classes would be difficult without moving data around in the ROM itself. Doesn't sound like that'd be worth it with how much customization it'd remove.

And yeah, FF3 is notorious for the railroading into Ninja/Sage at the end. There's some hacks of it that change the classes to actually have benefits over the Ninja/Sage, but vanilla FF3 basically means you're going to be using 2 Ninja and 2 Sages.

It was just a thought.

Jiggers

  • Sr. Member
  • ****
  • Posts: 405
    • View Profile
    • My Ko-Fi Page
Re: FF1 MMC5 Disassembly Updates
« Reply #628 on: July 12, 2020, 05:02:18 pm »
It's a good thought, though. A lot of the work has already been done for expansion in this way. I want to be able to add a second overworld eventually. Perhaps even raise the level cap. There's a lot more shops, weapons and armor are already expanded from 40 to 64, double the treasure chests possible to open, double the NPC dialogue. So I'll keep this in mind while I work on the level up data, and double check the possibilities with graphic data!

3,399 bytes free in the bank currently handling battle sprites. 512 bytes per class. That's 6 classes that can be squeezed in, for 22 total. Having each vanilla class branch twice from the adult classes would need 24. Branching from the base classes, we could squeeze in 7 base jobs and 14 adult classes. Removing the weapon and magic sprites to their own bank wouldn't be that much work, and allow for 8 more classes, for 30 total!

Hmm... FF5 remake on the NES?  :D
« Last Edit: July 12, 2020, 05:11:58 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.

Rabite890

  • Jr. Member
  • **
  • Posts: 30
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #629 on: July 12, 2020, 05:17:26 pm »
It's a good thought, though. A lot of the work has already been done for expansion in this way. I want to be able to add a second overworld eventually. Perhaps even raise the level cap. There's a lot more shops, weapons and armor are already expanded from 40 to 64, double the treasure chests possible to open, double the NPC dialogue. So I'll keep this in mind while I work on the level up data, and double check the possibilities with graphic data!

3,399 bytes free in the bank currently handling battle sprites. 512 bytes per class. That's 6 classes that can be squeezed in, for 22 total. Having each vanilla class branch twice from the adult classes would need 24. Branching from the base classes, we could squeeze in 7 base jobs and 14 adult classes. Removing the weapon and magic sprites to their own bank wouldn't be that much work, and allow for 8 more classes, for 30 total!

Hmm... FF5 remake on the NES?  :D

That could be interesting. 30 classes could give a lot of flexibility to either path. Or just giving a ton of options.

As long as you're still in the process of working on data for weapons/armor/magic/etc, have you seen Astral's newest work?

https://gamefaqs.gamespot.com/boards/522595-final-fantasy/78701259

She's been doing a ton of stuff that's amazing, including making equipment able to give bonuses that were exclusive to the GBA remake.

The amount of stuff you've changed/improved would make the FF1 Randomizer incredibly interesting.

A second overworld? Oooooo. Maybe we can even have unique stuff in the duplicate chests in Marsh Cave! You've got some great ideas here. Definitely one of the projects I'll be keeping an eye on.

Vanya

  • Hero Member
  • *****
  • Posts: 1752
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #630 on: July 15, 2020, 06:23:41 am »
Jiggers, are we using a system of equipment types yet?
I know that you converted the equipment system to use specific slots, but do the items have a type byte?
The later games associate classes with weapon types instead of specific lists.
That saves a ton of space and is easier for people to remember when selecting equipment.

I'm all for a future FFV demake using this project, and coincidentally I just posted in another thread about some day doing a FF1 remake in FF5's engine. lol :P

Anywho, expanding classes all the way out to a Trails of Mana style progression would be great indeed.
That would cover a lot of possible combinations of class advancement.
Might be worth it to make it as flexible as possible.
Taken to the extreme, you could allow everything from 16 base classes that each promote once all the way to 1 base class that can promote 31 times.

I wonder if Final Fantasy Tactics style classes would be reasonable to try?
But that would require keeping track of individual class levels.
Is there enough SRAM for something like that?

Jiggers

  • Sr. Member
  • ****
  • Posts: 405
    • View Profile
    • My Ko-Fi Page
Re: FF1 MMC5 Disassembly Updates
« Reply #631 on: July 15, 2020, 04:07:43 pm »
She's been doing a ton of stuff that's amazing, including making equipment able to give bonuses that were exclusive to the GBA remake.

The amount of stuff you've changed/improved would make the FF1 Randomizer incredibly interesting.

A second overworld? Oooooo. Maybe we can even have unique stuff in the duplicate chests in Marsh Cave! You've got some great ideas here. Definitely one of the projects I'll be keeping an eye on.

That's interesting... I wonder if she's doing it the way I have the Heal Helmet do regen--just straight up checking "is this specific helmet equipped?" during the Check-For-Regen-Status code... Or if its a change to the armour equipping code and every piece of armour can give a boost to a stat...

I dunno how the FF1 Randomizer does its thing, but they're going to have a hell of a time with this. XD I don't think I've left ANY piece of code or data in its original spot in ROM. And I feel like I need to re-organize one last time when I'm finished.

Duplicate chests are a map tile issue actually! A quick check in the map editor in Hackster shows 11 unused chests for the Marsh Cave/Mirage Tower tileset. I need to try to remember to label these chests when working on the maps once I can import them into Tiled.

And hopefully figure out how to double the available tilesets, too. I tried once and broke everything, but maybe next time I'll understand how they're being loaded better.

Jiggers, are we using a system of equipment types yet?
I know that you converted the equipment system to use specific slots, but do the items have a type byte?
The later games associate classes with weapon types instead of specific lists.
That saves a ton of space and is easier for people to remember when selecting equipment.

Hm. You mean like... Plate Armour/Chain Armour/Leather Armor/Robes? And then just using that byte as the "class can equip" check? So that a thief can equip ANY piece of Leather Armor?

The current system is... more flexible, I think. Like the White/Black robes, or the Katana. If the Katana's weapon type was "dagger", then the black mage could wield it too...

What I absolutely should do is consolidate all the data into the same table, though. Instead of having an Equip Slot Table, a Class Equip Permissions table, and the equipment data itself all separate. Then every time a piece of equipment is checked, it only has to load from ONE spot--and put it in RAM, and test it against the currently worn piece.

Quote
Is there enough SRAM for something like that?

Oh boy. This is just me thinking out loud here...

I absolutely need to consolidate SRAM. Each of the menu options does NOT need a whole byte.

ExpGainOption    = 2 bits
MoneyGainOption  = 2 bits
EncRateOption    = 2 bits
MuteSFXOption    = 1 bit
AutoTargetOption = 1 bit
BattleTextSpeed  = 4 bits
BattleBGColor    = 4 bits

2 bytes? That makes room for the PlayTimer (4 byte) going into the unused slots (3 bytes)

Canal, Ship, Airship, Bridge visibility toggles = 1 bit each. Save 3 more bytes. BridgeScene only needs 2 bits. That leaves 2 more bits for new overworld vehicles (whatever people want to make.) And the extra room can be used for X/Y coordinates for those vehicles?

Key items, likewise, don't need bytes. You either have them, or you don't. 1 bit. Currently have 32 key item slots, that can be 4 bytes.

All the option data and consumable items currently takes up #48 ($30) bytes. #64 ($40) bytes is a quarter of a 256 byte block of RAM. Weapons, Armor, and Magic each take up $40. They don't need to, either. I'm pretty sure with some tricky math and some data tables or something, they can be $20 bytes each. Since the limit for each piece of equipment is 16, that's only 4 bits each.

Which more than makes room for $100 bytes of Class junk, $40 per character. $18 of which can be decompressed spell data, which would allow more than 64 spells in the game and also allow players to move the spells around in the character's inventory.

Phew.

Picked a hell of a day to start drinking caffeine again.
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.

Rabite890

  • Jr. Member
  • **
  • Posts: 30
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #632 on: July 15, 2020, 09:25:12 pm »
That's interesting... I wonder if she's doing it the way I have the Heal Helmet do regen--just straight up checking "is this specific helmet equipped?" during the Check-For-Regen-Status code... Or if its a change to the armour equipping code and every piece of armour can give a boost to a stat...

I dunno how the FF1 Randomizer does its thing, but they're going to have a hell of a time with this. XD I don't think I've left ANY piece of code or data in its original spot in ROM. And I feel like I need to re-organize one last time when I'm finished.

Duplicate chests are a map tile issue actually! A quick check in the map editor in Hackster shows 11 unused chests for the Marsh Cave/Mirage Tower tileset. I need to try to remember to label these chests when working on the maps once I can import them into Tiled.

And hopefully figure out how to double the available tilesets, too. I tried once and broke everything, but maybe next time I'll understand how they're being loaded better.

Hm. You mean like... Plate Armour/Chain Armour/Leather Armor/Robes? And then just using that byte as the "class can equip" check? So that a thief can equip ANY piece of Leather Armor?

The current system is... more flexible, I think. Like the White/Black robes, or the Katana. If the Katana's weapon type was "dagger", then the black mage could wield it too...

What I absolutely should do is consolidate all the data into the same table, though. Instead of having an Equip Slot Table, a Class Equip Permissions table, and the equipment data itself all separate. Then every time a piece of equipment is checked, it only has to load from ONE spot--and put it in RAM, and test it against the currently worn piece.

Oh boy. This is just me thinking out loud here...

I absolutely need to consolidate SRAM. Each of the menu options does NOT need a whole byte.

ExpGainOption    = 2 bits
MoneyGainOption  = 2 bits
EncRateOption    = 2 bits
MuteSFXOption    = 1 bit
AutoTargetOption = 1 bit
BattleTextSpeed  = 4 bits
BattleBGColor    = 4 bits

2 bytes? That makes room for the PlayTimer (4 byte) going into the unused slots (3 bytes)

Canal, Ship, Airship, Bridge visibility toggles = 1 bit each. Save 3 more bytes. BridgeScene only needs 2 bits. That leaves 2 more bits for new overworld vehicles (whatever people want to make.) And the extra room can be used for X/Y coordinates for those vehicles?

Key items, likewise, don't need bytes. You either have them, or you don't. 1 bit. Currently have 32 key item slots, that can be 4 bytes.

All the option data and consumable items currently takes up #48 ($30) bytes. #64 ($40) bytes is a quarter of a 256 byte block of RAM. Weapons, Armor, and Magic each take up $40. They don't need to, either. I'm pretty sure with some tricky math and some data tables or something, they can be $20 bytes each. Since the limit for each piece of equipment is 16, that's only 4 bits each.

Which more than makes room for $100 bytes of Class junk, $40 per character. $18 of which can be decompressed spell data, which would allow more than 64 spells in the game and also allow players to move the spells around in the character's inventory.

Phew.

Picked a hell of a day to start drinking caffeine again.

Looks like I picked the wrong week to stop sniffing glue...

I'm not sure how she managed to do the things she's done. I don't think most of it should be possible, but there it is.

You're pretty close to how a randomizer works. Everything is supposed to be in a known location, so it can be moved around. I think they'd have to replace so much it'd be a nightmare for them. I would like to see some of the features from the randomizer thrown in. Hell even a randomizer program added to the package this comes in. But again, that's a ton of work.

The duplicate chests get me every time I play, no matter which version it is.

Vanya

  • Hero Member
  • *****
  • Posts: 1752
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #633 on: July 16, 2020, 10:47:27 am »
Having a randomizer added in might not be a bad idea after everything else is done.

Jiggers, if I'm not mistaken, it would just be a matter of making an alternative batch file to compile the ROM, no? All that would be need is to have it shuffle around some data? At least for a basic randomizer that doesn't make random maps?

Cyneprepou4uk

  • Sr. Member
  • ****
  • Posts: 474
  • I am the baldest romhacker
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #634 on: July 16, 2020, 11:03:35 am »
One way to go with randomizer is label values you want to be random, then launch an additional script which will replace values in those labels by making a copy of that file and compiling it.

So, yeah, it's just a matter of having an alternative batch file, where you include running your prepared randomizer  >:D
iromhacker.ru - NES ROM hacking tutorials for beginners. Please use Google Translate browser extension

Jiggers

  • Sr. Member
  • ****
  • Posts: 405
    • View Profile
    • My Ko-Fi Page
Re: FF1 MMC5 Disassembly Updates
« Reply #635 on: July 16, 2020, 07:16:44 pm »
*Big ol' shrug*

Since I only know ASM, not how all the scripting stuff works, I have really no idea how to randomize anything. Its interesting to talk about, but I can't really talk about it!  :P

I'm neck-deep in SRAM optimization right now. Actually RIGHT NOW I'm optimizing dialogue logic...

I have Overworld flags set for vehicles and bridge scene stuff. Options condensed down to 3 bytes (battle background colour and text speed were easiest to leave alone.) Key items are 4 bytes, not counting orbs--it was much easier to just let the orbs be their own 4 bytes, so far. Quest Item page in inventory works. Bottle purchasing from the Caravan should work.

There's now 8 unused bytes, sort of scattered around. 2 unused items, 6 bytes between the compressed key items and the orbs. 1 bit left in the overworld flags, so that could be another vehicle, 2 bytes for X and Y coordinates, then 4 more orbs for the second overworld. Or some arranging and they could be used for things like extra bridges and canals--but that would require a second overworld flag byte... I guess smokebomb_steps doesn't need to be in save ram, but I thought--it would suck to save in the middle of using one and have its effect wear off on reloading.

Reminding myself to check the map tile properties jump table... 

For the dialogue, I'm adding an extra byte to the logic table, and stripping a second jump table down to $27 entries instead of $D0. Saves some 170 or so bytes that way, plus makes adding more NPCs or editing them easier.



So the limit for unique battle sprites is 30. Could cram 32 in there, but at the cost of filling the fixed bank up with fancy sprite loading code. And I'm trying to keep the fixed bank extra empty for DPCM samples. I'm not doing well, since I was at nearly 900 free bytes and now its 600 or so. Turns out saving SRAM space has a cost! And I even moved a lot of shop and battle background palette+CHR loading to another bank.

Fixed the issue where map music wasn't playing after exiting the minimap, and also made it so long notes will re-start if they were cut off. Also my Magic Storm song is in there for a while, but I'm gonna take it out at some point.



And finally, a ton of data management... Back to over 1000 free bytes in Bank F! More to come when I get around to seeing where there's room for 30 freakin' map sprites!! And all the making sure the game runs and stuff. Really paired down my super, super old, clumsy, ugly, frustrating maze of bank switching and PLA PLA RTS nonsense that the title screen and its undo functions had. 4 AM isn't the time to test that it all works though.
« Last Edit: July 17, 2020, 03:56: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: 1752
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #636 on: July 17, 2020, 12:32:31 pm »
Go, girl! You're practically blazing through this stuff.

I had a thought that I may or may not have mentioned before.
Would it be viable to have more tiles for each battle sprite?

I'm wondering if we could do some sprite layering for some enhanced graphics shenanigans.
Since we're limited to 3 palettes, being able to mix those together would be a great option for artists.

Sprite count and flicker could be an issue on real hardware if not put together carefully, but that's an end-user problem.

Jiggers

  • Sr. Member
  • ****
  • Posts: 405
    • View Profile
    • My Ko-Fi Page
Re: FF1 MMC5 Disassembly Updates
« Reply #637 on: July 17, 2020, 03:03:40 pm »
So much stuff doesn't work right now, its amazing the game runs at all. xD Currently trying to organize some more graphics loading routines. Last year when I was trying to work out the order of events the original game goes through, I felt like it was somehow loading menu graphics twice... or palettes twice... Maybe I'm making it more of a spiderweb, but my aim is to not be spending so much time loading things that are already loaded. Title screen so far only needs to reload the Bridge Scene nametable after exiting the options/new game menu, which should make switching screens not interrupt the music so much. If I can get that going for every menu change... woooeee!



In terms of loading sprites in battle? Yeah. That's 5 rows unused at the moment, once the / is moved somewhere else.

I just freed up 4k bytes in Bank B, and if I move level up data somewhere else, that's going to make a WHOLE lot of room for extra battle logic and display routines, since that bank is so closely tied with the main battle loop already. Then there's still half a bank of data--magic and enemy AI stuff mostly... not to mention how much more graphic data will be freed up by making the enemy loading routine more flexible. So space for extra graphics, check. Space for sprite drawing code, check. Space for sprites actually loaded, check. And if the cursor/weapon isn't showing you can use all 4 palettes for whatever.

Use the Fade Out Sprites routine to clear the party. Change the palettes to something crazy. Load in a sprite as large as an ogre, swoop it in. Change the palette for the damage cloud if needed, do the messaging and all that. Fade the sprites out again, or before the damage cloud to avoid flicker issues. Reset the palettes. Fade in the party. Boom, you got a summon going on!

If I'm not mistaken... Removing the bottom line or two from the backdrop graphics and using the stack to hold some palette change bytes, you could also add a 3rd enemy color. The issues I have with it is getting the scroll right (still no idea what values I need to use for any given line where a color change happens), and the limited amount of time to write the palette.
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.

Cyneprepou4uk

  • Sr. Member
  • ****
  • Posts: 474
  • I am the baldest romhacker
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #638 on: July 17, 2020, 10:12:22 pm »
I noticed you have 3 CMP #$00 + the same branch as above in bank 0F.

Code: [Select]
SoundTestSelect:
    LDA joy           ; get joypad data
    AND #$0C          ;  isolate up/down buttons
    CMP joy_prevdir   ;  compare it to previously checked button states
    BEQ @Exit         ; if they equal, do nothing (button has already been pressed and is currently just held)

    STA joy_prevdir   ; otherwise, button state has changed, so record new button state in prevdir
    CMP #$00          ;  and check to see if a button is being pressed or released (nonzero=pressed)
    BEQ @Exit         ;  if zero, button is being released, so do nothing and just exit

    CMP #$04          ; see if the user pressed down or up
    BNE @Up

BEQ and STA don't affect Z flag, so it is a waste.
iromhacker.ru - NES ROM hacking tutorials for beginners. Please use Google Translate browser extension

Lenophis

  • IRC Staff
  • Hero Member
  • *****
  • Posts: 968
  • The return of the sombrero!
    • View Profile
    • Slick Productions
Re: FF1 MMC5 Disassembly Updates
« Reply #639 on: July 18, 2020, 12:01:31 am »
I'm not sure I see the optimization issue you're referring to.

Code: [Select]
SoundTestSelect:
    LDA joy           ; get joypad data
    AND #$0C          ;  isolate up/down buttons
    CMP joy_prevdir   ;  compare it to previously checked button states
    BEQ @Exit         ; if they equal, do nothing (button has already been pressed and is currently just held)

    STA joy_prevdir   ; otherwise, button state has changed, so record new button state in prevdir
    CMP #$00          ;  and check to see if a button is being pressed or released (nonzero=pressed)
This CMP specifically checks for zero against M (which is isolated with the up/down bits) to see if neither button is being pressed.

Code: [Select]
    BEQ @Exit         ;  if zero, button is being released, so do nothing and just exitAnd exits if so.

Code: [Select]
    CMP #$04          ; see if the user pressed down or up
    BNE @Up

While it's true branches and stores do not affect the N and Z flags, three other instructions in this code snippit do: LDA, CMP, and AND.


https://ff6randomizer.codeplex.com/ - Randomize your FF6 experience!