|
|
Post by Ascended Mermaid on Dec 19, 2012 10:19:50 GMT -5
Hmmm... yeah, still the 8x8 font. Only since I had to restore from two days ago, I'm extremely confused and have no idea what needs to be redone. :\ As far as I could tell, the subroutine is directly related to printing the text onscreen. As soon as it reaches the far right-side, instead of doing a line-break, it goes back about 8 spaces and continues to print (and does this two times) before doing a line break. Wait... yeah, that sounds familiar... it's supposed to do that, come to think of it. 8+8=16. It's simply because it *couldn't* linebreak. I forgot about that... this revelation comes to me now, of course, right after I decided to rollback to the 17th for the second time today. :\
Let's see... hmmm... it probably is the text buffer, although I'm not sure... because there doesn't seem to be anything else. Those ASLs affect how the letter tiles are printed to the PPU, though. In addition, either a register or memory is incremented by 1 sometime after that routine, and that 1 is then multiplied up to #$40 -- or because of my two NOPs, #$10. And then I fixed that AND to read #$03, for the max number of linebreaks. And I NOP'd another ASL just below that. More throes of insomnia, as usual. Overall, I know this affects how the text is printed to the PPU. It doesn't seem to print anything directly to the in-game window, rather it prints to the PPU (tiles $40-$7F), which are the dialogue window's tiles.
The dialogue window is like this:
40-5E (evens)
41-5F (odds)
60-7E (evens)
61-7F (odds)
I think I needed to do something with that routine; I was able to manage to get it to display 64 characters, which was also most definitely needed, as well as that linebreak fix mentioned earlier.
I have to make sure it prints just 1 tile instead of 4. (...I was naughty with the tile editor and cheated a bit, placing every 8x8 character in the "top-left" corner, spacing them apart.)
I also need to increase the characters for the TitleTable; I need more than 8 characters.
I'm pretty braindead tired at this point. So maybe I'll rest a bit and check it out more when I get up again.
|
|
|
|
Post by Ascended Mermaid on Dec 19, 2012 10:41:01 GMT -5
 As you can see, the tiles are printed in the following order... 1313 2424 Due to the 4 tiles being printed like so: 13133 24244 (Each tile contains 2 tiles (a top and a bottom tile) but it also prints the tile to the right, as it's still trying to print a big letter, so it prints like 11, 22, 33, 44, etc.) If a tile is printed at the very end, this happens: 13133 24244 FF Which caused the background tiles to be overwritten in that screenshot. // To further elaborate: I sdneos ti agru When unscrambled, is this: It is dangerous Hence: 13 24 A tile would normally print like this: 11 11 As it's trying to print a big letter. Instead, I just want it to print like this: 1 |
|
|
|
Post by Xalphenos on Dec 19, 2012 11:03:41 GMT -5
Is that it printing every tile without anything noped out of that code you posted? I see what its doing. Do you have a need to use both large and small fonts in the dialog window?
|
|
|
|
Post by Ascended Mermaid on Dec 19, 2012 12:01:04 GMT -5
Not at all.  // That is, I have no need for both large and small fonts. It prints every tile regardless of whether or not I NOP anything from that routine. I can tell because of how everything is overwritten by a 'phantom tile'; that blank tile accounts for every other space in my font table. |
|
|
|
Post by Xalphenos on Dec 19, 2012 12:22:23 GMT -5
Which rom are you using as a base for this, the Japanese?
|
|
|
|
Post by Ascended Mermaid on Dec 19, 2012 12:34:26 GMT -5
Yeah, that's the one. |
|
|
|
Post by kagemusha on Dec 19, 2012 16:44:15 GMT -5
I've hacked this 16x16 font routine down to 8x8 two times now. Mind you not Faxandu, but other games that use the same font engine etc with slight variation. Usually there's a table that loads a fixed set of tiles from the PPU into RAM etc, but there's also one that starts with a base tile and uses some math to add/subtract and write the next tiles into RAM etc. You need to update this so that the fixed tiles being read are done in a linear fashion instead of taking into account the 16x16 stuff.
BTW, this font system is capable of being VWF.
I'd also rework the name entry to be 8x8. You can still keep the same style etc. and it will make things easier/simpler in dealing with the code. It would look something like this with the space in the middle for the 8x8 font tile.
xxx
x x
xxx
|
|
|
|
Post by Ascended Mermaid on Dec 19, 2012 17:31:52 GMT -5
Thanks for the confirmation! That does make sense, though I've been having a devil of a time finding the routine. Is it something simple like my theory: LDA ; (loop start) STA INY LDA STA DEY INX AND #$10 BNE $(loop start) Or is it a fair deal more complex? As for VWF, I figure that could be an entirely separate hack. I no doubt should probably soak my brain in something more than just opcodes, though; binary digits come to mind. I honestly don't know the first thing about bits. That's pretty much required reading, right? // As far as the table goes, I figured I was looking for something that either reads as 40, 41, 60, 61 - or - 40, 42, 44, 46, but it may have something that looks like 80 (or so; a byte that tells the game how big the tiles are, much like how it handles sprite data, which also has a palette byte) in there as well. I think the game switches to bank C when it writes tiles. I've been focusing all of my attention on bank F (where I've found many of these subroutines that I've been altering for print positions in the PPU, etc.) so I have ignored C entirely. |
|
|
|
Post by kagemusha on Dec 19, 2012 21:54:11 GMT -5
Dunno. All you need to do is set a write breakpoint for the PPU address where the text appears and be sure to use the trace logger in case you need to trace back a bit.
|
|
|
|
Post by Xalphenos on Dec 19, 2012 22:28:29 GMT -5
Which is $1400 but don't enable the breakpoint until after you break at your posted code when the text box is drawn but blank. Which should land you a little after $CF97 still in bank F.
|
|
|
|
Post by Ascended Mermaid on Dec 19, 2012 22:42:45 GMT -5
Wait a second... THAT'S how the trace logger should be used?! I've always used it in conjunction with the data logger, haha... very time consuming! Your suggestion definitely sounds better! As for where the text appears... ... ... I should be able to find it easily enough if I use my new table (created for the 8x8 font) and watch the RAM. I had completely forgotten about it. (In my defense, insomnia has taken its toll, which only made matters worse.) It's good to get my brain working again. Hey, thanks for the jump start!  // (note to self) ; Also on my redo list: find the "wipe dialogue" routine and the "player input" routine -- I have to make it wipe correctly (again) after my 'CMP $FA, BEQ interrupt' routine. // Oh hey, you snuck up on me! Thank you as well Xalphenos! |
|
|
|
Post by kagemusha on Dec 19, 2012 23:14:36 GMT -5
I mean the actual PPU address that you can find by looking at the name table viewer. You would be setting a ppu write breakpoint for the actual screen coordinates for the text.
|
|
|
|
Post by Ascended Mermaid on Dec 20, 2012 0:04:04 GMT -5
Alright, it looks like we're all on the same page. It breaks at 0F:CF9B.
|
|
|
|
Post by Ascended Mermaid on Dec 20, 2012 10:59:08 GMT -5
I had the bright idea of using what I already know about writing the letter tiles to the PPU. Here's something simple I wrote: INC $0216 ; Start INC $0216 ; Letter +2 JSR Print LDA $0216 ; Check_1E CMP $1E BNE Check_1F LDA #$01 ; Print_odds STA $0216 CMP $1F ; Check_1F BNE Start LDA #$00 ; Print_evens STA $0216 INC $0217 INC $0217 ; Line +2 LDA $0217 CMP #$04 ; Are the lines maxed? BCC Start RTS I haven't tested that code yet, of course, and it's still slightly unfinished. I realize that unless the tiles are printed in singles instead of quadruples, letter tiles are going to be overwritten by the aforementioned 'phantom tiles'. My proposed method would scramble the dialogue in the PPU, but unscramble the in-game dialogue. What I'm thinking now is maybe I'll be able to find the data I need for letter tile size via a PPU breakpoint as you have both mentioned. I honestly didn't understand what I was looking at around CF97, so I'll have to carefully study the code. I'm a little slow so bear with me here, lol! // Yay, typos. |
|
|
|
Post by Ascended Mermaid on Dec 21, 2012 4:25:30 GMT -5
After overwriting a similar routine with the new code, I got it to print the first line of dialogue quite clearly, so I know I'm doing *something* right.
// Every time it JSRs to print the next letter, the whole routine starts over. It continues until the game breaks due to an unproductive loop.
I'm guessing that I need a base case.
LDA $0216
AND $0217
BEQ Start_Loop ; If the bytes at 216 and 217 = 0, start the dialogue loop.
RTS ; Otherwise, it will (hopefully) return to where it left off.
INC $0216 ; Start_Loop
For some reason, I tend to think better when I write it all out like this.
Bonus points: I should either jump to the check or add a check (depending on the circumstance) for scripting opcodes #$FA-FF so that they're not displayed as letters.
|
|
|
|
Post by Ascended Mermaid on Dec 21, 2012 8:49:26 GMT -5
 Well, this is progress, anyway. I'm not exactly sure what it thinks it's doing, but after posting that code and editing it some more, I felt pretty silly. Here's something a little more useful: I'm sure I'm still making amateur mistakes, but I'll get it soon. // Yeah, I know that last part around $F61D doesn't make sense. The objective with that was to simplify the Even - Odd - Even - Odd exchange. Evens are lines 1 and 3, odds are lines 2 and 4. See? Amateur mistakes. Plus, I'm not even taking full advantage of the registers. // Modified again. |
|
|
|
Post by Ascended Mermaid on Dec 22, 2012 6:27:22 GMT -5
 Here we go! I'm SO much closer now. My code may be a little iffy in spots, like the order of some events could be different. One thing to keep in mind is that after the 'Print this letter' subroutine, this all starts over from 0F:F601. I also have to take care of some stray PHAs and/or PHPs, or else the game will crash on a stack overflow. Also, until I fix that 16x16 tile business, the game will overwrite the first and third lines (while it's writing to the second and fourth lines, due to the order of the tiles in the PPU) with my 'phantom' (blank) tiles. 0F:F601:AD 16 02 LDA byte_216 = #$06 ; Load letter position to A 0F:F604:2D 17 02 AND byte_217 = #$02 ; Check if the letter and line positions match (Start of Dialogue) 0F:F607:F0 01 BEQ $F60A ; If so, start a new loop 0F:F609:60 RTS ; If not, go back to the old loop 0F:F60A:EE 16 02 INC byte_216 = #$06 ; Letter position + 1 0F:F60D:EE 16 02 INC byte_216 = #$06 ; The second letter ahead in the PPU is the next letter of the line. 0F:F610:20 6E F5 JSR $F56E ; Print this letter 0F:F613:AD 16 02 LDA byte_216 = #$06 ; Load Letter Position to A 0F:F616:C9 20 CMP #$20 ; Is the letter position within bounds? 0F:F618:90 F0 BCC $F60A ; If so, do another letter 0F:F61A:AC 16 02 LDY byte_216 = #$06 ; As this is called by another routine, we'll load letter position to Y 0F:F61D:88 DEY 0F:F61E:88 DEY ; Letter position - 2 0F:F61F:C0 03 CPY #$03 ; Is the letter position less than 3? 0F:F621:B0 FA BCS $F61D ; Keep decreasing letter positions until it is 0F:F623:88 DEY ; Letter position - 1 0F:F624:98 TYA ; Transfer Y to A 0F:F625:  16 02 STA byte_216 = #$06 ; Store A to letter position 0F:F628:C9 00 CMP #$00 ; Is the letter position 0 again? 0F:F62A:D0 E4 BNE $F610 ; If not, print the current letter 0F:F62C:EE 17 02 INC byte_217 = #$02 ; If so, we've already done the first and second lines 0F:F62F:EE 17 02 INC byte_217 = #$02 ; Line position + 2 0F:F632:AD 17 02 LDA byte_217 = #$02 ; Load line position to A 0F:F635:C9 04 CMP #$04 ; Is the line position within bounds? 0F:F637:90 D7 BCC $F610 ; If so, do another letter 0F:F639:60 RTS ; The end // It doesn't crash if I change that JSR to a JMP. Simple enough fix. Now I just have to figure out how to make it write lines 3 and 4 properly. |
|
|
|
Post by Ascended Mermaid on Dec 22, 2012 13:17:36 GMT -5
0F:F61A:AC 16 02 LDY byte_216 = #$02 ; Uh-oh
0F:F61D:88 DEY
0F:F61E:88 DEY ; 2 - 2 = 0
0F:F61F:C0 03 CPY #$03
0F:F621:B0 FA BCS $F61D
0F:F623:88 DEY ; 0 - 1 = FF
0F:F624:98 TYA
I'll have to be a little more creative. I need it to change to 1 or 0 (whichever happens to be the opposite at the time) without the risk of going past 0. I did try SBC #$1F before, but that messed up when the value was lower than 1F. The reason it returned a 2 is because the FE (line break) "script code" (for the purposes of this writing, any letter byte with a hex >= FA) jumps to $F61A... hmmm... ... ...
|
|
|
|
Post by Ascended Mermaid on Dec 23, 2012 12:18:40 GMT -5
Right, right right. My script only accounts for the first two lines, which means I'm going to have to expand it a bit. This one doesn't crash, so I know I did something right. 0F:F601:AD 16 02 LDA byte_216 = #$53 0F:F604:2D 17 02 AND byte_217 = #$00 0F:F607:F0 01 BEQ $F60A 0F:F609:60 RTS 0F:F60A:EE 16 02 INC byte_216 = #$53 0F:F60D:EE 16 02 INC byte_216 = #$53 0F:F610:4C 6E F5 JMP $F56E 0F:F613:AD 16 02 LDA byte_216 = #$53 0F:F616:C9 20 CMP #$20 0F:F618:90 F0 BCC $F60A 0F:F61A:AC 16 02 LDY byte_216 = #$53 0F:F61D:C0 20 CPY #$20 0F:F61F:B0 06 BCS $F627 0F:F621:C8 INY 0F:F622:C8 INY 0F:F623:C0 20 CPY #$20 0F:F625:90 FA BCC $F621 0F:F627:98 TYA 0F:F628:E9 1F SBC #$1F 0F:F62A: 16 02 STA byte_216 = #$53 0F:F62D:D0 E1 BNE $F610 0F:F62F:EE 17 02 INC byte_217 = #$00 0F:F632:EE 17 02 INC byte_217 = #$00 0F:F635:AD 17 02 LDA byte_217 = #$00 0F:F638:C9 04 CMP #$04 0F:F63A:B0 CD BCS $F609 0F:F63C:4C 10 F6 JMP $F610 // I'm not sure why byte 216 is going way past #$20... I got rid of CMP #$00, I forgot how pointless that was until now. |
|
|
|
Post by Ascended Mermaid on Dec 27, 2012 4:09:50 GMT -5
What in the world... wait a second... 0F:F623:C0 20 CPY #$20 0F:F625:90 FA BCC $F621 0F:F627:98 TYA 0F:F628:E9 1F SBC #$1F 0F:F62A: 16 02 STA byte_216 = #$53 0F:F62D:D0 E1 BNE $F610 Check if it's 20, subtract 1F, BNE $F610 -- I think I see now why it never advances to 0F:F62F. 32 minus 31 will NEVER equal 0! Maybe I need to change the last CPYs to #$1F or something. Hmmm... something's still way off. I know I probably need to fix the input break subroutine (so it stops printing, waiting for player input). For whatever reason the first line can be overwritten twice in a row. Probably since I'm not CPYing an even hex and subtracting an odd hex. Also, the code stops working after line breaks and decides to overwrite the first letter of lines 3 and 4 instead. Furthermore, $0216 STILL manages to go higher than #$20. Another subroutine could be the culprit. |
|
16 02 STA byte_216 = #$07
