Language…
19 users online: anonimzwx, Aurel509, buggy789, codfish1002, cohimbra, Dennsen86,  Doctor No, Fozymandias, Gamet2004, Green, Green Jerry, jirok1, LightAligns, Metal-Yoshi94, Mischievous Marc, Raychu2021, RicardoDeMelo, RZRider, sinseiga - Guests: 278 - Bots: 325
Users: 64,795 (2,375 active)
Latest user: mathew

VWF Dialogues v1.4

Patch

Originally posted by RPG Hacker
Originally posted by imamelia
I assume the VWF font uses the sprite layer, right?


Huh? No! xD
I thought I had made it pretty obvious that this patch only uses layer 3.

Oh, yeah...

Hm. I see what you mean about the sprite layer not being an option, though. I'll just have the same problems with Layer 3 backgrounds that I would with the original message boxes, I guess.

Originally posted by RPG Hacker
Originally posted by imamelia
Does the patch replace ALL the original messages, or just the intro and switch palace ones?


It doesn't really replace any messages. Instead it hijacks the routine that calls a message. Therefore anything that used a level message before (Switch Pallaces, Intro, Yoshi's House, speakers...) now uses my VWF system.


I see.

Originally posted by RPG Hacker
Originally posted by imamelia
Is it still possible to use the original Layer 3 messages?


In theory yes, but not out of the box. As I just said my patch overwrites the actual message calling. If you'd try to call one of the original messages it would call a VWF message instead. However, by simply commenting out a single hijack in my patch before applying it to your ROM it is possible to keep the original message calling. In that case it would still be possible to use the VWF system in combination with custom sprites, custom blocks etc.

Well, I guess if the VWF system uses Layer 3 anyway, there wouldn't really be much point in using the original messages. You did say that the VWF messages use a different RAM address and can go up to FFFF?

Originally posted by RPG Hacker
Originally posted by imamelia
And are you planning to release this at C3?


See my custom title. :D

"Phoenix from the Ashes"? So the project is dead now, but it will be reborn at C3? *runs*

----------------

I'm working on a hack! Check it out here. Progress: 64/95 levels.
Originally posted by imamelia
Hm. I see what you mean about the sprite layer not being an option, though. I'll just have the same problems with Layer 3 backgrounds that I would with the original message boxes, I guess.


I'm curious what problems you're talking about. If it's related to Layer 3 disappearing I can say my patch partially solves that. Layer 3 DOES get invisible during dialogues, but it always gets backed up to it's original state afterwards.

Originally posted by "imamelia"
Originally posted by RPG Hacker
In theory yes, but not out of the box. As I just said my patch overwrites the actual message calling. If you'd try to call one of the original messages it would call a VWF message instead. However, by simply commenting out a single hijack in my patch before applying it to your ROM it is possible to keep the original message calling. In that case it would still be possible to use the VWF system in combination with custom sprites, custom blocks etc.

Well, I guess if the VWF system uses Layer 3 anyway, there wouldn't really be much point in using the original messages.


Exactly my point.

Originally posted by "imamelia"
You did say that the VWF messages use a different RAM address and can go up to FFFF?


Yeah. However, the text doesn't get compressed or anything.Therefore lots of text could take multiple banks of ROM space.

Originally posted by imamelia
"Phoenix from the Ashes"? So the project is dead now, but it will be reborn at C3? *runs*


Quite the philosopher, huh? xD
I like that.
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
Originally posted by RPG Hacker
Originally posted by "imamelia"
You did say that the VWF messages use a different RAM address and can go up to FFFF?


Yeah. However, the text doesn't get compressed or anything.Therefore lots of text could take multiple banks of ROM space.

How can text get so big?
...Are you making a converter tool in C++ or something and storing uncompressed layer 3 data in the ROM or something weird like that?
<blm> zsnes users are the flatearthers of emulation
No, just the text. What I meant to say was "If you have a lot of text". Just think about it. If you had $FFFF messages that each only consissted of one character, let's say the termination byte $FF, that would still fill two whole banks. Now consider that dialogues usually have a lot more than just one character. :P

Of course it is very unlikely for a game to have $FFFF different messages, especially for a Mario hack. Still this system is made specifically for RPG-styled hacks, which can get quite a lot of text. $8000 characters of text in a game doesn't sound like all that much. :P

I mean for that reason many commercial SNES games already used text compression. The only example I can think of right now is Star Ocean, which used Huffman compression. I know this because a friend once asked me if I knew anything about this compression, since he wanted to translate the game.

Anyways, to make it short: Text doesn't get compressed with my tool, therefore having a lot of text might mean filling multiple banks just with text.
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
Yeah...writing messages in .txt files would give you an idea of just how much space might be necessary. I'm actually debating whether I should use the patch in combination with Romi's VWF tool or just use the patch by itself. Most of my hacks will have a sizable amount of storyline. Actually, though, RPG Hacker, that begs another question: Are the pointers to the text data 24-bit? If not, the text couldn't exceed one bank (well, without doing something like changing the data bank), but if so, you could theoretically insert text into the ROM separately from the main patch and change the pointers in the patch to point to the other text. By the way, were you going to make a tool for converting text to direct hex data? And if so, will it be possible to utilize some commands as direct hex data anyway (kind of like how in Addmusic, pXX,YY is the common notation for vibrato, but you can get the same effect with $DE $XX $YY $ZZ) if you wanted to?

----------------

I'm working on a hack! Check it out here. Progress: 64/95 levels.
Originally posted by imamelia
Yeah...writing messages in .txt files would give you an idea of just how much space might be necessary. I'm actually debating whether I should use the patch in combination with Romi's VWF tool or just use the patch by itself. Most of my hacks will have a sizable amount of storyline. Actually, though, RPG Hacker, that begs another question: Are the pointers to the text data 24-bit?


Yeah, I thought about that and made them 24-Bit. This also makes it possible to read messages from RAM, which can be useful in some cases. I mentioned this before somewhere in this thread.

Originally posted by imamelia
By the way, were you going to make a tool for converting text to direct hex data?


I was going to, yes (I think I mentioned this in my opening post or in the video description). The question is how doable this is for me. The only programming language I know is Pascal. While this might be fair enough for this task (I'm not going to learn any new language too soon) I have no experience with writing my own parsers so far, which would be required to read and display the text files properly.

Originally posted by imamelia
And if so, will it be possible to utilize some commands as direct hex data anyway (kind of like how in Addmusic, pXX,YY is the common notation for vibrato, but you can get the same effect with $DE $XX $YY $ZZ) if you wanted to?


I don't know if I'll include that in the actual GUI application, but it is possible by simply writing stuff into the text file that contains the actual text.
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
I'm hoping and praying that the message above your avatar means this patch is done. ;)
It's a little teaser and means "I'm coming along nicely and will make it for C3 if nothing unexpected happens".

EDIT:
Super Metroid, btw.
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!

Yaaaaay!!

Can't wait for C3! This is one of the things I've been waiting for to move forward with developing my hack.

EDIT:
Anchorman, btw.
Even when this comes out, I think I might stick with the VWF Font tool. I know how to fully implement it's uses now and this seems like it is merely a message box replacement, but all in all, this is a very cool feature you have made and I may use it in Hunter's Revenge 2 Recharged.
Your layout has been removed.
I actually prefer that some people stick to Romi's VWF tool, anyways. It adds variation to the scene. Also my tool will be harder to use, especially when it releases. I won't be able to make a text converter or something like that too soon. At first you'll have to enter text manually, which sure will make it a bit harder to use. However, I'll try to find good replacements for this as soon as possible.
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
I've been giddy over this video ever since I saw it a few weeks back. I hope I can implement this in my hack! :D
"We knew the world would not be the same... Few people laughed.. few people cried.. most people were silent. I remembered the line from the Hindu scripture, the Bhagavad-Gita... Vishnu is trying to persuade the Prince that he should do his duty, and to impress him takes on his multi-armed form and says, "Now I am become Death, the destroyer of worlds. I suppose we all thought that, one way or another."
Continuing C3-Discussion here.

First of all: Thanks for all your positive comments, videos and questions you posted in the C3 thread. Thank you! You people made all the work worth it! :)

Next to answer some left-over questions:

Originally posted by "Lynnes"
The next feature you should add is being able to add 32x32 character portraits to the side of the dialog. You can upload them by using sprite graphics so there isn't any pallete limitations.


A feature for displaying layer 3 graphics freely is already planned (SolidSnake suggested that). However, using sprites is not an option for multiple reasons. First of all: Unlike in Romi's Cutscene Tool this one is running inside a level, so the are sprites displayed while dialogues are running. Therefore, OAM slots are not available freely. Secondly: There is no way to display the sprites above the text box without some annoying game modification. There is no easy setup to make only certain sprites go in front of layer 3 and all other sprites behind it. But I guess only layer 3 graphics will be fine for the beginning.

Originally posted by "mszegedy"
Wait, so I can use this without glitching up my Layer 3 BG?


Whatever you define as "glitching up". Basically, yes. Layer 3 backgrounds won't be harmed, but for the time of displaying the text box the layer 3 background will be invisible. It will reappear after that.

Originally posted by "imamelia"
Um...do we need a specific version of xkas to use this?


I recommend v0.06

Originally posted by "imamelia"
Also, do you think using special character $EB to display sprite tiles would be worth adding?


See above. Layer 3: Likely yes. Sprites: Rather no.
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
Originally posted by RPG Hacker
Continuing C3-Discussion here.

First of all: Thanks for all your positive comments, videos and questions you posted in the C3 thread. Thank you! You people made all the work worth it! :)

Well, I'm glad. Your work was certainly appreciated, it seems...something this awesome and useful doesn't come along often.

Originally posted by RPG Hacker
Whatever you define as "glitching up". Basically, yes. Layer 3 backgrounds won't be harmed, but for the time of displaying the text box the layer 3 background will be invisible. It will reappear after that.

I assume that any priority and interaction settings of Layer 3 will also be restored?

Originally posted by RPG Hacker
I recommend v0.06

Yeah, I don't know what I had (it said 0.06...), but it wouldn't work for me, so I tried redownloading xkas, and it worked just fine. You don't suppose Romi's version of 0.06 would affect anything?

Originally posted by RPG Hacker
See above. Layer 3: Likely yes. Sprites: Rather no.

Okay. I can still write to OAM using the $F1 command anyway.

By the way, as soon as GEMS is out, I'm going to make a version of the Info Box and Display Message 1 sprite that can be used with this patch and use two extra bytes to determine which message to play. I also have a question...is there a good way to display VWF text in a level mode other than 14? For example, I hijacked the Mario Start! routine to show my own text, but it's not variable-width. It would look better in a variable-width font, though (think of the YI stage intros).

----------------

I'm working on a hack! Check it out here. Progress: 64/95 levels.
This could really spice up those pies I've been making.
Originally posted by imamelia
I assume that any priority and interaction settings of Layer 3 will also be restored?


Yeah, though "restored" isn't the right term here. Let's rather say "aren't even affected". What I do in my patch is disable IRQ and then use NMI for my dialogues. Since I have to move the Status Bar I have to do this anyways. However, this also makes it possible to change layer 3 settings without affecting the level at all. It's pretty useful.

Originally posted by imamelia
You don't suppose Romi's version of 0.06 would affect anything?


I don't know. Maybe... After all, I'm using an undocumented xkas v0.06 feature for the 8-Bit-/16-Bit-Mode differences and a few optional hijacks. I'm abusing the repeat command for this. It is likely that in his version, Romi "fixed" what was never meant to be used in regular code.

Originally posted by imamelia
I can still write to OAM using the $F1 command anyway.


Yeah, with a bit of ASM knowledge you should be fine.

Originally posted by imamelia
By the way, as soon as GEMS is out, I'm going to make a version of the Info Box and Display Message 1 sprite that can be used with this patch and use two extra bytes to determine which message to play.


Cool! Right now it is already possible to use any sprite or block that affects $7E1426 together with my patch if you enable the message box hijack. You'll have the same restrictions as the old text box, though (that means two messages per translevel and stuff like that).

Originally posted by imamelia
I also have a question...is there a good way to display VWF text in a level mode other than 14? For example, I hijacked the Mario Start! routine to show my own text, but it's not variable-width. It would look better in a variable-width font, though (think of the YI stage intros).


Hmm... My VWF system hijacks somewhere around the Status Bar DMA code. Therefore it only works in places where there is a Status Bar. I assume what you could if you have some DMA and VRAM experience is use the VWF Generation Routine from my patch (detailed in the Readme) to generate some VWF text in RAM and then upload it yourself. However, I don't really know if this will work on the "Mario Start!" screen. I think by default the game disables any layer on this screen except for the sprite layer. Therefore layer 3 wouldn't even show up. Oh well, I think sprites are already a decent options for this, anyways, since you can set them by pixel instead of just by tile. Therfore - if it isn't too much text - you can easily use spriets for VWF-like text as well.
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
This is great, you are...a gift from the SMW gods. I can't wait until you release upgrades to this! Like the GUI (as it mentions in your Readme =P).
Hey you!
Check out my SMW Blog!

Ok, maybe a bit dead


Also, Visit my Youtube Page!
ASMBrad_Youtube


Depth in Detail:


WLC Entry:

Play?
This is where you would read the first line of text of my signature, but it is currently pointless.

Projects:
- Serious thing kinda happening.
- on hold for some time :|
Two suggestions:
1. Use a synchronized pair of frame counters, one in RAM and one in SRAM. If a desync is detected, kill the current message.
2. Provide some method of freezing only Mario, while leaving sprites running.
Originally posted by JVyrn
1. Use a synchronized pair of frame counters, one in RAM and one in SRAM. If a desync is detected, kill the current message.


Huh? What do you mean by "desync"? How CAN it even desync? I don't get it and never had it happen. On the SNES, RAM and SRAM are basically the same thing, anyways. The only difference is that SRAM is on then cartridge and isn't cleared when you start the SNES.

Originally posted by JVyrn
2. Provide some method of freezing only Mario, while leaving sprites running.


Yeah, I was thinking about doing this already. I'll will do that for the next version.
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
It will desync when and only when the player loads a savestate.

Patch