Language…
10 users online: AJ1Ayrton, Daizo Dee Von, GRIMMKIN, Hidincuzimsmokin, Klug, Oskise,  Ringo, Rykon-V73,  Telinc1, Tsquare07 - Guests: 251 - Bots: 368
Users: 64,795 (2,375 active)
Latest user: mathew

VWF Dialogues Patch v1.3 - Preview

Super Mario WorldPatchWork in Progress

Well, I definitely wished I could have released the new version of VWF Dialogues Patch during this C3, but I'm a notoriously slow worker, and I kept pushing the this version's scope higher and higher, like the complete fucking moron I am, to the point where I basically reworte like half the thing*, so alas, just a preview it is for today.

* Major exaggeration.

I started picking up work on VWF Dialogues Patch again for two main reasons. One reason was to fix bugs and incompatibilities. Some of you might remember that yoshifanatic, who really contributed most of the new features for v1.3, already submitted it to this site a few years back. However, it was rejected/pulled again, due to having some incompatibilities (it either didn't work on hardware, or didn't work in newest emulators, depending on settings). Since the patch was lying dormant on my GitHub for years, I decided to finally tackle these bugs. The second reason was that the version of the patch currently hosted on SMWC doesn't actually assemble in the newest version of Asar, and it's mostly my fault for creating the function hell that is shared.asm, so I wanted to change that.

However, once I started working on the fucking thing, I immediately noticed how full of shit it was. Understandable, considering I made it almost 15 years ago. I immediately noticed potential for major improvements, especially utilizing features of upcoming Asar version 1.9, so I got to work and immediately turned what would have otherwise been a multi-week project into a multi-month one. Honestly, I'm really fucking surprised I haven't lost moviation yet - so rare for me nowadays - but I actually got to a point close to completion, and everything that's left now is some remaining testing, bug fixing (mostly on hardware) and polsihing. So without further ado, here's a sneak peek at some of the new features you can look forward to.


Greatly Improved Usability

Take a look at this:



What you see here is your average message when using VWF Dialogues Patch v1.2. Now take a look at this:



This is that exact same message, but rewritten for VWF Dialogues Patch v1.3.

The entire patch has been rewritten so that you can now write messages entirely using Asar macros and function. As a result, you no longer have to memorize any magical hex numbers and messages immediately become 300% more readable (well, in theory - some of the new macro names are kinda annoyingly long, which does take away a bit from readability, but I plan to improve this even further by adding abbreviations for all macros later on). As an added bonus, these macros automatically do 99% of all the distinctions that you need to for the patch's 8-bit and 16-bit modes. Another nice bonus is that these macros do a lot of error-checking at build-time, so for a lot of errors, you no longer have to start your ROM, only to find out that it'll break in horrible ways.

Probably the biggest improvement is the %vwf_header() macro. It uses a new feature of Asar v1.9, varidadic macros, which basically lets you define macros with optional arguments. One of the nastiest thing of older VWF versions was that you always had to specify the entire header for each message. Not only was this quite annoying, but it was also horrible to memorize, because the old header format was just a bunch of magic bits and bytes again. Also, if you wanted to change the default look of all your text boxes, you would have previously had to edit every single message header. That's no longer the case. Now, you simply provide defaults for every single header setting, and you can skip specifying any of them. You only need to specify the settings you want to change for a given message, which looks like this:

Code
%vwf_header(vwf_x_pos(1), vwf_y_pos(1), vwf_width(14), vwf_height(12), vwf_text_alignment(TextAlignment.Left))


Again, I'll likely touch up the formatting a bit later and potentially shorten some of these names, but even in its current form, I hope you can already see the improvements over having just magic numbers.

In theory, this could even be used in a future version of the patch to reduce the overall size of the assembled patch, by skipping these default settings in the actual ROM. Currently, they are only skipped in code, but still assembled to the ROM for every header.



Skip Messages

This feature was entirely implemented by yoshifanatic, I really only fixed a minor bug with it. You can now specify a skip location for all messages. Pressing the Start button will then immediately make the text box jump to that location. Most of the time, this will simply be the end of the text box and will allow you to cancel out of any optional text boxes a random NPC might give you. Super useful if you accidentally talk to an NPC when you didn't want to.



Automatic Pointer Generation

The old version of the patch used a file called vwfmessagepointers.asm with pointers to every single message. This was not only prone for errors (in fact, the old file already contained a couple of bugs built-in), but also required manual labor if you ever wanted more than 256 messages in your hack. Well, all of that is history now, as this file is no longer needed in VWF Dialogues Patch v1.3, which automatically generates all the pointers for you, based on which messages you have actually defined.


Error Messages

Using the patch in certain ways will automatically display an in-game error message as of version 1.3. For example, trying to display an error message that wasn't filled in.



yoshifanatic originally implemented this feature, but I made it more reliable and added new types of error messages. This way, hopefully a play tester can immediately tell a hack author about any text box-related bugs they come across.


Message Box Animations

When you use the "load message" command, you can now decide to display the close/open animation of text boxes. Probably a feature with niche applications, but I can definitely think of a few. Deciding to re-show the open animation will also reload certain text box settings, like box frame or box pattern. See further below for an example of what this makes possible.



MessageASM

MessageASM is a feature originally implemented by yoshifanatic. I made some improvements to it. You can imagine it as the VWF Dialogues equivalent of UberASM: For every single message box, you can have a certain code routine that gets executed every frame. The applications for this are vast. For example, here I used it to animate the text color of a message box.



Or here I used it to implement text box customization - which is a feature that existed in code pretty much all the way since version 1.0 of the patch, but there was never s traight-forward way to utilize it. Even now, doing it with the patch alone still isn't quite perfect (for example, settings won't get saved to SRAM automatically), but at least this gets us a lot closer to it being an easily accessible feature (for, like, the two hacks that would actually even use it).





Text Macros & Text Macro Groups

Text macros are a powerful feature originally implemented by yoshifanatic, but I expanded them, fixed some bugs and greatly improved their usability. Put in simple terms, text macros are an easy way of saving space in your ROM, as well as effort. For example, have the name "Princess Peach" appear in a lot text boxes? Then you can now wrap it into a text macro. Instead of writing out the full name for every single usage, you now only need to call the macro, which takes up a mere three bytes of space in the ROM (instead of whatever the name would have normally rquired) and spares you the embarassing fate of accidentally misspelling Peach's name as "Princes Poach" in that one text box only.

However, the usefulness of text macros doesn't stop there. Combine them with text macro groups and their potential is immediately multiplied by one hundred. This feature allows you to wrap text macros into groups, and then allows you to index those groups by arbitrary RAM addresses. Want an example? Let's say you have an item system in your game, and a RAM address which stores the type of an item. If you now create text macros for the names of all items, you can wrap them into a text macro group and then index that group by the value of that RAM address. The result will be that a text box displays the correct item name, depending on the value of the address. In theory, this even makes the creation of simple menu systems possible.



In this screenshot, I created two text macro groups: "PlayerPowerupStatus" and "CurrentPlayer". Then I created a text macro "CurrentPlayerWithPowerup", which indexes the first group with by $7E0019 and the second group by $7E0DB3. By simply calling this macro in a text box, I can now display the full name of the current character in a text box, like "Fire Luigi" in this screenshot.



Buffered Text Macro

Technically an extension of text macros, I'll list them separately, because they're more of a coding feature and not quite as useful for average users. Originally implemented by yoshifanatic and then improved by me, buffered text macros function just like regular ones, except you can construct them at run-time rather than at build time. The way this works is by adding snippets of text box commands to a global memory buffer. All you need is a length and list of a commands.

Use cases will be very limited for average end users, but one use case for advanced users can bee seen below:



Here I used buffered text macros to implement an intentionally shitty name entry screen. Now the reason it's so shitty is simply because I implemented it almost entirely via the text system itself with minimal code. The text system is of course limited, so this was the best I could do without a lot of code, but in a full hack with more custom code around it, you could indeed implement a proper Secret of Evermore-styled name entry screen using this feature.

Note that displaying text from RAM wasn't exactly impossible in previus versions of the patch, but this one supports it in more of an official manner, and it's now a lot easier to do.



What's Next?

I've been working on this version of the patch for several months already, and while I had hoped to have it released in 2021, it'll likley be a couple more months from now before an actual release will happen. My vacation ends on Monday, so my free time will be more limited by then (plus, as I said, I'm a notoriously slow worker, anyways).

Some of the work left to do includes:
  • Fixing a few final bugs
  • Testing on hardware (sd2snes)
  • Improving readability by adding abbreviated commands
  • Rewriting the manual (like, literally, almost the entire thing - yikes!)
  • Documenting and testing backwards-compatibility with version 1.2 (it will be very limited, but I plan to include recommendations for how to migrate from v1.2 to v1.3 in at least a few limited cases).


Thanks for reading! And if this somehow magically ends up winning anything (don't know how likely that is for an in-progress patch), don't forget that yoshifanatic made major contributions to this version and should get a trophy as well.
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
VWF Dialogues is quite a complex patch but it is one of the best ones as a result, particularly because it allows for such creative messages, particularly in-engine messages (the same can't be said for e.g. bg4vwf and Messages in Minimalist Status Bar, though they are creative in their own ways too). Naturally, an update (particularly a minor rewrite) these features (e.g. text macros and custom name display) makes it even better. MessageASM is also nice, particularly because it allows for easier control for in-engine cutscenes.

Originally posted by RPG Hacker

I remember how in the beta (the first video of VWF Dialogues), you're able to customise which doesn't work in the release anymore, I think
this is REALLY impressive. not only because of how feature-rich it is, but also because you're working with code you wrote a long time ago without your soul crumbling to dust lol
All work on VWF Dialogue is holy work. Anything that makes it easier to work with is divine.

Originally posted by RPG Hacker, Emissary of Divinity
but also required manual labor if you ever wanted more than 256 messages in your hack. Well, all of that is history now, as this file is no longer needed in VWF Dialogues Patch v1.3, which automatically generates all the pointers for you, based on which messages you have actually defined.

So in the new version, would you only need to put "dialogue 100" after "dialogue FF" to go past 256? Then is the new limit just however many you can cram into your hack before there's no more room?


Other Submissions of mine!
This is great. I've thought for a while that this was the best message patch on the site, and seeing it get updated makes me glad. I hope you finish it soon!

Now, I do have a couple suggestions for possible features to add:
- Sprite display. This was in Romi's message system but not in this one, aside from one personal fork that somebody made (might have been Yoshifanatic; I don't remember). It would be really useful to have, especially for character portraits (like in Touhou games, for instance).
- A variant of the option command that supports each one going over multiple lines. Presumably, there would need to be additional data to specify how many lines each option takes up.
- Perhaps a command that can wait for different buttons and do different things depending on which one is pressed? Is this currently doable with MessageASM?
- Maybe a command for uploading data to VRAM? This might be doable with MessageASM, though. So might setting up HDMA, which I also thought about.

Also, I take it the music and color change commands now work properly on hardware?

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

I'm working on a hack! Check it out here. Progress: 64/95 levels.
never thought this is gonna happen…and seems even better than one would've imagined…I am soo happy and looking forward to the release and the new things which comes with it and of course re-implement it in my hack!
Originally posted by MarioFanGamer
VWF Dialogues is quite a complex patch but it is one of the best ones as a result, particularly because it allows for such creative messages, particularly in-engine messages


Thanks! Making the patch very flexible was definitely one of my main goals back then, even though it comes as at a price (needs a lot of CPU power and also a lot of RAM). Definitely wild to see how my patch has stuck around for so long, despite me being so inexperienced when I made it.

Originally posted by RPG Hacker
I remember how in the beta (the first video of VWF Dialogues), you're able to customise which doesn't work in the release anymore, I think


It actually works in all versions of the patch I ever released, plus that one unreleased beta version from the video you mentioned (which was a completely separate patch, really - I scrapped it and rewrote it from scratch back then). The issue is that I never made any UI to customize the text box, so this feature just lied dormant in code. The only way to modify the design was to write to the respective registers with UberASM or something (which is really what I did in that first demo video).

The same is still true now, I'm still not providing a UI myself, but at least it's now reasonably simple to absue the patch as sort of a UI for that. An example implementation (seen in that GIF) will be available on my GitHub. It's still not what I would call a proper solution to be used in a full hack, but I think it's a great starting and neat proof of concept.

Originally posted by MercuryPenny
not only because of how feature-rich it is, but also because you're working with code you wrote a long time ago without your soul crumbling to dust lol


Well that definitely still happened, rest assured. 😅
Some parts of the patch are definitely garbo. For example, for almost every command in the patch, there's two nearly identical pieces of code - one for calculating the width of the text, and one for actually rendering it. I'd never do it that way nowadays.

I can deal with it, though. Mainly because that code is over a decade old - if it didn't make me cringe, it would mean that I learned nothing since then. More importantly, I think the value the new features will provide is greater than any cringe the code could make me feel.

Originally posted by Deeke
So in the new version, would you only need to put "dialogue 100" after "dialogue FF" to go past 256? Then is the new limit just however many you can cram into your hack before there's no more room?


Basically that, yeah. By having a start/end message pair in your file, the patch will know to generate a pointer for that message. So for example,

Code
%vwf_message_start(011F)
%vwf_message_end()


once you do this, the patch will know to generate a pointer for message $011F.

In reality, the patch is actually even smarter than that. It also checks if a %vwf_header() is present inside the message. If it isn't, it will consider the message a stub and will instead generate a pointer to the fall-back message (which you can see in the "Error Messages" section above). It also won't allocate the header until %vwf_header() was actually called, so all these stub messages waste 0 bytes of free space, except for their generated pointers.

There is one minor caveat. The patch only looks at the highest message ID you've allocated. So if you only put messages 0000 and message 0100 into your hack, 0100 will be the highest ID, so the patch will generate pointers from 0000 up to 0100, which is of course wasting a lot of space. I did this so that I could still index the pointer list linearly without needing yet another indirection and slow lookup. Though the patch does print a warning if you have too many gaps in your message IDs, so as long you pay attention to it, you shouldn't run into that problem accidentally. I mean, the old patch already included pointers up to 0100 by default, anyways, so the new version isn't really wasting any space that the old version wasn't already.

Originally posted by imamelia
- Sprite display


This is something I'd love to have, but I've looked a bit into it in the past, and I don't quite see how. At least not without major limitations.

I mean, admittedly, my biggest issue is just not being very familiar with how sprites work in SMW. I've never coded a single working custom sprite for SMW, if you'd believe that. Though from what I can tell, it would definitely be tricky to do, regardless.

Romi's VWF patch runs on a separate screen with nothing else being rendered. That basically makes every single sprite slot available for that patch to utilize. My patch doesn't quite have this luxury, it's being rendered on top of gameplay. Additionally, there would be priority issues with sprites. The text box always gives priority to layer 3, which will be rendered on top of everything, so sprites would always appear behind it. In fact, when I wrote the first version of the patch, I tried implementing options via a sprite cursor, but gave up on it eventually. So rendering sprites would only be possible outside of the text box.

Definitely not saying this feature would be impossible, but I think think it would have major compromises, be very situational and be very complex to implement in a usable way - which kinda goes against the patch's principle of trying to be very flexible.

Originally posted by imamelia
- A variant of the option command that supports each one going over multiple lines. Presumably, there would need to be additional data to specify how many lines each option takes up.


Hmm, yeah, that could definitely be useful. And it might be possible, even if a bit tricky. Though if I'm honest, the implementations of options in the patch is what I consider "hell zone". I'm kinda too scared to even just look at the code. I don't know if I currently have the backbone to attempt updating it. I do think it would be a reasonable change, though, and I don't even think it would need any extra data. In theory, the patch should be able to deduct how many lines an option takes up.

Originally posted by imamelia
- Perhaps a command that can wait for different buttons and do different things depending on which one is pressed? Is this currently doable with MessageASM?


Yeah, definitely thought about that, and absolutely something I might add in a future version of the patch. Should be quite simple to do.

Probably not for this version, though. If I added this, I'd like it to be an extension to the "wait for A" command, rather than a new command entirely. Though I'm making an effort to keep v1.3 binary-compatible with v1.2 messages. This requires me not changing commands too much. Once v1.3 has been out for a while and everyone has switched to using macros, binary compatibility is no longer a concern, so in a future version, I could implement this easily.

Also yeah, MessageASM would absolutely make this possible. In fact, my test suite includes a test which does just that: It waits for the player to press L + R. This is done via a new command, %vwf_freeze(), which freezes the text box until the text pointer is modified by something, which MessageASM can do. The text box customization seen in the GIF above also does something like this.

Originally posted by imamelia
- Maybe a command for uploading data to VRAM? This might be doable with MessageASM, though. So might setting up HDMA, which I also thought about.


Yeah, could definitely be useful. And probably very doable. The patch already includes a flag which can be set to start a palette reupload. In the "animated text color" GIF above, I'm abusing that exact flag. I suppose something similar could be added for generic VRAM uploads in a future patch. In fact, that could be a reasonable alternative for the sprite limitations mentioned above, to put 2-bpp images on screen. Something to keep in mind for a future version of the patch.

Originally posted by imamelia
Also, I take it the music and color change commands now work properly on hardware?


I don't know if they currently do - but I will definitely test everything on console once I'm done with updating actual code. I will do console testing last, since it will be the nastiest step (as it requires moving around my SD card for every single change I want to test).

I haven't heard about that music incompatibility yet, though. And I have no idea what could case that. My patch literally just writes values to $1DFB. Could that maybe be a problem with AddMusicK rather than the patch itself?
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
Originally posted by RPG Hacker
This is something I'd love to have, but I've looked a bit into it in the past, and I don't quite see how. At least not without major limitations.

Even if it only works in levels that don't have other sprites active, that's still something. It could be used for cutscenes. I suppose in the meantime, one could probably work around it by using the message code (either MessageASM or $F1 or both) to store values to a RAM address that then get read by a custom sprite in the level. It could even be a dynamic sprite.

Originally posted by RPG Hacker
I mean, admittedly, my biggest issue is just not being very familiar with how sprites work in SMW. I've never coded a single working custom sprite for SMW, if you'd believe that.

Maybe I should make a sprite-coding tutorial one of these days....

Originally posted by RPG Hacker
Hmm, yeah, that could definitely be useful. And it might be possible, even if a bit tricky. Though if I'm honest, the implementations of options in the patch is what I consider "hell zone". I'm kinda too scared to even just look at the code. I don't know if I currently have the backbone to attempt updating it. I do think it would be a reasonable change, though, and I don't even think it would need any extra data. In theory, the patch should be able to deduct how many lines an option takes up.

*shakes pompoms* You can do it!

Originally posted by RPG Hacker
Yeah, definitely thought about that, and absolutely something I might add in a future version of the patch. Should be quite simple to do.

Probably not for this version, though. If I added this, I'd like it to be an extension to the "wait for A" command, rather than a new command entirely. Though I'm making an effort to keep v1.3 binary-compatible with v1.2 messages. This requires me not changing commands too much. Once v1.3 has been out for a while and everyone has switched to using macros, binary compatibility is no longer a concern, so in a future version, I could implement this easily.

Also yeah, MessageASM would absolutely make this possible. In fact, my test suite includes a test which does just that: It waits for the player to press L + R. This is done via a new command, %vwf_freeze(), which freezes the text box until the text pointer is modified by something, which MessageASM can do. The text box customization seen in the GIF above also does something like this.

Good to know.

Originally posted by RPG Hacker
Yeah, could definitely be useful. And probably very doable. The patch already includes a flag which can be set to start a palette reupload. In the "animated text color" GIF above, I'm abusing that exact flag. I suppose something similar could be added for generic VRAM uploads in a future patch. In fact, that could be a reasonable alternative for the sprite limitations mentioned above, to put 2-bpp images on screen. Something to keep in mind for a future version of the patch.

I've been trying to come up with possible commands for a message system in SNES homebrew games, what might be useful to have. Honestly, if I ever get around to anything like that, I might just port your system; it would take some work, but probably less than reinventing the whole thing.

Originally posted by RPG Hacker
I don't know if they currently do - but I will definitely test everything on console once I'm done with updating actual code. I will do console testing last, since it will be the nastiest step (as it requires moving around my SD card for every single change I want to test).

I haven't heard about that music incompatibility yet, though. And I have no idea what could case that. My patch literally just writes values to $1DFB. Could that maybe be a problem with AddMusicK rather than the patch itself?

Yeah, maybe you're right. There was definitely a time in the past when just storing values to $1DFB wouldn't work correctly, but I think the current version of AddmusicK handles that okay. (Well, except when it turns the background yellow like it does in my hack...)

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

I'm working on a hack! Check it out here. Progress: 64/95 levels.
You're the last person I expected an ASM release from this C3. You've turned the tables on me! Sneaky sneaky. #tb{'U'}

I was so excited (and amazed) when you released the very first version, and to think it's been more than a decade since then is wild. I could have sworn you'd given up on the project a long time ago! Although I won't ever be using this now, I love reading through changelogs and illustrated feature lists - especially when the features are this exciting and immediately useful.

Good luck on getting this update finished!


 
It's quite nice seeing my attempt at an V1.3 update to this patch being improved and expanded upon! :) I feel like the improvement to the text formatting alone may help get more people to use this patch when you finish this update.

Fun fact, the version of this patch I'm using in MYSQ is a sort of beta version of what I eventually attempted to submit to SMWCentral's patch section. If I remember correctly, the main differences were that some of the new features were implemented in a somewhat different way in my hack (in particular, the message header format is a bit different, as I repurposed bits for features that I removed), which I re-wrote in the version I submitted.
My Hacks:
Mario's Strange Quest V1.6
Yoshi's Strange Quest V1.3 / V1.3.1 Beta 4.6
Mario & Yoshi's Strange Quests (2/10/2023 Build)

Other stuff:
My SMW/SMAS/SMAS+W disassembly
Yoshifanatic's Discord Server: A place for fans of my stuff and/or Yoshi to chat with others.
Even if it isn't going to be released for a while, I'm still majorly impressed that you decided to put in the effort to not only add in new features and fix bugs, but that you also managed to make it even easier to use. Coming back to this after so long cannot be easy, and I commend you a lot for being able to accomplish so much with it already since then.
PS. I wonder if it's possible to integrate this patch with KevinMs Retry Uberasm and all the other windows (continue/end, Save window etc.)? -That would be awesome(!) and consistent in the aesthetics (but probably also complex).
Something that just occurred to me: how compatible will the update be with older resources using it? I'm thinking of the NPC sprites I just updated (and would kind of like to not have to update again for a new VWF version #tb{^^}).

Simply put, will this code still work in the future with no changes to it? (assume the macros get the 16-bit message number.)

Code
	!varram	                = $702000
	!varramSA1	        = $419000

	if !SA1
	!varram	= !varramSA1
	endif
	%load_extra_byte(2)                     ; \
	XBA                                     ;  |
	%load_extra_byte(3)                     ;  | show the dialog with the given number
	REP #$20                                ;  | (skip if another dialog is active)
	STA !varram+1                           ;  |
	SEP #$20                                ;  |
	LDA !varram                             ;  |
	BNE ++                  		;  |
	LDA #$01                                ;  |
	STA !varram                             ; /
	; [...]
++



 
@RPG Hacker: Quite the great way to improve this tool.
While this will not work with layer 3, unless some clever ASM hacking is used, I do want to have a go there.
Thanks, everyone! 🙂

Originally posted by WhiteYoshiEgg
You're the last person I expected an ASM release from this C3.


Honestly, I didn't see it coming, either. 😅
I just started a few months ago and weirdly got into it. Maybe because ASM is so different from C++ that it provided a strong enough contrast from work to where it didn't just feel like I'd be working. I feel like I phrased that kinda weirdly, but my point is, I had huge motivational issue this past year, but I somehow managed to stick with this.

Originally posted by yoshifanatic
Fun fact, the version of this patch I'm using in MYSQ is a sort of beta version of what I eventually attempted to submit to SMWCentral's patch section. If I remember correctly, the main differences were that some of the new features were implemented in a somewhat different way in my hack (in particular, the message header format is a bit different, as I repurposed bits for features that I removed), which I re-wrote in the version I submitted.


Fun fact #2, the version I'm working on actually changed the format of headers once again compared to the one you submitted back then. In that version, a new byte was added to the header to enable Message Skip and MessageASM. Since I am aiming for binary compatibility with v1.2, I actually moved the bits to enable this feature into another header byte that had a few unused bits. Not sure why I left those bits unused in the past, but I guess it's only convenient for me.

Originally posted by simon.caio
PS. I wonder if it's possible to integrate this patch with KevinMs Retry Uberasm and all the other windows (continue/end, Save window etc.)? -That would be awesome(!) and consistent in the aesthetics (but probably also complex).


I would love doing something like that, but unfortunately I consider it to be out-of-scope for this patch without doing a complete rewrite. The main issue is that my patch can only render a single character per frame. That's a hard limitation, it was built like that from the ground up. While this is good enough for text boxes, it's not quite great for menu systems, which are expected to pop up pretty much instantly. Even hacking support for more characters into the patch likely wouldn't be possible. At least not without major performance issues.

So without a complete rewrite of the patch, I personally don't see this happening, and it's not very likely that I'm going to find time and motivation for a complete rewrite. Would still be pretty nice, though.

Originally posted by WhiteYoshiEgg
Something that just occurred to me: how compatible will the update be with older resources using it? I'm thinking of the NPC sprites I just updated (and would kind of like to not have to update again for a new VWF version #tb{^^}).


I actually didn't think about this, but I just checked, and !vwfmode and !message are still the first two !varram defines in the patch, so your code should still work. The only difference I can find is that !varramSA1 is now $415000 by default in my patch (I'm not sure when or why that was changed, but I'll keep it that way - I don't think that'll be a problem, since presumeably, users of your sprite will be expected to copy over the defines, anyways).

So yeah, I do think your sprites will still work. The new version of the VWF patch actually includes a new routine for displaying a message which is slightly more advanced in that it also checks if a message is already running and forces it to close if so. However, don't think it'll be necessary to have that in your sprites, since it's really a nice-to-have feature.

For the future, I should think about a more direct way of letting people access the patch's features. Like maybe a light-weight .asm file they can just drop into a patch that automatically finds the address of VWF routines. Newer Asar versions should absolutely make that possible. I've already thought about how to solve this problem properly before, but maybe I'll actually come up with a proper solution soon.
Feel free to visit my website/blog - it's updated rarely, but it looks pretty cool!
Definitely could see this with hacks that use allot of Asm or maybe Sa-1 seems interesting


You are challenged by Champion Daisy!

LAYOUT FOOTER:
This is very much to look forward to!

Super Mario WorldPatchWork in Progress