Originally posted by FakescaperI dunno why you'd need to make more hijacks, I thought you'd only need to make more defines for stuff. Although are the boxes really just for people to adjust colors and stuff ingame? Shouldn't it already be preset stuff (probably on a per level basis or something). Either way nice work.
Well, let me explain the system I used in more detail: I do have default values to setup in my patch. You can use default values for about everything there is. As long as you don't touch anything those default values will be loaded. So without needing any custom sprites, custom blocks etc. you can display textboxes with the preset default values. If, however, you DO want to make it so that you can change the textbox settings ingame, then that is possible by simply modifying some RAM addresse, as the boxes seen in the video do. It doesn't even take any complicated ASM. It's literally just:
lda #$XX
sta $XXXXXX
One good example for that is Secret of Mana. You had a menu where you could customize textbox frame, background and color. That's also where I got the idea from and I liked it. This is also what I meant by "hijacks". I could make those things easily customizable with a patch. Like, I could make a patch that changes the pause screen so that you could change those settings on it. But that would pretty much FORCE any user of this patch to use this option and, well, it would (defenitly) mean more hijacks. Anyone who really wants that option in the game could do it himself or ask someone else to do it for him. Same with a SRAM routine. I didn't include a SRAM routine for the textbox settings. Doing so would mean more hijacks. If, however, someone really needed the settings of his dialogues to be saved to SRAM he could simply make a SRAM routine himself. If I did it that once again would mean more hijacking points. And those functions are really just "extra" functions, not mandatory for the actual dialogues. I wanted to include only really mandatory stuff to keep compatibility as high as possible.
As for the "on level basis" idea: I think it wouldn't be too great for this patch. Just imagine you want to use multiple NPCs in the same level. You would be forced to use the exact same settings for each of them. However, since any NPC needs to be an individual sprite anyways it doesn't hurt to include any ASM code you need in the sprite itself rather then having it not changable, does it? ;)
Anyways thanks for pointing your ideas out to me. I'm thankful for any critics I get on my work. I'll put another video up those days.
Originally posted by KilloZapitMy main question for this is in regards to the script format. VWF Tool had a very impressive script format with a lot of options that was somewhat expendable in theory, if kind of annoying to do in practice. How does the script format in this work? I also wonder if it's better to do external compiled scripts like VWF Tool, or internally compiled scripts using xkas's built in tables and macros for special commands.
Well, that's why I said I'd love to make a GUI for this. Right now it's so that you have to enter the complete messsages as HEX or (depending on the font file you use) ASCII characters. $00 to $EE are regular characters, while $EF to $FF are special characters. However, you can still have up to $FF characters in a font file and use all of them since one of my special commands - man, I'm a genius! - is "draw character $XX". Therefore you can easily draw any character from $00 to $FF by just using that special command or from $0000 to $FFFF if in 16-Bit-Mode, which is also supported (but not tested much so far). Anyways, detailed information on this will be given whenever I release something.
Originally posted by KilloZapitI never liked SOM's text boxes in that regard anyway. The background patterns on the text were rather silly, and I always just turned them off if I could
The backgrounds patterns are easily editable, so it's no problem using a background without any pattern. However, you can only use one color for the background. At least I've only designed it for one color. Don't know if it would work corretly for more then one.
Originally posted by KilloZapitAnyway, since most layer 3 stuff just uses the lower half of the tile map (as to not mess with the status bar) you could effectively split it into two vertically mirrored tilemaps and set the start address via irq. You could further split the upper half into two single screen maps and use one for statusbar/layer 3 letters and one for layer 2 if you want. Also I wonder if you can just turn HDMA off via IRQ and on again...
That's not possible due to my patch overwriting layer 3 graphics in VRAM completely. The space from the original graphics + the first three tilemaps are used for the actual graphics, while only the last tilemap is actually used as a tilemap. That's also why the Status Bar is always disabled during dialogues. You don't want to see messed up graphics in it, do you?
[EDIT]
Here's a picture of VRAM with a screen-sized textbox full of Ws[/EDIT]
Originally posted by KilloZapitAnyway smw's IRQ is sorta picky and buggy which is why it messes up in snes9x and bsnes if you make small changes... plus you effectively need to watch how much stuff you do per scanline in it.3
That is true cause I actually hijacked SMW's IRQ in my patch. What I did is expanding the scanline count during dialogues and altering layer 3 position of IRQ (to show only the last tilemap). And yeah, when I used $DD as a canline count it showed absolutely nothing in SNES9X and BSNES while it worked fine in ZSNES. Lowered that number by one and it worked fine in all three emulators.