************************************* Dragonball Z Hyper Dimension: Journal ************************************* ********** 06/28/2008 ********** 1st string at $03047A in ROM file. $06847A in SNES memory. $FFF0, $FFF4, $FFF8 and $FFFF are all control codes. 2 byte characters. Pointers begin at $030386. $068386 in SNES memory. ********** 06/29/2008 ********** Tilemap for story text is at $5800 in VRAM and $02BC13 in ZST. Tilemap is drawn in RAM at $7E710C before the text is read. Static tilemap! Note: Need to add check for end string tokens in cartographer when using a pointer method. The tiles for each screen of text are stored in two places. The first five lines of tiles are stored at $26E13 in ZST and $3100 in VRAM. The last five lines are stored at $028C13 in ZST and $4000 in VRAM. Five lines of tiles equal 50 16x16 tiles. So 10 16x16 tiles per line. When a $FFF4 is read, the location in VRAM to draw the tiles is changed from the first area to the second and the buffer in RAM at $7E4000 is cleared for reuse. ********** 07/01/2008 ********** An explanation of the compression used on the font (and other data that uses the decompression routine at $00D7C8): Each block of compressed data begins with a 2 byte value that specifies the size of the uncompressed data. This is used to determine when to stop decompressing data. Next a byte of data is read that is used to determine how to handled the next block of data. Each bit of this byte is a flag. If a bit is 1, then the next byte of data in the ROM is copied directly to the decompression buffer in RAM. If a bit is 0, the next two bytes of data in ROM contain a pointer to the data earlier in the decompression buffer to copy to the current position and the length. The upper 12-bits are the pointer and the lower 4-bits specify the length of the data to copy minus 2. Therefore, the minimum size of a match is 2 bytes. ------ I got the decompressor working perfectly last night. The next task is to code the compressor, which should be relatively simple. The only trouble I'm having right now is deciding out how to locate the best match for the data in the look-ahead buffer. The quickest way would be a simple sequential comparision. Something like if decomp_buffer[X] is the same as look_ahead[0], compare the two buffers until they no longer match. Save the length of the data that's the same and the value of X. Increment X and then repeat until the end of the decomp_buffer is reached. If another match is found, compare the two buffers again and then compare the saved length to the current length of data. If the old data is longer than the current data, keep it, but if the new data is longer than the old data, replace the saved length and position variables. The only other problem I'll have is making use of the built-in "zero fill" function. Since this only occurs at the beginning of the compressed data, I suppose I can just check the first of the data. If the first byte is 0, calculate how many bytes after that are also zero. Then encode the length as both the pointer and the length of a lz pointer. ------ Compressor Design: 1. Clear buffers and set indexes to zero. 2. Calculate size of uncompressed data. 3. Store 16-bit size at start of compressed buffer. 4. Increment buffer index by 2. 5. Save current compressed buffer index as flag_location. 6. Clear flag variable. 6.1 flag_pos = 0; 7. if uncompressed index == 0, check the first byte of the compressed data. 2.1 if 0, check next byte(s) for zero. 2.2 see 10.2 for encoding instructions 8. Clear match_length and match_pos variables. 9. Search comp_buffer[] for the next value in the data buffer. 9.1 if found, compare the next byte in each buffer. 9.2 repeat until a comparison fails. 9.3 compare the length of this data to match_length. 9.4 if match_length < search_length, match_length = search_length; match_pos = search_pos 9.5 Repeat until search_pos == compressed buffer index. 10. Write flag and compressed data to buffer. 10.1 if(match_pos == 0 || match_length <= 2) 10.1.1 comp_buffer[cindex] = data_buffer[dindex]; 10.1.1 flag = 1 10.2 if(match_pos != 0) 10.2.1 distance = cindex - search_pos; 10.2.2 comp_buffer[cindex++] = (distance & 0xff00) >> 8; 10.2.3 comp_buffer[cindex] = (distance & 0xf0) | (match_length - 2) 10.2.4 flag = 0 10.3 Increment flag_pos 11. Repeat 8-10 while(flag_pos < 8) 12. Repeat 6-11 while(cindex < size) ********** 09/03/2008 ********** I've spent the past hour or so looking over this game after a two month hiatus, and I've just about got the VWF figured out. This game is, more or less, the same as Bare Knuckle 3. There's a static tilemap and a fixed number of characters per line. There's already an end of line control code that I can use for padding each line. The only thing I'll need to do is keep track of which line I'm on and how many are left to pad. So, two variables in addition to the shift variable and VWF buffer. The font is going to be 2bpp, so I don't have to add the outline on the fly, which might increase the amount of space I need for the VWF buffer a bit. I've got enough space though to work with, I think. ------ Okay, I've added the code to by-pass the compression and use my own uncompressed font. The code works perfectly. Gemini's thrown together a font for the game. I'm gonna see how it looks in-game before I decide whether to use it or not. ********** 09/04/2008 ********** I finished drawing the font and inserting it last night. It actually looks pretty good in-game just using cavespeak. So, it'll probably look phenomenal once I get the VWF in and working. It looks like I have 10 characters per line for narration strings; 9 for dialogue; and 14 for the Versus mode responses. I think the most pain free way of determining the maximum number of lines and characters per line is to create two new control codes to use at the start of each string. It's 2-4 more bytes per string, but it saves me the trouble of distinguishing the 3 different situations in code. I'll look into this more before I decide, though. I'm trying to avoid going the route I did with Bare Knuckle 3 and have a complicated table to load the data from. ------ There appear to be two text routines. The one at $02ED05 used by the narration and the one at $02EC59 used for character dialogue in story mode and their responses in versus mode. Not sure about the menu options. They don't appear to use either of these routines. ********** 09/09/2008 ********** $00B367 is the routine responsible for reading the text in the menus. A tilemap is constructed in RAM using the font (which is stored in VRAM in its entirety at this point). This is gonna make adding a VWF to this section challenging, since the tiles to display aren't sent to VRAM as they're needed. The text starts at $30000 in the ROM file. ********** 09/10/2008 ********** I've written the VWF code and I'm currently debugging it. The part giving me trouble is combining 2BPP tiles together. The trick is to use the same method I did in the VWF I scrapped for Spider-man: Lethal Foes: OR the first row, AND the second row. I need to rewrite some of the code to handle this, which I'll leave for tomorrow. ********** 09/20/2008 ********** Okay, so I sort of screwed up the VWF when I wrote it. I made the assumption the font was stored one way when in reality it was stored another way. Nothing major to fix, but I need to plan out exactly what I want to do before I start writing code again. I find I save time by writing a simple design. CS 115 FTW, I guess. The font is stored so that the upper-left tile is stored at $xxx0, the upper right at $xx10, the bottom-left at $xx20, and the bottom-right at $xx30. Thus in order to load one complete 16 pixel row of tiles, I need to first load one byte of the upper-left tile and place it in the upper 8 bits of the accumulator. Next I'll need to load one byte of the upper-right into the lower 8 bits of the accumulator. This is gonna get confusing really quick so I need to sit down tomorrow with the code I used for BK3 and map out a flowchart. Fun. ********** 10/03/2008 ********** I managed to fix the last few bugs in the VWF tonight and I got Tom to agree to translate the script. He says he'll have that finished by tomorrow. The next thing to work on is getting the dialogue text to use the new read routine and VWF. This will probably be pretty simple: write another read routine that accesses the VWF and in general acts like the original routine (checks the flags, etc) and call that. At any rate, this will be finished by Halloween. It's been almost two years since my last release. I can't believe I'm gonna be releasing something again. ********** 10/05/2008 ********** Yesterday I fixed the read routines so they all use the VWF code and it works everywhere except in the menus, which are probably gonna be a pain in the ass to fix. I'll look into them next. Right now, I need to figure out what's causing the font to not be sent to VRAM for the menus in the Versus mode. There's a call to the decompression routine I'm missing some where I bet. At any rate, I've got a translated script on my hands now and I want to get this ready for testing by Saturday night if at all possible. TODO: Add the empty "gray" tile to the VWF font somewhere. This is needed for the white spotlights that appear beneath each character's sprite during versus mode. ********** 10/16/2008 ********** I've got all miscellaneous text (mostly menu text) that has hard coded pointers located and dumped. The problem now is getting the VWF in. Ordinarily this wouldn't be a big deal, but since the variables (like character HP in versus mode) is placed *after* the string is read and drawn in the tilemap, this is going to be a pain in the ass. I think the best way to do this is to set aside a maximum number of empty space for each variable field, and have each variable use a fixed width font. Alternatively, I could have the text drawn in RAM and then DMA'd to VRAM as needed. This might cause some lag for the aforementioned HP variable, though. At any rate, this block of text doesn't draw the text in RAM. Instead the font is stored in VRAM in its entirety and only the tilemap is updated. Each string will need to be VWF'd in RAM and then DMA'd to VRAM. The best way to do this will be to use a static tilemap. That way I'll only need to update the relevant tiles in VRAM for the variables. Need to sit down with some paper and draw this out tonight. ------ The names that appear below the character portraits throughout the game are stored in RAM beginnig at $7F1C00 with Goku. The tiles used are different from the rest of the text and are stored before the normal font in VRAM. Need to find where this is in ROM so I can change that. TODO: Dump the names as they appear under the status bar in battle and replace them using Gemini's graphics. ********** 10/22/2008 ********** Still haven't had a chance to work on the menus. I'm not sure I'm gonna make that Halloween release afterall. There's just too much to do and too little time to do it and test it sufficiently. At any rate, I found the character names that appear in battle. They're compressed, too. I gotta find some space in the ROM to stick them into the game uncompressed. Maybe I can overwrite the Japanese tiles *after* they've been decompressed. Might be able to save a headache and space that way. ********** 10/27/2008 ********** Design for the menu text VWF: 1. Initialize variables and clear draw buffers. 2. Read byte of text 3. Check for control codes. 4. If not control code, call VWF routine to draw the character in the buffer. 5. Call tilemap routine if overflow occurred so the tilemap can be updated. 6. Repeat 2-5 until EOS control code is read. 7. DMA tilemap and draw buffer to their correct places in VRAM. To deal with the fields of text that can vary (like HP and Scene Color), I'm going to implement a new control code that will skip a specified number of tiles, reserving them for later use. The tilemap will be updated at the same time, that way the tiles referenced will only need to be "filled in" later. This should work, although it will require the routines that load the variables to DMA the tiles. Hopefully it won't cause any lag. ********** 11/15/2008 ********** I've spent most of the day fixing the bugs that had cropped up in the menu. Mostly it was just changing calls to the decomp routine to the routine to load the uncompressed font. I did figure out the cause of the garbage being displayed as filler on the backgrounds in the menus. BG3 is filled with blank tiles (#$00) at the beginning of each routine, since this is the letter A in the English font, I need to change this. I attempted to change it to #$FF, an unused value, but this didn't work. For some inexplicable reason, that causes the character animations to lag severely in VS mode before the set up screen appears. Even weirder is it only does that when using Vegeta. I need to investigate the cause of this further. I might be better off to just alter my table a little so the space comes at the beginning. ------ Actually, I just did that and it fixed the problem. Weird. Now I can focus on bigger and better things. ********** 11/17/2008 ********** Today has seen an immense amount of progress be made. I've finally got the VWF routine working with the start menu and the versus mode select (CP or 2P), however there's still a few bugs to work out with each of the other instances the routine is called. What I want to work on next is getting the versus mode set up screen working. The problem is that the text is drawn via the VWF routine before the font is unloaded. In other words, when the VWF graphics are DMA'd to VRAM, they're overwritten shortly thereafter by the decompression routine loading the font into VRAM. Simply disabling teh call to the decompression routine isn't enough, as this results in garbage being spewed onto the screen. The options menu does this too, so I suspect the other screens will suffer a similar problem. Although, it seems likely that the problem with the Options menu is caused by substrings not being handled yet. All in all, it looks like *this* will at least be done by Christmas, which is more than I can say for Bare Knuckle 3, which should've been done in time for Halloween or sooner. Useless people. ********** 11/19/2008 ********** I got the garbage issue resolved. The solution I came up with is instead of calling the load_font routine, clear the area in memory used for the font. Then DMA this empty buffer to VRAM to clear out the garbage left from loading the character portraits. Then re-DMA the VWF graphics, which are still in RAM where I drew them, to VRAM. It sounds more complicated than it really is. The important thing is it works. The next problem to tackle is getting the variables VWF'd and displaying correctly. ------ Maximum number of space used for each variable field: KI requires space for 3 numerals. Max value possible: 900 Attack requires space for 2 numerals. Max value possible: 10 Defense requires space for 1 numeral. Max value of 5 COM Level requires space for 1 numeral. Max value of 4 BGM requires space for 10 tiles (16x16), it looks like. ------ Sound - 4 tiles Stage Color - 6 tiles Rush Battle - 3 tiles Blow Back - 3 tiles Effect - 3 tiles; Max value of 119 BGM - 10 tiles ------ I need to work out the amount of space required for the longest string of characters possible. For the three digit numbers, I need 2 16x16 tiles to accomodate the widest possible number: 999. For the two digit ones, I still need 2 16x16 tiles, although the last 8x16 isn't necessary. For one digit numbers, I need 1 16x16 tile to display the widest number: 9. For the substrings, I'm going to set aside at least 10 16x16 tiles for them. That should be more than enough. The first $1000 bytes of VRAM is set aside for the string itself. Each of the variable fields will begin on the second "page". This means each address will be hardcoded and need to be added to the tables I've created for loading the VRAM address and the max number of characters allowed. This also means, I'll have to sit aside enough space in the strings to allow for the substrings and variables to be inserted later without spilling over into the surrounding text. Honestly, this doesn't sound too difficult. My biggest concern was DMA-ing data when the game didn't originally do that. There seems to be a very minor lag when entering and exiting the start menu, though. In other words, when exiting the "VS 2P; VS CP" menu back to the start menu, there's a small lag while the string is drawn. There doesn't appear to be any way to avoid this, unfortunately. I'll look into it more later. My biggest priority now is getting all the variables working again. ---- ----------- VRAM Description ---- ----------- $0 - $1000 String $1000 - $10C0 1P Ki $10C0 - $1180 2P/CP Ki $1180 - $1200 1P Attack $1200 - $1280 2P Attack $1280 - $1300 1P Defense $1380 - $1400 2P Defense $1400 - $1480 COM Level $1480 - $1700 BGM ---- $1700 - $1800 Sound $1800 - $1980 Stage Color $1980 - $1A40 Rush Battle $1A40 - $1B00 Blow Back $1B00 - $1BC0 Effect ---- $1BC0 - $1C00 1P $1C00 - $1C40 2P/CP NOTE: Values above are relative to the address String appears at and are NOT absolute VRAM addresses. ********** 11/24/2008 ********** --- ------- ----------- RAM Tilemap Description --- ------- ----------- $1AC9 #$0144 1P HP $1ACF #$0170 2P/CP HP $1ACB #$01C8 1P attack $1AD1 #$01F4 2P/CP attack $1ACD #$024C 1p defense $1AD3 #$0278 2p/cp defense $1AD5 #$02F8 com level $1AD7 #$1354 BGM ------ This going to be very brief because I'm tired and I've been staring at this game all day. I've managed to get all of the variable fields displaying now, except for the 1P and 2P/CP fields, which are drawn separately. There's also a bug that occurs when switching BGM titles. I haven't looked into this, so I'm not sure what the problem is. Most likely it's nothing major. The important thing is everything is working. Each field is only updated (i.e. tiles redrawn and sent to VRAM) when the value has changed. Otherwise there is an obscene amount of lag which is detectable in the sprite animations. Next on the list of things to do is fix the BGM bug and get the Options menu working. Then I'll move on to either the Tournament mode or Krillin's continue screen. I'd really like to get this stuff finished up tonight so I can concentrate on more important things and have something to show off for Thanksgiving. It won't be a patch release, but a video of the first few mintues of gameplay would be cool. ------ Also, I need to find where the values are reset to default after a battle has taken place. ------ The cause of garbage being displayed sometimes instead of the BGM title is because the game uses $7E0006 in that part for something. I was using it for my !char variable. Once I changed that, it fixed the problem. ********** 12/15/2008 ********** Another brief update. I haven't really worked on this any since the last update, but fortunately I was smart enough to include the code responsible for drawing the 1 and 2/C in my source code for future reference. Adding these should simply be a matter of adding the size and location (where in VRAM to draw them) to the various tables. I think I'll still need to write some code to call all of the pertinent routines, since it's not like the numerals or the BGM titles. I also threw together the design for the center control code, which follows: --------------------------- Center control code design: --------------------------- -Read until control code is read. -Add up the width of each character. -Subtract this value from the maximum width of the line. -Divide this number by two to account for blank space on both sides of the text. -Subtract 8 pixels from this value and increment !ram_index for every 8 pixels. -Set !shift to the remainder. -Exit. I'll need to add this before release so the start menu is centered correctly, but this isn't that important. As for an actual release date...it probably won't be Christmas. I just haven't felt up to working on anything any more. ********** 12/22/2008 ********** I've spent a few hours today working on this. The code to draw the 1 and 2/C has been written and works perfectly. The only thing left to do on the VS menu is to format the text, but I'm waiting on the center control code to be written, which brings me to my next set of problems. The code for the center control code has been written and works, except there seems to be some issue with the menus. I suspect it's causing a conflict with the tilemap some where. I'll look into this further after I test the center control code in the story text. For now I'm gonna step away from this and tackle something else. Sick of debugging this stupid control code. ********** 01/05/2009 ********** This is gonna be quick because I have to leave for work in 5 minutes. Over the past week or so I've managed to fix the center code and even get the continue screen text and character select screen in the tournament mode working. The only thing left are the battle announcement and victory screens in the tournament mode. Also, there's a small bug on the VS Set Up screen. It looks like there's a problem with the tiles for one line ending with the tiles for the beginning of the following line. It's a tilemap problem that I need to look into more before I can say what the cause is. I'd really like to get this finished up before the 14th when classes go back. It'd be nice to have at least one thing to show for my semester off. ********** 01/06/2009 ********** Still need to find and change the code that resets character attributes after a VS match has ended. Also, the Win, Loss, Tie screen needs to be hacked. Damn. ------ Character stats are now redrawn after the match is over. Next up is the W/L/T screen. ********** 01/08/2009 ********** Looking over the past few entries I can say that I fixed the tilemap issue with the VS set up screen. Just needed to up the max chars per line a bit. Found the code that handles reseting the attributes after a VS match has ended. The values and the cursor location stay the same as before, but now the temp_array is cleared to ensure the variables are drawn at least once. I haven't worked much more on the W/L/T other than to come up with an idea for it. Instead of having kanji after each value as the Japanese game does, I'm going to have "Wins", "Losses" and "Draws" appear in the center of the screen between the two player's stats. It should look much cleaner that way. The problem that's been driving me crazy the past few days is the obscene amount of lag present when entering and exiting the Option menu. Fortunately I think I've come up with a solution. Instead of relying on the VWF to draw the menu options themselves (Sound, Stage Color, etc), I'll store them pre-drawn in ROM somewhere and then DMA them to VRAM. That way only the variable fields of text are being drawn on the fly. I need about $1000 bytes of space to store the uncompressed image, and it looks like I have just that (and then some) starting at $C000 in the ROM file ($1C000 in SNES memory). I'll play with this idea more when I get home from work tonight. Note: Still need to add the spotlight tile for the VS mode set up screen. ------ It worked! There's no lag at all now when entering and exiting the option menu. The only problem with this method is I'll need to let the VWF routine draw the text out for me, grab a savestate, rip the data from the savestate, stick it in a file and reassemble the rom everytime I make a change to the option menu. Fortunately, it's the option menu. I'm not gonna be changing it very much. ********** 06/14/2009 ********** I fixed the bug in the options menu that caused the game to freeze up when trying to change the Rush Battle and Blow Back settings to Off. Turns out my test script was overwriting the pointer and not the original string. Took 5 months to figure that out. I'm smart. Heh. ********** 06/15/2009 ********** Played around with the options menu a little more to get all the dots in that need to be there, and I think I'm gonna hold of doing that until later. I'll have to draw the dots in options.bin and then redo options_tmap.bin by hand to make everything look right. Simple stuff, but I don't feel like doing grunt work right now. Think I'll take a look at the continue screen and see what I can do there. ------ Ended up taking a look at the W/L/D screen in the versus mode. It doesn't look like changing it to how I want will be that difficult. Draw up the 1P, 2P, Win, Lose, Draw strings and DMA them from ROM into VRAM, so I don't have to call the VWF routine and cause lag. Then just update the relevant portions of the tilemap before the values are drawn. Simple. ------ Okay, I cleaned up the routine that DMA'd the options screen so that it's now a general use DMA routine for uncompressed data. Also threw together the routines to transfer the W/L/D graphics to VRAM. It works perfectly. Now I just gotta work on the tilemap. ------ Took a better look at the routine so I could map out where each variable is stored, and the only thing I'll have to do is update the tilemap that's in RAM. This is going to be really simple. I just have to determine where in the tilemap I want to draw each string. I also need to throw together a routine that will accept the tilemap ID number, the length of the string (win, lose, etc) and where in the tilemap to put it. That should be fairly straightforward but I'll do that tomorrow. ********** 07/18/2009 ********** Over the past few days I've been working on the W/L/D screen. The only real problem I had was getting the variables to display correctly, but that was only because I didn't remember how the code I wrote for the VS set up screen worked. Once I got that figured out and added the various bits of information to the tables for the game, it worked perfectly. I think the next thing I'm gonna look into is decompressing the character name graphics and getting someone to fix English ones. ********** 07/23/2009 ********** I spent the past three hours or so adding the name graphics that Gemini sent me a while back. I still haven't touched the name graphics under the portraits, but the graphics during fights are inserted. The only thing left to do there is change the unlimited time kanji to an infinity sign and the fighting section will be done. Side note: First time in a while that hacking has actually made me feel better. I just put on some music and focused on that while I did all the boring grunt work. Surprisingly relaxing. ********** 07/24/2009 ********** I discovered the reason why the portrait names are white with no shadows: there isn't enough room left in the palette to hold a shadow color. This is gonna make adding the names in a pain, since I can't use the same font as the VWF to draw them. Gonna have to get someone to make me some graphics. Great. I wonder how hard it would be to hack the palette. Hmm. ------ Turns out changing the palette used isn't that hard. Instead of the tilemap entry being 0AXX, I just have to change it to 06XX so that palette #1 instead of palette #2 is used. I've got to recolor the tiles, but I have to do that anyway. ------ Trying to determine how much space I need for the graphics. The numbers below indicate how many tiles wide each is. Double the value given to determine the number of 8x8 tiles needed. Goku 5 Vegeta 6 Gohan 5 Gotenks 6 Vegetto 6 Piccolo 6 Freeza 6 Cell 3 Mister Buu 8 Buu 3 54 ------ And three and a half hours later I have the graphics inserted and tilemap for the W/L/D screen inserted. The new problem is the character select screen. See, palette #1 doesn't have all the colors I need. I'm gonna look into adding the colors so I don't have to change anything. ********** 07/25/2009 ********** I got the palette issue resolved last night. What I ended up doing is changing the code so the same palette is loaded into the same position in the palette table every where it's used. That means all of the character select screen and versus mode set up and battle result screens are finished. I still need to throw together an infinity symbol for battles and add the spotlight tiles back in, but that's nothing major. What I'm gonna work on tonight is finishing those few things up and getting the options menu finished, I think. That'll leave the tournament mode as the only thing left to hack. ------ I'm an idiot. The kanji actually was "ki". Wasted 10 minutes drawing the infinity symbol for nothing. ********** 07/30/2009 ********** So the only thing left to do really is fix the bugs in the tournament mode. I fixed the issue with the garbage being displayed the other day. Turns out the Y register was being corrupted along the way. Now I've got another problem. The Match X YP vs ZP string is redrawn every frame, since that means calling the VWF and massive lag, I've got the code that handles redrawing disabled, which is fine except it messes up the variables. Instead of being drawn where I want them to be in VRAM, they're drawn where the Match string is drawn, thus overwriting it. Not sure what the problem is. ********** 08/03/2009 ********** I've spent the past two hours trying to figure out what the deal is with the tournament mode. For some reason the 2P graphics are shown before everything else, and when the refresh occurs, the *other* graphics are shown, but the 2P graphics aren't. The tiles are there in VRAM at that point but they're not on-screen. This is really annoying and frustrating. ********** 08/04/2009 ********** The reason the 2P graphics were being displayed is because they were the last thing in the draw buffer. When dma_font was called from within str_refresh_set_up, they were being sent to VRAM. After a little sorting, I got it fixed. Now the variables are drawn before the announcement string, that way the Match info is the last thing left in the draw buffer, so when str_refresh_set_up is called, the string is just sent to VRAM again. That means the fade-in works and everything perfectly. The problem now is getting the variables to show up in the tilemap. This should hopefully be a lot easier to fix. ------ Okay, so that wasn't so hard to fix. It's a little hacky the way I did it, though. I threw together a routine to add the variables back into the tilemap after the string has been drawn. It works. Not the most elegant of solutions, but who cares? It works. I've long since stopped caring about writing elegant code for this game. I need to code a pixel space control code so I can get everything to line up correctly. After that I need to run through the tournament mode and make sure all the XPs work. ------ That was easy. Got the pixel indent code up and running in less than 15 minutes. Need to run through and check the other cases now. ------ It works fine for everything. Now I need to fix the Finals Announcement string. I'm sure that's gonna be an unholy pain in the ass. Ugh. I'll deal with it tomorrow after work. For now I'm content. I fixed the bugs and centered the text. This string is final. ------ So I can't sleep. Actually, I could, it's just that I'm so close that I want to keep going. I've got the Final Match announcement set up and working correctly. The only issue now is getting the formatting straightened out. See, this string uses the same code as the previous one to determine where the variables go, so they show up in the same place. That's fine and dandy for the Japanese version, but I need them to appear elsewhere in the translation. I think I'll throw together something to load separate tilemap locations for this string so it'll look nice. I still need to figure something out to do with the large victory kanji. ------ Threw together a copy of the tmap fix routine and got the Final Match announcement working. Yay. Last thing is the victory message. ********** 08/07/2009 ********** I finished up the tournament mode yesterday, and after a few hours of investigating, I've fixed the code to set up the max chars per line variable in code, rather than relying upon a control code. Much cleaner this way. I've handed the script off to DarknessSavior to work on. The only thing left for me to do is finalize the Options menu, translate the copyright info on the title screen and add that damn spotlight back to the tiles in versus mode. It looks like I might get this released this year afterall. Woo. ********** 08/22/2009 ********** Finally fixed the spotlight. Got a few days left before class starts, so I'm gonna try to get the rest of this done. That way I can just insert the script and start testing without needing to do any more hacking. Hopefully. ********** 11/14/2009 ********** Line widths for copyright data: 1st: 136 pixels 17 tiles (8x16) 2nd: 120 pixels 15 tiles 3rd: 112 pixels 14 tiles Copyright: 16 pixels 2 tiles I posted up on RHDN about getting someone to create the graphics for this. The only thing left to work on is the options menu, which shouldn't be too difficult. It's really just a matter of remembering how the game works and how my code works. I've got two hours left before work, so I should get something done. I hope. ------ New idea for how to handle the tiles in the options menu: Rather than draw the entirety of the menu (Sound.....Stage Color.....etc), draw only the option title (Sound, Stage Color, etc) and include one 16x16 tile of the repeating string of "...."s. Then construct the tilemap by hand, which is already being done. Simple. ------ For the BGM, I'm going to have to add a check for the ID # code thing and branch off to a new routine that's similar to the BGM routine used by the versus mode. For the Effects, I'll have to do something similar as above, but build a copy of the variable text routine used by the versus mode for the KI stats and such. This shouldn't be too difficult. The hard part will be making sure all the variables are set up correctly before the code branches and they're in the correct shape upon return. I need to do something to offset the overlap of "..."s for the Rush Battle and Blow Back options. I can probably get away with doing something clever with the graphics, rather than implementing some elaborate shifting in code. ********** 11/26/2009 ********** Today is Thanksgiving and hacking is officially finished. The BGM and Effect options were actually much easier to deal with than I thought they would be. The Effect option uses the same code the Ki and such in the VS mode use. The BGM didn't require any special code. I just needed to play with the tile ID numbers a little bit to get it to display correctly. Hehe. I also got the graphics for the copyright screen finished thanks to Moulinoski or however he spells it. Now I'm just waiting on the script, which DS had better finish with soon or I'll kill him. I'm gonna try to find something else to take my mind off my life for the rest of the day now. If my connection starts working again, I'll post an update on the site. ********** 05/08/2010 ********** Turns out the ending text that appears after you beat the game used a different routine than the rest of the game and that needed to be hacked. It took about 3 hours of comparing this new routine with the similar dialogue routine to come up with a working solution. Now that that's out of the way, the only thing left to work on is adding a VWF to the Credits screen. This should be interesting because the text is outlined with gold and blue. Maintaining that in the VWF will certainly be an interesting challenge, but first I have to find the credits text. ------ I need to modify my table a little bit to properly dump the credits, but it's a really simple encoding scheme used to dictate what color to use. The yellow outlined text is the same as any where else in the game. The high bit of the blue text however is set. Since this routine simply reads text and writes to the tilemap, it's gonna require a little finesse to VWF this thing and work in the colored text. I need to sit down tomorrow and draw up an approach for handling this. The VWF itself will be simple since it's the same situation as the narration in the story mode, which was cake to handle. The colored outline is gonna be a little trickier to handle. I need to examine my code and see if there's anyway to add a color check. I'm thinking throw in a control code to set a flag that is checked in the tilemap routine and if the flag is set, do the necessary ORing to switch the color. ------ I got the code written and added a flag. Now I just gotta add code to initialize things. I think I need to examine the narration code and see how that works again. ********** 05/09/2010 ********** Further investigation shows that this will have to be coded like the variable text to a certain extent. The narration actually drew the string in a buffer in RAM and DMA'd it to VRAM. The credits don't do that. The alphabet stays in VRAM, so the tilemap is the only thing that needs to be updated. I have plenty of space in VRAM to draw the strings fortunately. Just overwrite the font at $3000 and it should be okay. This is gonna be a pain in the ass, but not nearly as big a pain as the variable screens were. With this I can just initialize the variables at the beginning of the string and then run through everything. I need to look into how the variable screens DMA'd the drawn string to VRAM. That's the only part that's gonna give me trouble, and that's only because I don't remember how I did it in the first place. My old code is starting to look really unfamiliar to me. This is why you don't go 6 months without working on things. ------------------------ Variables to initialize: ------------------------ !tilemap_index !tmap_index & !ram_index (set to zero) !chars_left & !max_chars !tile_id ------ Honestly, I think it'll be easier to add the relevant information to the tables for the variable text and let the other code handle things. The only problem I think is the draw buffer at $7e4000 won't be large enough to hold an entire string's worth of text. So I'll need to DMA stuff somewhere, I think. Actually, it uses the same code as the options menu. So just hook into the option_substring_set_up routien and let it go from there. Should be cake. Just have to add the check for the new [COLOR] control code. Correction, it's the menu_text routine I want not the options routine. Stupid messy code. ------ Got the credits hooked into the menu_text routine correctly and everything is working great. Even the color control code. The only problem to address is allowing the strings to be more than 5 lines. In other words, add code for the DMA control code to function properly. None of the other instances where this code is used had more than 5 lines of text to display at once so it wasn't a problem. Unfortunately most of the strings in the credits are longer than 5 lines. This shouldn't be too hard to pull off. Clear the draw buffer, the vwf buffer and update the variables used to address vram. Gonna work on adding the colored letters to the dump table and dumping the credits properly for re-insertion.