Shell Monsters Text Display

KingMike · 06-09-2003, 10:37 AM

Currently, a problem with Shell Monsters Story's text display system is that it only allows 16 characters per line in the dialouge. I think that is too small (maybe 22 characters per line would be ideal?, but if the code worked, I'd be able to use the entire width of the screen if I wanted), but it is very difficult to do the hack (I've found the line of code that handles this, but then it breaks the line break code, got around that on lines still within the original 16-character limit, but lines more than 16 characters will insert two line breaks (quadruple-spacing) at the next line break. Right now, it's a wrestling match with the ROM's ASM.

I'm wondering if you people think it'll be a problem. It might be if I get 8-character names (I'll see if that's possible at the end, though). And I will be lengthening item names (possibly 14 characters at the longest. Is that a problem to have item/monster names take up an entire line of dialouge?
Perhaps I should just insert the text I've got and worry about it later?

EDIT: Almost forgot to mention. I think I've got the hacking done to be good on text space (dialouge and menus).

ChrisRPG · 06-10-2003, 04:43 PM

Heh, I ran into the same thing with slayers RPG. Not funny, but weird.

It had 13 characters per line, now 26. And now my line breaks are 2 line break characters instead of one. There is a way to redo it, but not really worth the time considering I have a lot of hacking to do on other projects too. And 2 line breaks will just take up extra space, which is no problem if the rom can be expanded. So I would do whatever is more convenient for you that doesnt comprimise the look too much. Also having names on 1 line is ok too, in my opinion. I would rather see the full name then have an abbreviation. I did this in the battle text for dq12. Some item/enemy names were just too long to allow anything else on the same line. The other option is to do an wordwrapping/autoscroll routine. But that is not fun at all, and takes quite a bit of time and energy, the upside being the feeling of accomplishment that you get from doing programming like that.

KingMike · 06-13-2003, 10:30 PM

Looks like I'll definitely need to work out a workaround for this. The battle text is particularily bad. I'll have to crop it badly to get it to fit within the alloted space (the game doesn't mind scrolling one line off the screen (it'll auto-scroll the text up one line), but having a sentance take up four lines of the screen (like when a character dies, and it says:
BLAHBLAH has
died!
and then the
spirit slipped
away from the
body.), that sends the game into inifinite loop).
Think I'll have to do like Zhi

, and skip the problematic code altogether, running my own solution code.
Well, I've recorded a trace of one iteration through the text loop, to the point where I can seperate dialouge and menu buffer to VRAM routines (the game copies all the text, including converting variables to regular text to a buffer, then copies it to a second buffer for formatting. What I'm going to try to do is to take buffer 1 (basically the text window, except accents haven't been accounted for, but since English doesn't need accents) and shove that directly into VRAM instead of the game routine (which formats the code to 8x16 (8x8 letter plus an 8x8 accent (space, ", or o) and then shoves it into 8x16, somewhere enforcing the 16-characters per line limit). With any luck I'll only have to write out 40 bytes worth of JSRs (hoping to keep the JSRs lined up) and maybe 20 or 30 bytes of my own VRAM routine. If that doesn't work, I guess I could set a flag to tell if there's dialouge, then go the buffer to VRAM routine, and set it to run the hack routine instead if it's doing dialouge (menus don't use buffer 1, so the game would blow up if I just hacked the buffer-to-VRAM routine).

ChrisRPG · 06-14-2003, 05:38 AM

I had almost the same thing in dq12. But it did the battle text in ram once at 7e:2400-7e:253f first before copying to vram. I took the handakuten dakuten accent checks, and converted them to a jsl to my own autoscroll routine. So my code basically did the same the games did, but scrolled one line instead of 2 and allowed 5 lines on the screen instead of 2 or 3. anyway Its kind of long to post what I did here. But if you want I can send you some more detailed things of how I handled that problem. I basically made my own scroll routine and clear buffer routine. And nop'ed the games scroll routine. That way I knew it would do what I needed it to. There is nothing wrong with just taking out the games problematic code, and making your own code. I do it all the time. Sometimes, its just not kosher to use the games routines when your own can do the job better. Since the game was made and optimized for Japanese text and not Englsih. And dont let anyone tell you other wise.

As long as you have traced thorugh enough to know which adresses hold what data, and what needs to be in x,y and a when its done, and what the flags should be, you are fine. Another hint if one address holds the start address of ram buffer, it was $04 in dq12, you can then chack that to see if its the battle text or the regular text. Like $04 had $2400-253f for battle text and 2800-2bff for regular text. I did cmp #$27ff, if it was greater than that it was regular dialogue and went back to the games routines, if less than that it was battle text and it branched to my routines before going back to the games routines. It would be nice if your game has that type of thing in it.

I would be interested in looking at how you handled it too, if you wouldnt mind sharing with me your code when its done. I am always open to learning new things and innovative ideas to cope with text problems.

KingMike · 06-18-2003, 10:40 PM

I believe I tracked down 1 RAM byte that I could use to tell if it's menus or dialouge, but I'm not sure of the validity of it. ($00CA (00 appears to be dialouge-not-in-progress, 01 appears to be dialouge-in-progress), because it is nowhere near any of the other known dialouge-related stuff). I made a hack of the formatted text to VRAM routine that skips to the end of the routine if 00CA==01, and it seems to give the desired (for now) result (no text is printed). So, I guess it's ready for the code writing. Only thing I'm not sure of is why the screen jumps around as soon as I write a character to the name table (the character prints, then the window scrolls to the edge of the screen. Perhaps I'm missing something? Scroll register needs a write? Wait for VBlank?
Anybody able to explain how a scroll-induced name table works (I know how to make a non-scrolling name table/tilemap)?

KingMike · 06-24-2003, 01:53 PM

Yep. Resetting the scroll register worked. Now I just have to figure out how to make the routine one once, then make the game think it has finished updating the text (to end text update after one time through, instead of running the routine for every letter). And, I'll probably have to hack the text-scroll routine also. Probably'll also be good to rig up a new end of line code, to get around the extra spaces the game throws in (since it uses an AND #$0F make the game fill in the rest of the space on the line with space. Any good ways to get a mod-$17 instead of mod-$0F, which is what the game used the AND for? Otherwise, yes the new end-of-line code's probably better, and just use the X register and CPX?

UPDATE: Got a routine done, but I think moving the data around causes a crash. I think I'm going to leave the text data as it is, and just write a routine to print to the screen (so, if I only get 3 longer instead of 4 short ones (and I'm putting in a maximum of 6 short lines, which has been ASM fixed to not crash the game), right now I think it'll be worth it).

06-10-2003, 04:43 PM	#2
ChrisRPG Game Translation Guru Join Date: Apr 2002 Location: Springfield , MA, USA Age: 39 Posts: 1,939	Heh, I ran into the same thing with slayers RPG. Not funny, but weird. It had 13 characters per line, now 26. And now my line breaks are 2 line break characters instead of one. There is a way to redo it, but not really worth the time considering I have a lot of hacking to do on other projects too. And 2 line breaks will just take up extra space, which is no problem if the rom can be expanded. So I would do whatever is more convenient for you that doesnt comprimise the look too much. Also having names on 1 line is ok too, in my opinion. I would rather see the full name then have an abbreviation. I did this in the battle text for dq12. Some item/enemy names were just too long to allow anything else on the same line. The other option is to do an wordwrapping/autoscroll routine. But that is not fun at all, and takes quite a bit of time and energy, the upside being the feeling of accomplishment that you get from doing programming like that. __________________ RPGOne Translations. Your growing video game translation place. Do not judge others, lest you be judged 10 times over. -RPGWizard

06-14-2003, 05:38 AM	#4
ChrisRPG Game Translation Guru Join Date: Apr 2002 Location: Springfield , MA, USA Age: 39 Posts: 1,939	I had almost the same thing in dq12. But it did the battle text in ram once at 7e:2400-7e:253f first before copying to vram. I took the handakuten dakuten accent checks, and converted them to a jsl to my own autoscroll routine. So my code basically did the same the games did, but scrolled one line instead of 2 and allowed 5 lines on the screen instead of 2 or 3. anyway Its kind of long to post what I did here. But if you want I can send you some more detailed things of how I handled that problem. I basically made my own scroll routine and clear buffer routine. And nop'ed the games scroll routine. That way I knew it would do what I needed it to. There is nothing wrong with just taking out the games problematic code, and making your own code. I do it all the time. Sometimes, its just not kosher to use the games routines when your own can do the job better. Since the game was made and optimized for Japanese text and not Englsih. And dont let anyone tell you other wise. As long as you have traced thorugh enough to know which adresses hold what data, and what needs to be in x,y and a when its done, and what the flags should be, you are fine. Another hint if one address holds the start address of ram buffer, it was $04 in dq12, you can then chack that to see if its the battle text or the regular text. Like $04 had $2400-253f for battle text and 2800-2bff for regular text. I did cmp #$27ff, if it was greater than that it was regular dialogue and went back to the games routines, if less than that it was battle text and it branched to my routines before going back to the games routines. It would be nice if your game has that type of thing in it. I would be interested in looking at how you handled it too, if you wouldnt mind sharing with me your code when its done. I am always open to learning new things and innovative ideas to cope with text problems. __________________ RPGOne Translations. Your growing video game translation place. Do not judge others, lest you be judged 10 times over. -RPGWizard

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

06-09-2003, 10:37 AM	#1
KingMike PROGRAMED BY HACK Join Date: Apr 2002 Age: 26 Posts: 572	Currently, a problem with Shell Monsters Story's text display system is that it only allows 16 characters per line in the dialouge. I think that is too small (maybe 22 characters per line would be ideal?, but if the code worked, I'd be able to use the entire width of the screen if I wanted), but it is very difficult to do the hack (I've found the line of code that handles this, but then it breaks the line break code, got around that on lines still within the original 16-character limit, but lines more than 16 characters will insert two line breaks (quadruple-spacing) at the next line break. Right now, it's a wrestling match with the ROM's ASM. I'm wondering if you people think it'll be a problem. It might be if I get 8-character names (I'll see if that's possible at the end, though). And I will be lengthening item names (possibly 14 characters at the longest. Is that a problem to have item/monster names take up an entire line of dialouge? Perhaps I should just insert the text I've got and worry about it later? EDIT: Almost forgot to mention. I think I've got the hacking done to be good on text space (dialouge and menus).

06-13-2003, 10:30 PM	#3
KingMike PROGRAMED BY HACK Join Date: Apr 2002 Age: 26 Posts: 572	Looks like I'll definitely need to work out a workaround for this. The battle text is particularily bad. I'll have to crop it badly to get it to fit within the alloted space (the game doesn't mind scrolling one line off the screen (it'll auto-scroll the text up one line), but having a sentance take up four lines of the screen (like when a character dies, and it says: BLAHBLAH has died! and then the spirit slipped away from the body.), that sends the game into inifinite loop). Think I'll have to do like Zhi , and skip the problematic code altogether, running my own solution code. Well, I've recorded a trace of one iteration through the text loop, to the point where I can seperate dialouge and menu buffer to VRAM routines (the game copies all the text, including converting variables to regular text to a buffer, then copies it to a second buffer for formatting. What I'm going to try to do is to take buffer 1 (basically the text window, except accents haven't been accounted for, but since English doesn't need accents) and shove that directly into VRAM instead of the game routine (which formats the code to 8x16 (8x8 letter plus an 8x8 accent (space, ", or o) and then shoves it into 8x16, somewhere enforcing the 16-characters per line limit). With any luck I'll only have to write out 40 bytes worth of JSRs (hoping to keep the JSRs lined up) and maybe 20 or 30 bytes of my own VRAM routine. If that doesn't work, I guess I could set a flag to tell if there's dialouge, then go the buffer to VRAM routine, and set it to run the hack routine instead if it's doing dialouge (menus don't use buffer 1, so the game would blow up if I just hacked the buffer-to-VRAM routine).

06-18-2003, 10:40 PM	#5
KingMike PROGRAMED BY HACK Join Date: Apr 2002 Age: 26 Posts: 572	I believe I tracked down 1 RAM byte that I could use to tell if it's menus or dialouge, but I'm not sure of the validity of it. ($00CA (00 appears to be dialouge-not-in-progress, 01 appears to be dialouge-in-progress), because it is nowhere near any of the other known dialouge-related stuff). I made a hack of the formatted text to VRAM routine that skips to the end of the routine if 00CA==01, and it seems to give the desired (for now) result (no text is printed). So, I guess it's ready for the code writing. Only thing I'm not sure of is why the screen jumps around as soon as I write a character to the name table (the character prints, then the window scrolls to the edge of the screen. Perhaps I'm missing something? Scroll register needs a write? Wait for VBlank? Anybody able to explain how a scroll-induced name table works (I know how to make a non-scrolling name table/tilemap)?

06-24-2003, 01:53 PM	#6
KingMike PROGRAMED BY HACK Join Date: Apr 2002 Age: 26 Posts: 572	Yep. Resetting the scroll register worked. Now I just have to figure out how to make the routine one once, then make the game think it has finished updating the text (to end text update after one time through, instead of running the routine for every letter). And, I'll probably have to hack the text-scroll routine also. Probably'll also be good to rig up a new end of line code, to get around the extra spaces the game throws in (since it uses an AND #$0F make the game fill in the rest of the space on the line with space. Any good ways to get a mod-$17 instead of mod-$0F, which is what the game used the AND for? Otherwise, yes the new end-of-line code's probably better, and just use the X register and CPX? UPDATE: Got a routine done, but I think moving the data around causes a crash. I think I'm going to leave the text data as it is, and just write a routine to print to the screen (so, if I only get 3 longer instead of 4 short ones (and I'm putting in a maximum of 6 short lines, which has been ASM fixed to not crash the game), right now I think it'll be worth it).

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)