For an explanation why the shift.
OH AND ANOTHER THING BEFORE YOU START: although your game may store its original font in 2bpp or more, it is FAR easier to work on your VWF in 1bpp. Use a 1bpp font as your working font, and if the game is using 2 or 4bpp, write a function to up-convert your finished VWF tile as you load it into VRAM. (while I can't remember the converstions offhand, I recall it's usually something simple like writing each byte twice or adding a 00/FF before/after every byte. You can probably tell if you use WindHex and play around in the tile editor by drawing a few test tiles and then compare the resultant hex)
If you have to add a shadow that's a bit trickier but still far easier to do in the transfer phase.
You need variables: PixelOffset to store how displaced the current character is from the edge of the tile, and LetterWidth to store the width of the current character.
You will probably also need a scratch buffer at least two maximum width characters wide (your workspace for a VWF tile), as well as another buffer 2 characters wide to hold a single character for shifting. (though if you get more experienced at code you may be able to do clever coding to omit that. Though with only three registers on the SNES compared to 8 data registers on the Genesis, it may not be as feasible on SNES for that optimization)
Say you have the word "Abra".
Since it's the first letter, PixelOffset is 0 because you are storing at the (left) edge of the tile.
Say "A" is 7 pixels wide.
At this point you can just copy the A to your scratch buffer because you don't need any shifting. Note that since you started on pixel 0 of the tile and your character is 7 pixels, you have used (0+7) pixels width of your buffer, your PixelOffset is 7.
Next character. Say the "b" is 5 pixels.
Since the previous character was 7 pixels, you need to read the "b" from the font and then shift it 7 pixels right. Make one buffer simply that "b" shifted right 7. You need to shift it 7 because you're placing it to the right of the "A" that was 7 pixels wide.
Now merge (the ORs) that shifted "b" tile with the previous "A". So now you'll have a tile that says "Ab". Again, since you started the "b" on pixel column 7 of the buffer and the "b" was 5 pixels, you have used (7+5 or 12) pixels width of the buffer. Your PixelOffset is 12.
You'll need to copy that tile into VRAM, or into a canvas holding the entire message window. However your game is managing it.
Once that "Ab" tile has been copied, you can update your scratchpad. Maybe you can update it right away, maybe you'll have to wait until your VWF routine begins to process the next letter. Depends on how the game is coded.
But, say your font had a maximum with of 8 pixels per character. That means the first tile, with the "A" and some of the "b", has exceeded the 8-pixel tile size and thus the first 8-pixel tile is no longer needed (since you already transferred it to the window canvas. You should the clear out that left side of the tile, by copying the right side data to the left and then replacing the right side data with empty space. (so you'll have room to draw the next character) Since you cleared out 8 columns of your pixel buffer, you should reduce your PixelOffset by 8, from 12 to 4. Since you will then start drawing on column 4 of the updated scratchpad. Likewise, you will shift your next character "r" 4 pixels right before ORing it into your VWF tile.
If your "r" is 6 pixels, that'll fill up to column 10 (4+6) in the buffer and again you'll need to flush out the filled tile before the "a".
