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

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

Jiggers

  • Full Member
  • ***
  • Posts: 248
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #360 on: June 29, 2019, 07:21:37 pm »
No worries.

All this time I thought something was wonky with the dialogue after string # $FD ... it just turns out that the strings themselves were not labeled or organized properly.

Edit: This also accounts for why the orb sprite is the thief...  :banghead: I don't know how this happened. About to fix it though.

Support for twice the dialogue strings is underway! Not super useful until I can figure out how to make twice the NPCs... but its there. Perhaps I will fiddle with it so that instead of needing 256 new NPCs, its just a toggle thing to make NPCs string boxes of dialogue together...



Going through tileset data... for reference:

Code: [Select]
;; $8800 ;;
;; Map tile data, 0x100 bytes per tileset
; 2 bytes per tile:
;  +0: bits 5-7: 000..... ; 0-1x     = normal
;                001..... ; 2-3x     = battle! Battle in $6a, BG in $53
;                010..... ; 4-5x     = WARP!
;                011..... ; 6-7x     = Warp without transition
;                100..... ; 8-9x     = Map-to-map teleport (+1 is target)
;                101..... ; A-Bx     = Warp without transition
;                110..... ; C-Dx     = Map-to-world teleport (+1 is target)
;                111..... ; E-Fx     = Warp without transition
;      bits 0-4: ...00000 ; 00       = No battle here
;                ...00001 ; 01       = Can't step here
;                ...0001x ; 03 - 02  = Door; +1 is shop number or 0 for regular door
;                ...0010x ; 05 - 04  = Need KEY
;                ...0011x ; 07 - 06  = Exit room by stepping here (?)
;                ...0100x ; 09 - 08  = Treasure chest (contents specified by +1)
;                ...0101x ; 0B - 0A  = Spiked square if +1 bit 7 clear, otherwise normal battle
;                ...0110x ; 0D - 0C  = Damage square
;                ...0111x ; 0F - 0E  = Need CROWN to step here
;                ...1000x ; 11 - 10  = Need CUBE to step here
;                ...1001x ; 13 - 12  = Need all ORBS to step here
;                ...1010x ; 15 - 14  = Use ROD
;                ...1011x ; 17 - 16  = Use LUTE
;                ...1100x ; 19 - 18  = Give Earth orb
;                ...1101x ; 1B - 1A  = Give Fire orb
;                ...1110x ; 1D - 1C  = Give Water orb
;                ...1111x ; 1F - 1E  = Give Wind orb
;          Also: bit 0: set if sprites cannot step here
;          Also: bit 1: If set, no message when pressing A at this square
;  +1: index for whatever is specified in byte 0

Checking the actual data, it seems like none of the first bytes actually start with A, B, E, or F. Only $6 is used for "warp without transition"

So this is a good start, maybe! If they're not used, I can try to use them to double treasure chests??

I still need to do more digging... I want to try and change some of these. The altars are bugged because of that bit 1 being set for Fire and Wind orbs. I will find another way to put the orbs into inventory upon defeating the Fiends.

What tile properties would be useful? A safe-tile in dungeons that allows the use of tents and saving, surely? HP/MP springs?

Update: I understand a little more, but less certain I can change as much as I thought. For now, the Give Earth Orb tile property ($18) should be working for all altars. It decides which orb to do based on what map you're on. The map IDs are set in Constants.inc
« Last Edit: July 01, 2019, 02:10:30 am by Jiggers »
I know exactly what I'm doing. I just don't know what effect it's going to have.

Vanya

  • Hero Member
  • *****
  • Posts: 1489
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #361 on: July 01, 2019, 01:32:45 am »
What tile properties would be useful? A safe-tile in dungeons that allows the use of tents and saving, surely? HP/MP springs?

Absolutely, yes to all three.
Maybe also one that allows the sprites to appear "behind" the tile if that is at all possible.
Would be very useful for doing secret passages and pillars and high walls and proper beds.
Let's see...
We already have damage tiles... (Can these be used on the overworld?)
How about a slippery ice property for ice tiles?
Can the forest tile property be used in town/dungeons?
If not, that would be great to have.

And while you're poking around tile properties, could you look at maybe making treasure chest tiles use an open graphic after the contents have been taken?

Jiggers

  • Full Member
  • ***
  • Posts: 248
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #362 on: July 01, 2019, 03:56:55 pm »
I am hoping now that I can just re-write all the tile properties. Instead of having masks to combine different things, it would just be a mask for "Can walk here" and "No special dialogue", and everything else is just its own special control code thing. That leaves 64 possible tile properties with the remaining 6 bits... So long as I can re-work the way the game reads it. 32 if I use a third bit for a mask like "sprite goes behind here"? Right now there's like... 20 tile properties. So that should be enough too.

By the way--no go on having FF6 shaped map sprites. I wanted to basically have the battle sprites be the "facing sideways" map sprites, but that would require washing them out by 1 colour so they match. I realized this ages ago, but it just comes to mind now...

Or else it would require having every floor be black, but I actually get super uncomfortable with NES games that leave the background black if the rest of the environment/level doesn't match. Stupid Menace Beach... Someone should make a Creepy Pasta about that...


Right now I'm going through each tile-set and marking what each tile does. This will take a few hours.

Slippery ice will require adding something to movement code, so not sure about that... yet...

Really want to make secret passage tiles, so that's a priority for me. XD

And, sure--I think I might know how to change treasure chest tiles when they're opened. There's 6 quarter-tiles of Japanese text in each tileset, too, so there's room for 1 more unique tile and a treasure chest top. And I'm pretty sure there's unused tiles in a bunch of them. Like, what the heck is this:



I feel like I've seen it before--does it flank the orb altars and the game somehow flips it around to have two of them?

Anyway, if anyone's willing to draw a treasure chest top for the normal chests and sky palace chests... please do!
I know exactly what I'm doing. I just don't know what effect it's going to have.

Vanya

  • Hero Member
  • *****
  • Posts: 1489
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #363 on: July 01, 2019, 07:39:44 pm »
1) Reworking tile properties sounds like a great idea.
2) I think 32 tile properties is good enough.
3) I can't recall what that graphic is for, however the game has very few unused graphics at all.
See here ---> https://tcrf.net/Final_Fantasy#Unused_Graphics
4) I can get you treasure chest graphics in a jiffy...



Here...

https://1drv.ms/u/s!Aioy8p_nvLQ6iBkvppsz37Bce07m?e=Z7hZaS

https://1drv.ms/u/s!Aioy8p_nvLQ6iBibcUgeh9OoKvbf?e=4FEDXV
« Last Edit: July 02, 2019, 04:20:25 pm by Vanya »

Jiggers

  • Full Member
  • ***
  • Posts: 248
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #364 on: July 02, 2019, 12:15:48 am »
Oop; 404 errors on those.

I'm trying to think of how to do this now. So this is my rubber ducky post.

Loading a new map. After initial map tiles have been loaded into tileset_data.
First, check game_flags for open chests. Get cur_map, run the chest ID through the second byte of that map's lut_SMTilesetProp table. If it matches: Check the first byte to make sure its a chest? No: Check for chests, then check the second byte to make sure its the right ID? Sounds better. Once found... Take the counter then--out of 128 tiles, say it finds an open chest at tile 99, so 99 is the index or ID... (I get the two terms confused sometimes... all the time.)

Then, check at tileset_data+$100 for the upper left tile in slot 99. It should be 2A. ORA with $70 or whatever, change it to 7A (currently the / tile in each tileset). Shift over, 2B becomes 7B. And done! When the screen draws the map based on that, it should show the open chest...?

Now, when first opening:
LDA facing               ; use the direction the player is facing
JSR GetSMTargetCoords    ;  as the direction to get SM target coords
JSR GetSMTileProperties  ; get the properties of the tile at the given coords
Y = chest index/id now, so just do the upper tile swapping.
What next? Will the game automatically draw it, or does have to re-enter the map? Guess we'll see...

Hopefully that will work when I go to actually code it in.

Meanwhile: I changed the tile properties, and towns are working OK so far. Got a spook in Onrac where everyone was saying "Nothing here." but it might have been a wonky save state load, I'll go back and check and make sure the submarine works. Every other map is bonkers nuts, teleporting when you walk into a wall.  :D I only got 2 more of the original map's tileset data sorted out, 5 to go, and then changing almost every byte to fit my new system...
I know exactly what I'm doing. I just don't know what effect it's going to have.

Vanya

  • Hero Member
  • *****
  • Posts: 1489
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #365 on: July 02, 2019, 09:19:46 am »
Bloody hell. Ok.
I'll  post them again tonight when I get back from work.



OK. check the links and see if you can download them.
« Last Edit: July 02, 2019, 04:20:57 pm by Vanya »

Jiggers

  • Full Member
  • ***
  • Posts: 248
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #366 on: July 02, 2019, 05:08:25 pm »
Thanks!

I just had a wee bit of trouble making out the pixel colours because the bmp format blends things together... so how does it look?


Messed up on having the white too bright there, it should be a paler colour of brown... Also I took out the brown dots inside that I had put in. They look weird.


For this one, wasn't really sure if the slid-back top looked right (it would be a lot better if the sprite could be 2-3 pixels wider for sure), so I just slightly altered the other kind. It looks too round to me, I don't know how to get that straight-edge look... Again, I think 'cos it needs just another pixel on the right side.



When using the Black Orb teleport, or the Cube or Crown teleports, have you ever noticed it playing the fanfare? Apparently its supposed to do that when you walk onto the tile, but then the teleport happens and the song gets cut off, I think, because I have no memory of this.

Since I have to make special-item teleports behave differently, I might try to have the teleport wait until the song is over. Or should I just remove the song from playing? One of these options will take way less space in the fixed bank.

Eh, special item teleports work with a simple LDA/STA so I don't really want to add in a bunch of other stuff to make them work different after all. So, cutting the song out. Surprised this wasn't considered a bug before though...

So that's doors, special-item-required teleports, and battle squares working again! Still need to check damage squares, treasures, locked doors, and the ROD/LUTE use tiles (which now should be able to handle any key item!)



BIG UPDATE!

Bank 12 now has a bunch of stuff that was in Bank 11 (previously Bank 0!) This now has teleport coordinates and battle background stuff and whatnot.

Bank 11 is primed to be filled with more map tileset data maybe??? Also all the tile properties have been re-done for standard maps. FFHackster was instrumental in making sure I knew what each tile did. I took the huge chunks of data and made them into lists, and hopefully my way of doing tile properties means its easier to edit too.

« Last Edit: July 02, 2019, 09:14:23 pm by Jiggers »
I know exactly what I'm doing. I just don't know what effect it's going to have.

Vanya

  • Hero Member
  • *****
  • Posts: 1489
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #367 on: July 02, 2019, 08:59:07 pm »
They look fine to me.
I'm kinda just considering them to be placeholders anyway.
And also, anything is better than nothing.



Cool stuff.
Never noticed a fanfare issue on those teleports.

Jiggers

  • Full Member
  • ***
  • Posts: 248
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #368 on: July 03, 2019, 12:28:16 am »
Some testing issues... I made a roof tile into a treasure chest For Reasons. (By the way--I doubled the treasure tables. Pretty sure that's working properly! Not sure if its updated into the latest master.) I set it to treasure $20, 1020 g. But I got way more gold than that after opening it. So again... keep an eye out for treasure being wonky like that. I figure the bug should be in LoadPrice and AddGPtoParty but I didn't change those in months...

Now what I did was when GetSMTileProperties uses Y, I backup after the RTS...

Code: [Select]
GetSMTileProperties:
    LDA tmp+5          ; take the Y coord
    LSR A              ; right shift by 2 to get the high byte of *64
    LSR A
    ORA #>mapdata      ; OR with high byte of map data pointer
    STA tmp+1          ; this is high byte of pointer to tile in the map

    LDA tmp+5          ; get Y coord again
    ROR A
    ROR A
    ROR A
    AND #$C0           ; *64 (low byte this time)
    ORA tmp+4          ; OR with X coord
    STA tmp            ; this is low byte of pointer

    LDY #0                ; zero Y for indexing
    LDA (tmp), Y          ; get the tile from the map
    ASL A                 ;  *2 (2 bytes per tile)
    TAY                   ; throw in Y for indexing

    LDA tileset_data, Y   ; copy the two bytes of tile properties
    STA tileprop
    LDA tileset_data+1, Y
    STA tileprop+1

    RTS                   ;then exit!

...a ways after the RTS...

Code: [Select]
TalkToSMTile:
    JSR GetSMTileProperties   ; get the properties of the tile at the given coords

    LDA tileprop              ; get 1st property byte
    AND #TP_SPEC_MASK         ;  see if its special bits indicate it's a treasure chest
    CMP #TP_SPEC_TREASURE
    BEQ @TreasureChest        ; if it is, jump ahead to TC routine
    CMP #TP_SPEC_TREASURE_2
    BEQ @TreasureChest2       ; if it is, jump ahead to TC routine
   
    LDA tileprop              ; otherwise, reload property byte
    AND #TP_HASTEXT_MASK      ; see if the HASTEXT bit is set
    BEQ @Nothing              ; if not... force "Nothing Here" text

    LDA tileprop+1            ; otherwise, simply use the 2nd property byte as the dialogue
    RTS                       ;  tied to this tile, and exit

  @Nothing:                   ; if forced "Nothing Here" text...
    ;LDA #DLGID_NOTHING
    ; A will be 0 here
    RTS

  @TreasureChest:             ; if the tile is a treasure chest
    LDX tileprop+1            ; put the chest ID in X
    LDA game_flags, X         ; get the game flag associated with that chest
    AND #GMFLG_TCOPEN         ;   to see if the chest has already been opened
    JMP :+                   

  @TreasureChest2:            ; if the tile is a treasure chest
    LDX tileprop+1            ; put the chest ID in X
    LDA game_flags, X         ; get the game flag associated with that chest
    AND #GMFLG_TCOPEN_2       ;   to see if the chest has already been opened
:   BEQ :+                    ; if it has....
      LDA #DLGID_EMPTYTC      ; select "The Chest is empty" text, and exit
      RTS
     
:   JMP OpenTreasureChest     ; otherwise, open the chest

Y isn't changed at all there... So then it gets to OpenTreasureChest.

Code: [Select]
OpenTreasureChest:
    TYA
    PHA                      ; save Y

    LDA #BANK_TREASURE       ; swap to bank containing treasure chest info
    JSR SwapPRG_L

    LDX tileprop
    LDA tileprop+1           ; double chest index and put in X
    CPX #TP_SPEC_TREASURE_2
    BEQ @ChestTable_2        ; check the first tile property to see if the chest is treasure table 1 or 2
   
   @ChestTable_1:
    ASL A
    TAX
    BCC :+
   
    LDA lut_Treasure+$101, X ; if treasure chest is over $7F, check the second half of the LUT
    STA dlg_itemid
    LDA lut_Treasure+$100, X
    STA treasure_offset
    JMP @CheckTreasure
   
  : LDA lut_Treasure+1, X    ; use it to get the contents of the chest
    STA dlg_itemid           ; record that as the item id so it can be printed in the dialogue box
    LDA lut_Treasure, X
    STA treasure_offset
    JMP @CheckTreasure
   
   @ChestTable_2:
    ASL A
    TAX
    BCC :+
   
    LDA lut_Treasure_2+$101, X ; if treasure chest is over $7F, check the second half of the LUT
    STA dlg_itemid
    LDA lut_Treasure_2+$100, X
    STA treasure_offset
    JMP @CheckTreasure
   
  : LDA lut_Treasure_2+1, X    ; use it to get the contents of the chest
    STA dlg_itemid           ; record that as the item id so it can be printed in the dialogue box
    LDA lut_Treasure_2, X
    STA treasure_offset
 
   @CheckTreasure:
    BEQ @Gold                ; if 0, its gold

    CMP #1                   
    BEQ @Item                ; if 1, its a consumable, key item, or magic spell

    ;; Otherwise, its equipment!
   
    LDX dlg_itemid
    LDA inv_weapon, X
    CMP #99
    BCS @TooFull
        INC inv_weapon, X    ; says inv_weapon, but armor IDs are +$40 so it works
        INC dlg_itemid
        JMP @OpenChest
   
   @Gold:
    LDA dlg_itemid
    JSR LoadPrice            ; get the price of the item (the amount of gold in the chest)
    JSR AddGPToParty         ; add that price to the party's GP
    JMP @OpenChest           ; then mark the chest as open, and exit
   
   @Item:
    LDA dlg_itemid
    CMP #ITEM_MAGICSTART     ; if its a magic thing...
    BCS @Magic
   
    CMP #ITEM_KEYITEMSTART   ; if its a key item
    BCS @KeyItem
   
    ;; otherwise, its a normal item
   
    TAX                      ; put item ID in X
    LDA items, X             ; see how many of this item the player has
    CMP #99                  ; see if they have >= 99
    BCS @TooFull
      INC items, X           ; give them one of this item -- but only if they have < 99
      JMP @OpenChest
   
   @Magic:
    SEC
    SBC #ITEM_MAGICSTART     ; subtract magic offset to conver to spell ID
    TAX
    ;LDA inv_magic, X         ; check how many of that spell is stored
    ;CMP #4                   ; no reason to have more than 4
    ;BCS @TooFull            ;; JIGS - why not, you can sell 'em now
       INC inv_magic, X      ;; and something else is wrong if you're pulling over 99 from chests
       JMP @OpenChest
   
   @KeyItem:
    TAX
    INC items, X
    INC dlgsfx               ; turn on key-item jingle
     
   @OpenChest:
    LDX tileprop
    CPX #TP_SPEC_TREASURE_2
    BEQ @FlagChest_2
   
   @FlagChest_1:
    LDX tileprop+1           ; re-get the chest index
    LDA game_flags, X        ; set the game flag for this chest to mark it as opened
    ORA #GMFLG_TCOPEN        ;
    JMP :+
   
   @FlagChest_2:
    LDX tileprop+1           ; re-get the chest index
    LDA game_flags, X        ; set the game flag for this chest to mark it as opened
    ORA #GMFLG_TCOPEN_2
   
  : STA game_flags, X        ;
    PLA
    TAY
    LDA tileset_data+$100, Y
    ORA #TP_TREASURE_OPEN
    STA tileset_data+$100, Y
    LDA tileset_data+$180, Y
    ORA #TP_TREASURE_OPEN
    STA tileset_data+$180, Y
   
    LDA #DLGID_TCGET         ; put the treasure chest dialogue ID in A before exiting!
    RTS

  @TooFull:                  ; If too full...
    PLA
    LDA #DLGID_CANTCARRY     ; select "You can't carry any more" text
    RTS

From what I was trying to figure out, the roof tile I edited was $17th in the town's lut_SMTilesetProp table.

The $17th upper left tile in the town's lut_SMTilesetTSA table is $03...

Yet, in my test, Y ended up being $2E, which grabbed $40 from the table.

All this is to say... I still don't really know what I'm doing.

Edit: OH, Y got shifted. $17 * 2 = $2E ...  :-[ Okay, back on track.





AND IT WORKS.

For loading the map anyway!!! For original game chests!!! Tomorrow I will add in Treasure Chest 2 support and try to make opening a new chest update without re-loading the map!!! AAAAAAAAAAH
« Last Edit: July 03, 2019, 03:46:32 am by Jiggers »
I know exactly what I'm doing. I just don't know what effect it's going to have.

Vanya

  • Hero Member
  • *****
  • Posts: 1489
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #369 on: July 03, 2019, 02:06:11 pm »
Awesome work!!
With all that extra space for tiles, things could get much more interesting.
Speaking of FFHackster, I can't imagine it can still be used to edit the MMC5 ROM built from this disassembly, right?

Jiggers

  • Full Member
  • ***
  • Posts: 248
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #370 on: July 03, 2019, 02:31:58 pm »
Goodness me, no. The map editor might still work, you'd just have to copy-paste the map data from a working ROM to the MMC5 ASM file... then probably place NPCs by hand and all that. That's what I plan on doing if I can't get someone to build a new map editor...

Some more tile ideas: Pressure plates, chests-with-rocks-in-them like FF5... Now that I know how to use game_flags, there's still... 768 possible on/off switches to be used. 1024 if I can't get new NPCs to work. And more since the game only uses a handful of the event flags.

Next I want to learn how to edit maps directly, to make walls move out of the way. I still need to code in healing springs and all that stuff, too! Gonna be busy!

If anyone wants to see if this code can be shortened:

Code: [Select]
    JSR LoadSMCHR           ; load all the necessary CHR
    JSR LoadSMTilesetData   ; load tileset and TSA data

    ;; JIGS - here, it checks all the tile properties of the map's tileset to see if there's a chest
    ;; When it finds a chest, it checks to see if its open
    ;; If its open, it swaps the upper tiles to use the opened chest graphic
   
    LDY #0                  ; set Y to 0 to use as loop counter and index
    STY tmp                 ; Set tmp to 0 
    LDA cur_tileset         ; Load current map's tileset
    CLC
    ADC #>lut_SMTilesetProp ; and set high byte to the tileset properties table
    STA tmp+1
   
   @CheckTreasureLoop1:   
    LDA (tmp), Y            ; Load a byte of the tileset properties table
    CMP #TP_SPEC_TREASURE   ; if it matches a chest
    BEQ @IsChestOpen        ; check if the chest is open!
    CMP #TP_SPEC_TREASURE_2 ; and again for chest type #2
    BEQ @IsChestOpen
   
   @IncY2:   
    INY                     ; if not, increase Y by 2 (each tile is 2 bytes)
   @IncY1:
    INY
    BNE @CheckTreasureLoop1 ; if Y hasn't wrapped, keep checking for more chests
    JMP @ContinueLoad       ; after all 256 bytes (128 tiles) are checked, resume loading the map like the original game
   
   @IsChestOpen:
    PHA                    ; backup the chest type
    INY                    ; inc Y to check the second byte of the tileset properties table
    LDA (tmp), Y           
    TAX                    ; put that in X
    PLA                    ; restore the chest byte into A
    LSR A                  ; Chest table 1 is 9 (1001) and Chest table 2 is A (1010)
    BCS @ChestTable1       ; so figure out if its 1 or 2 by checking carry after shifting
   
   @ChestTable2:
    LDA game_flags, X      ; with X as the chest index, check game_flags to see if its set open
    AND #GMFLG_TCOPEN_2     
    BEQ @IncY1             ; if its not, go back up to the main loop, but only inc Y by 1 more
    BNE :+                 ; if it is, skip ahead
   
   @ChestTable1:   
    LDA game_flags, X      ; same, but check a different open bit flag!
    AND #GMFLG_TCOPEN
    BEQ @IncY1
   
  : DEY                      ; decrement Y back to the previous byte of the table
    TYA                      ; put in A
    LSR A                    ; and halve it
    TAX                      ; then put it into X
    LDA tileset_data+$100, X ; Load up the upper left tile of the chest
    ORA #TP_TREASURE_OPEN    ; ORA with #$70 to change it to the open chest tile
    STA tileset_data+$100, X ; and save it
    LDA tileset_data+$180, X ; Do the same with the upper right tile
    ORA #TP_TREASURE_OPEN
    STA tileset_data+$180, X
    JMP @IncY2               ; Then jump back to inc Y by 2 to check the next tile property
   
   @ContinueLoad:
    JSR LoadMapPalettes     ; load palettes
    JSR DrawFullMap         ; draw the map onto the screen

...!!!!!!!!!



Update: Added SFX to opening chests.  :D
« Last Edit: July 03, 2019, 05:56:51 pm by Jiggers »
I know exactly what I'm doing. I just don't know what effect it's going to have.

Vanya

  • Hero Member
  • *****
  • Posts: 1489
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #371 on: July 03, 2019, 07:21:58 pm »
Wicked!!

Lets see...
Tile shenanigans...
Push Blocks (1 for each direction.)
Hidden Item (Now that treasure chests have graphics, we may need a version with no graphics.)
Conveyor Tiles (1 for each direction.)


BRB

Jiggers

  • Full Member
  • ***
  • Posts: 248
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #372 on: July 03, 2019, 11:12:50 pm »
Hidden items are in the works! With new messaging and they don't add the opened chest tile to whatever tile the treasure is in.

Doing some dialogue table re-jiggering, things are broken again for a bit. Also accidentally made a "keep off the grass" change to towns; NPCs will not move if grass tiles are set to have a treasure in them.

Had to move some banks around again, because Dialogue takes up SO much space... Just adding the table pushed it over 160 bytes. In the future, might have to split it again, differently. For now object talk routines are in their own bank... Unless this won't work.

Also did some work on tiles that hide the sprite. They work when moving, but stop working when you press any other button.

Lastly, fixed the treasure bug where getting gold would give the wrong amount, because it was using the Weapon/Armour price table. But until I fix the other stuff, that's not live.

I'm very bad at using GitHub properly.



Edit: Things should be fixed. Dialogue tables are split into 2 banks, with a variable that is set to tell the game what bank to read from. Because of this, the tables cannot be moved, and the GetDialogue routine in both banks needs to be the same. But it works!

NPCs and sprite objects use Table 2, since they are now coded to be able to. That leaves all of Table 1 for tile-based dialogue, such as reading descriptions of things as you sniff around...?

Options menu in the title screen is fixed... again.

"Invisible" chests now work, but NPCs won't walk on them. These do not exist unless you put them in; you can make any tile a treasure tile. The game will not alter sprites when they're opened, and will not display anything stating you've already obtained the treasure, but it does have new dialogue when you first find it: "While searching around, you found... [item]"

update: This is still bugged. Game crashes when talking to certain NPCs and I can't figure out which ones those are.
« Last Edit: July 04, 2019, 02:33:56 am by Jiggers »
I know exactly what I'm doing. I just don't know what effect it's going to have.

Vanya

  • Hero Member
  • *****
  • Posts: 1489
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #373 on: July 04, 2019, 01:21:26 am »
I'm back.
Had to go to work.

I suck at github pretty bad, too. So no worries there.

Going back to tile ideas... how about animated tiles so the ocean can stop being lifeless.
Maybe even do two types. One would be tile based animation. And the other could use palette animation.

A hot spring tile a`la Breath of the Wild that slowly restores HP and/or MP when you stand still on them.

A bog tile that slows your movement down. Could be used for swamps, sand, or deep snow.

Teleport tiles with animation.

Bridge tiles. Two types.
1) When you enter the tile horizontally, the sprite is above the tile, you can move horizontally freely, and you can only move vertically to other tiles of the same type. However, when you enter the tile vertically, the sprite is below, and you can move freely in any direction.
2) When you enter the tile vertically, the sprite is above the tile and you can move vertically freely, and you can only move horizontally to other tiles of the same type. However, when you enter the tile horizontally, the sprite is below, and you can move freely in any direction.
(This is probably way more complicated than it needs to be.)

On/Off blocks that are either solid or walk-able depending on the state of a matching switch tile.

Ladder tiles that you can only move through vertically and force the sprites to face up.

An unlit torch tile that makes all the other tiles in the room black, and can be lit by using a quest item on it at which point all the tiles are returned to normal.

Cracked Floor tiles that turn into holes you can fall through after you step off of them.
Cracked Floor tiles that turn into holes if you stay on them for too long.

Solid tiles that you can only move through if you have a certain quest item. Could be used for deep water.

Jiggers

  • Full Member
  • ***
  • Posts: 248
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #374 on: July 04, 2019, 03:59:26 pm »

this mother-fluffin' old fart here
this man
 of all like, 200 npcs in this game
 this gandalf-bearded old flour sack
is the ONLY ONE.
to have 4 bytes in his dialogue table instead of 5
So the routine that checks what bank to use to get the dialogue data... wraps over to the next NPC in line... crashes the game.
Out of all the people in the game I talk to to test my new dialogue system
I chose him
the ONE. PERSON. WHO WAS BUGGED.

...

I like some of those tiles, some not so much. XD Hopefully I can put some skeleton code in to handle things better so its easier to change around though!

I really hope the version up on github is working now... I would like to play it for a while and finally beat it maybe...
I know exactly what I'm doing. I just don't know what effect it's going to have.

Disch

  • Hero Member
  • *****
  • Posts: 2717
  • NES Junkie
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #375 on: July 04, 2019, 09:40:58 pm »
Out of all the people in the game I talk to to test my new dialogue system
I chose him
the ONE. PERSON. WHO WAS BUGGED.

... and you're angry about that?  I'd say you were incredibly lucky!  I mean, that's why you tested it, right?  To make sure it works and to find bugs?

Much better to have the bug exposed immediately than to have a random user 3 months in the future tell you about a crash that you struggle to reproduce.

 :thumbsup: :beer:

Jiggers

  • Full Member
  • ***
  • Posts: 248
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #376 on: July 04, 2019, 10:20:54 pm »
XD Yeah... after just staring in disbelief, I was like... what are the odds? I found the one thing wrong with it! ...(so far)...

Except the 2-3 hours of going, "eff it, what could possibly be doing this, I guess half the NPCs must crash the game now! Time to stare at the code trying to figure out what I could do different..."

Since I was getting similar CPU crashes while testing non-chest treasures right before, I thought maybe they were related, too. Someday I'll learn to actually follow-through on the debugger when facing a crash instead of trying to track it down in the raw code.

And I played around with the forest effect some, trying to figure out how it works! In doing so, I fixed a possibly-undocumented bug in the original game, where while standing in a forest and pressing a direction into a mountain or the ocean or whatever, you come out of the forest without moving tiles. Now, the lower sprites stay hidden--and instead of invisible, they're just behind the background, so there's a kind of transparency effect! Still need to test that with dungeon walls and things, not sure if the transparency will look okay.

July 05, 2019, 04:22:47 pm - (Auto Merged - Double Posts are not allowed before 7 days.)
Got sprite-hiding tiles working! Same as forest hiding, but for the head too. Not actually completely invisible.

Has FF1 always had sprites 2-3 pixels up from the bottom of the tile they're on, to give it a bit of a 3d look? Never noticed before, but now I see the head poking up above a tile a bit and I wonder if I mucked something up or if I just never noticed. Pretty cool that they did that if they did! Just uh... might make it look a bit weird. Might have to do the moving-the-sprite-offscreen thing...
« Last Edit: July 05, 2019, 04:22:47 pm by Jiggers »
I know exactly what I'm doing. I just don't know what effect it's going to have.

Vanya

  • Hero Member
  • *****
  • Posts: 1489
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #377 on: July 05, 2019, 06:51:44 pm »
That partial transparency is how they do it in FF2 and FF3. So it's all good.

And, yeah, the map sprites have always been a couple pixels up. :D

Jiggers

  • Full Member
  • ***
  • Posts: 248
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #378 on: July 06, 2019, 03:35:21 pm »
So long as passages are designed to make sure the tops of heads aren't poking through walls, I suppose that's fine!

New update: Re-organized the way the healing tiles work (also the healing tiles work, I did that yesterday I think)! Safe save tiles also work.

For testing purposes, open up Bank 12 and set these two tiles like so:


Then go into Coneria and check the save option while standing on the grass, and on the cobbles. And poke at the shadow of the inn. You shouldn't be able to step on it now... I'm pretty proud of the effect when you press A though!

Also added red emphasis to the screen flash when stepping on damage tiles, why not.
I know exactly what I'm doing. I just don't know what effect it's going to have.

Vanya

  • Hero Member
  • *****
  • Posts: 1489
    • View Profile
Re: FF1 MMC5 Disassembly Updates
« Reply #379 on: July 06, 2019, 06:47:37 pm »
Well, the grass tile lets me save.
Fantastic job on the healing spring property!
Love the flashy effect!!
« Last Edit: July 06, 2019, 06:53:17 pm by Vanya »