Language…
10 users online: Aeon, dacin, DashGamer, DixyNL, drkrdnk, GRIMMKIN, JezJitzu, Nemesis1407,  Segment1Zone2, toady - Guests: 238 - Bots: 324
Users: 64,795 (2,376 active)
Latest user: mathew

VWF Dialogues v1.4

Patch

Word wrap function is now done! Actually I feared that this function might cause the game to lag even with sprites frozen since it requires a loop to run through many times which itself calls subroutines that have loops in them. So depending on a word's length and the number of special characters within I feared it to cause noticable slowdowns, but now, it works just fine (as I said with sprites frozen, I didn't test with sprites unfrozen). Now I have all of the important functions done. Also added a few other, small functions today.

EDIT:
Sprites unfrozen it lags quite a lot now, but maybe that can still be fixed. I don't know, this will be the last thing I'll take a look at, since making everything work at all is my main focus right now. Maybe FastROM patches could also be a solution here?
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
Is there any reason one would want the sprites to not be frozen during the message?

Also, can this reload Layer 3 effects (tides, mists, fish, custom stuff) after the message box closes?

[?] Miscellaneous Helpful Hints
If I moderated your hack, there was apparently a 90 percent chance it was rejected.
Originally posted by RPG Hacker
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.


That's where xkas' .tbl file support and macros becomes handy. Though I am honestly not sure if 16-bit .tbl are supported. Anyway it almost seems simpler to me to make it command based, not character based, so each block of text is prefixed by a mode and size. If you want me too, I could write the macros for you... I have gotten pretty good at them. :P

Originally posted by RPG Hacker
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?


But it's only necessary to use all the layer 3 gfx in full screen box which wouldn't have the status bar anyway... there is a good chunk of it that's mostly only use for the title screen and message boxes which should be enough for 3 or 4 lines.

That said, it's probably not a big deal to lose layer 3 for a while. One effect I thought of doing for cutscenes was to scroll the status bar up off the top of the screen before one and scrolling it back down after one. Not really hard to do, just change where the it puts the status bar scroll register and calls the IRQ. Oh and the item box sprite. Which reminds me, you should make it hide the sprite if you don't... I don't remember if you got any power ups in the vid.

Originally posted by RPG Hacker
Sprites unfrozen it lags quite a lot now, but maybe that can still be fixed. I don't know, this will be the last thing I'll take a look at, since making everything work at all is my main focus right now. Maybe FastROM patches could also be a solution here?


Try pre-calculating line size for each block of text or when the textbox opens and not as it's drawn. A short pause is better then constant lag. That said, depending on the timing, it might not be practical to do a whole bunch of crap at once.


Your layout has been removed.
Originally posted by andy_k_250
Is there any reason one would want the sprites to not be frozen during the message?


"Level up!"

"X is casting a Spell! Lv. 8"

"What a horrible night to have a curse."

I think some pieces of text like these which could be triggered by certain events during action phases would be detrimental if they paused gameplay, which, from the look of the video, would be possible to make happen. I'd really like it if the option for not freezing sprites stayed, but if it proves to be impossible/unrealistic to keep the game running smooth, it wouldn't be a deal breaker to me, I'd still love to employ this tool.

To see it all go smooth for you with your endeavors would be awesome. Keep up the good work, this has great potential.
Just getting everything working as mentioned sounds ideal before any optmization. You could release a functional but laggy patch and anyone in this forum can suggest ways to speed it up.

video looks very nice, well done on getting this far.
Thanks for all your comments!

Originally posted by andy_k_250
Is there any reason one would want the sprites to not be frozen during the message?


Well, yeah. Pretty much all of this text box was inspired by secret of Mana a lot. In Secret of Mana the text box was also used to give you messages like level up messages or stuff like that. Those never froze the game, they were just shown on the top of the screen. I also can think of a few other ways of using this function.

Originally posted by andy_k_250
Also, can this reload Layer 3 effects (tides, mists, fish, custom stuff) after the message box closes?


Well, yeah. The complete layer 3 data is backed up to RAM before the actual code starts (I'm using Kaijyuu's OW Event Restore Patch to get 16 kb at $7F:0000). The actual layer 3 settings - like scrolling rate or position - are absolutely untouched. That's where my method of just expanding the Status Bar IRQ during dialogues comes in handy. I'm abusing this IRQ so that I don't have to touch the other layer 3 settings at all and therefore don't have to backup everything. I'll try to include in a video what that looks like if I don't forget it. It doesn't change the fact that layer 3 is "invisible" during dialogues, though, so it may still be better to not use this in layer 3 levels.

Originally posted by KilloZapit
That's where xkas' .tbl file support and macros becomes handy. Though I am honestly not sure if 16-bit .tbl are supported. Anyway it almost seems simpler to me to make it command based, not character based, so each block of text is prefixed by a mode and size. If you want me too, I could write the macros for you... I have gotten pretty good at them. :P


Well yeah, right now I'm using an asciitable to get the correct values. Since I have word wrap and auto line break ready now it is pretty easy to write longe dialogues with this. But my main concern is that this method is not comaptible with Unicode and my patch was designed to be compatible with all kind of languages. That's also why there is 16-Bit-Mode, even though it wastes double the space. I really don't know of any good compression format that at the same time keeps everything easily customizable. I could probably make a font compressor like Romi did, but then again I would need a GUI application even more and editing those files would be arse.

Originally posted by KilloZapit
But it's only necessary to use all the layer 3 gfx in full screen box which wouldn't have the status bar anyway... there is a good chunk of it that's mostly only use for the title screen and message boxes which should be enough for 3 or 4 lines.


Yeah, but how is the patch supposed to know whether some area in VRAM is untouched or not?

Originally posted by KilloZapit
That said, it's probably not a big deal to lose layer 3 for a while. One effect I thought of doing for cutscenes was to scroll the status bar up off the top of the screen before one and scrolling it back down after one. Not really hard to do, just change where the it puts the status bar scroll register and calls the IRQ. Oh and the item box sprite. Which reminds me, you should make it hide the sprite if you don't... I don't remember if you got any power ups in the vid.


Yup, I've thought of hiding the sprite. Well yeah, such an effect indeed would not be all that hard to make. I'm leaving that up for the user for now. Everything that has to be done is modifiy the IRQ layer 3 position from my patch. One problem could be, though, that often in SMW right below the Status Bar there are other graphics. The layer 3 smaher for example starts right under the Status Bar. Moving it up would show it in the Status Bar. Of course you could overwrite that space before you do so, but then again if a layer 3 smasher is currently on the screen it would suddenly get cut-off.

Originally posted by RPG Hacker
Try pre-calculating line size for each block of text or when the textbox opens and not as it's drawn. A short pause is better then constant lag. That said, depending on the timing, it might not be practical to do a whole bunch of crap at once.


My problem is that I do not have all that much RAM. If I did I would just create the whole dialoge in RAM and then make it possible to load up everything at once. I think I've already wasted more than enough RAM already. 558 bytes + 16 kb for layer 3. Some of thsoe 558 are still untouched, though. But yeah, I kinda thought of using RAM to make everything faster, too. I don't necessarily have to waste a lot of RAM for that. I could just take a few routines that are often called and shorten them by saving some of their settings to RAM before the dialogue even starts. This would defenitly make everything a lot faster.
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
I think I'll redo this one completely. I'm just not satisfied with the current version. Looking back there is a lot which can (and has to) be improved. I don't even feel like working on this version anymore, since I've done this so badly that every single edit to it gets really, really hard. Also by working on it (and by being on Serioushax a lot lately and by doing a lot of stuff with SMW in general) I got a lot of experience, so that I can do it a lot better now. So if I redo it it will turn out a lot better than the current version. That means it'll be faster, smaller, cleaner and have more comments. Also I might drop multiple font support, depending on how much slower it makes everything. If it's bearable I'll keep it in. Anyways, if I redo it the way I want it to then it'll gain a few extra functionalities which especially for advanced programmers will be very useful. Also two new options can be easily be implemented: Displaying the text centered and displaying the whole text at once. The latter option requires a lot of free RAM. However, if I redo it I'll code it so dynamically that you can choose the RAM destination yourself and even use SRAM if you want to.

That's about it I guess. Also note the update in my title. I'm redoing this plus I have to focus on school, so this obviously won't be done in a while.
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
Nice to hear you're sticking to this project. Although it's quite obvious that we'd all like to see this released as soon as possible, take your time - school's definitely more important than hacking. By the way, I personally wouldn't have anything against you dropping the multi-font option, given how many other cool features you've already put in.

(You don't know approximately when this will be finished, do you? <:) )


 
WOW! WTF? Why doesn't quoting work? Oh dang, doing it the hard way...

Originally posted by "WYE"
(You don't know approximately when this will be finished, do you?)


Hard to say. Knowing that the hardest thing about ANY programming project is always actually getting started with it and knowing how I can almost only work on this on weekends it might take it's time. Then again the fact that I have all the graphics and tables done and the fact that I know what to do and how to do it will speed everything up a lot. Yeah, in fact: Maybe I can get it done for C3? That would be the first time I'd take part at an event. However, I'm not making any promises here, just estimates.

Oh yeah, I'll also drop 16-Bit Mode. I mainly wanted it for complex languages like Japanese, but I figured langauges like that don't need VWF anyways. On the other hand having 16-Bit Mode makes everything a lot harder to program. Maybe I'll make a seperate patch for this which supports 16-Bit, but doesn't use VWF. We'll see.
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
Still awesome to see you didn't forget this, and you can finish this once. That's the most important, so good luck!! :D
Well, I for one will definitely be looking forward to it when it comes out, which can't be soon enough (unless you somehow manage to release it before the next Lunar Magic). But no pressure. Is there anything we can do to help?

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

I'm working on a hack! Check it out here. Progress: 64/95 levels.
Okay.

By the way, I'm assuming you're planning to have an option to change the music during the dialogue...are you going to make it support changing to ANY song number, loading samples as well if necessary?

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

I'm working on a hack! Check it out here. Progress: 64/95 levels.
Because if you want to, for Romi's addmusic I have the routine for that in my global subroutine patch. (And if that doesn't, you can always look at Kil's block. Infact, if you use AddmusicM it doesn't matter because you can write any number to $1DFB).
I own a community of TF2 servers!

ASMT - A new revolutionary ASM system, aka 65c816 ASseMbly Thing
SMWCP - SMW Central Presents a Product- tion long name

frog

http://esolangs.org/wiki/MarioLANG
I didn't plan an option like that. For that I have an "execute ASM code" option which lets you do pretty much everything during dialouges, including simple writes to $1DFB. I think this should be enough. In the code it would look something like this:

Messages.asm:

Code
Message0000:
db "Change music now!"
db $EF                   ; $EF = Execute Code
db ChangeMusic
db $FB,$FF               ; $FB = Wait for A Button, $FF = End



Customcode.asm:

Code
ChangeMusic:
    lda #$03
    sta $1DFB
    rts


I think this is simple enough. If not I'll simply include the code to change music in the Readme.


Oh yeah, I also actually have a few questions now:

1) How do you change the SRAM size of your cartridge? I want to test my patch with Free SRAM later.

2) If I had a label called
Code
!freeram = $7F0000        ; 16 kb of free RAM

Is there an easy way to get the bank numer of that label? I know to get the offset you could just do

Code
rep #$20
lda !freeram


Which would equal "lda #$0000". I don't know how to easily load the bank number, though. So far what I always did was creating a dl table, then putting all my labels in there and loading the banknumbers from that table. I guess there is a much better way to do this, though.
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
org $FFD8 ;SRAM Increase 07 should enable you to use SRAM $700000-$71FFFF
db $07 ;SRAM Increase


As for bank numbers: From Alcaro/used in my mode 7 upload edit:


!7Tilemap = $678000 ;These are the locations of your mode 7 graphics and tilemap.

LDX.w #!7Tilemap ;Mode 7 Tilemap Offset (Inserted with xkas)
STX $4342 ;DMA Source Address Offset
LDA.b #!7Tilemap>>16 ; Mode 7 Tilemap Bank
STA $4344 ;DMA Source Address Bank

note: XY is 16-bit A is 8=bit


test
I own a community of TF2 servers!

ASMT - A new revolutionary ASM system, aka 65c816 ASseMbly Thing
SMWCP - SMW Central Presents a Product- tion long name

frog

http://esolangs.org/wiki/MarioLANG
Thanks. Using right-shift was actually my idea as well, I just didn't try it yet. Guess that confirms that it works. :D
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
Also as I said, bank byte can also be LDA.b !7Tilemap/$10000
I own a community of TF2 servers!

ASMT - A new revolutionary ASM system, aka 65c816 ASseMbly Thing
SMWCP - SMW Central Presents a Product- tion long name

frog

http://esolangs.org/wiki/MarioLANG
Does it have the capability to compare RAM addresses? For example, can it show "You have bought this item for 500 coins" or "Sorry, you don't have enough coins. You need 500 for this item." depending on whether the player has 500 coins or not, or display either "Access granted." or "No key? You shall not pass!" depending on whether or not a certain bit of a certain address is set?

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

I'm working on a hack! Check it out here. Progress: 64/95 levels.
You shouldn't need a Messages.asm and a Customcode.asm, and it seems rather annoying to do it that way. A better way is simply putting code after the message that calls it like so:

Code
Message0000: 
db "Change music now!" 
db $EF ; $EF = Execute Code
db ChangeMusic 
db $FB,$FF ; $FB = Wait for A Button, $FF = End

ChangeMusic: 
lda #$03 
sta $1DFB
rts


It might be nice to have an extra command to load a byte into A and then jump, so you can set parameters. Reuseable code would make a Customcode.asm more worthwhile.

Also shouldn't it be "dw ChangeMusic"? :P
Your layout has been removed.

Patch