Nightcrawler's Message Board
Transcorp Projects >> Translation Corporation Projects >> Project - nuVWF (formerly Nightcrawler's VWF)

Message started by KingMike on Dec 8th, 2008 at 9:42am

Title: Project - nuVWF (formerly Nightcrawler's VWF)
Post by KingMike on Dec 8th, 2008 at 9:42am
Great to hear you're planning to make a "universal" hack.

But I imagine it'd still be a pain for games using tilemapped fonts.
(3x3 Eyes 1 uses one font routine for everything. Dialouge, menus. So, that left me with needed to rig up several control codes to control it (also printed multiple strings in parallel in some cases, meaning I need to include a tilemapped mode to avoid crossing the streams. :P )

Title: Re: Nightcrawler's VWF
Post by Nightcrawler on Dec 9th, 2008 at 7:25am

KingMike wrote on Dec 8th, 2008 at 9:42am:
Great to hear you're planning to make a "universal" hack.

But I imagine it'd still be a pain for games using tilemapped fonts.
(3x3 Eyes 1 uses one font routine for everything. Dialouge, menus. So, that left me with needed to rig up several control codes to control it (also printed multiple strings in parallel in some cases, meaning I need to include a tilemapped mode to avoid crossing the streams. :P )

Support for tile mapped engines is being done as well. I am actually currently working on supporting a 4th engine right now which happens to be tile map based. I had planned for this in the initial concept work. It's going to use the same routines. The only difference is it will use a smaller chunk of RAM for only one character and spillover at a time, and require an extra DMA hack to transfer the data to VRAM rather than simply change the tilemap like the original game's routine. The rest of the mechanics should be identical.

As far as the control codes for tile mapped menu fonts, I already have support for that as well. ;) The design supports custom control code handling. The main menu in Tenshi already runs fine with custom control codes for tile boundaries to make things line up.

As for something really stretching it like needing parallel printing or tile mapped mode; That's kind of out of scope, however the design is modular enough that one would probably be able to create a new render module and the rest would potentially work. Just speculation without getting into the specifics.

Obviously 100% of every case cannot be supported. But in those instances where it is not possible, the code can act as a template for easy adaptation to whatever the needs may be. Aside from the truly reusable parts, the idea was creating a structured framework that could quickly be molded to fit into any game even if it does need something out of the ordinary. I never want to have to code a new VWF or text system from the ground up again. Perhaps that ideal is not totally or realistically achievable, but I'll take something close! ;D

As I progress with supporting this tile mapped engine, I can give you more specifics on that. I will need some minor refinements for it. It is still a work in progress after all. And naturally, thus far, it's only really been tested in Tenshi No Uta. It will be quite some time before I give it a try in some other games to try and realize that potential.

Title: Re: Nightcrawler's VWF
Post by Nightcrawler on Jan 19th, 2009 at 4:23pm
I got away from this for awhile due to the holidays, an injury, and preparing for a wedding, but I've gotten the chance to get back to work lately. Supporting tile mapped fonts has been a bit more challenging than I initially planned for. I've got it working half baked. I need to restructure the main routines to better handle things now that I have it working. I also need some better handling of the vwf buffer when it's not a big RAM window and one 8x16 or 12x12 at a time which is used obviously for many 12x12 fonts and when replacing a tile mapped font.

So, there's still work to be done unfortunately before I can show something comprehensible. There's also a few bugs it seems. Certain areas of Tenshi No Uta's menus outside my test menus are crashing it seems. :(

Title: Re: Nightcrawler's VWF
Post by Next_Gen_Cowboy on Jan 20th, 2009 at 2:15pm
I can see something like this hopefully having not only widespread appeal, but also success. I have failed a great many times when trying to implement VFW in any non-standard way. (even then I have failed)

So this is what I am wishing you luck on, just as much as Tenshi No Uta.

I do not know whether or not you intend it, but I really do prefer the "Transcorp" font to most everything. The obvious readability particularly when running off of a low res monitor is a major plus.

I could have sworn you were not obsessive with fonts =p

Title: Re: Nightcrawler's VWF
Post by Nightcrawler on Jan 21st, 2009 at 8:07am
Another early issue I'm seeing is speed. The more flexible I make it, the more overhead there is. It's more noticeable on the tile map based menus where sections are fully rendered before they are displayed. With main dialog, you can print letter by letter and it's fine. With menus, you don't really want to see the menu being printed out.

I'll have to see what I can do with this. It just may not be that useful for instances demanding fast performance. In those cases, a custom routine may be a better fit.

I'm not obsessive with fonts. It's the opposite. I don't care about them. I found one that looked OK and don't care enough to find any more. Though I may be forced to on the menus. A thin font may be necessary to fit everything on screen.

Title: Re: Nightcrawler's VWF
Post by Next_Gen_Cowboy on Jan 21st, 2009 at 9:38am
Regardless I must say the fact that it works impresses me, if you can, keep me updated on the menus I want to see how this plays out.

Aside from the overhead is it working with all four fonts you want changed?

I am getting visions of Phantasy Star 3 text scrolling down and making my eyes bleed for eternity  :P

Title: Re: Nightcrawler's VWF
Post by Nightcrawler on Jan 22nd, 2009 at 8:21am
Thanks. I will be updating along the way. Eventually I'll post some code to give a better idea of the interface. I've had to make some structural changes and rethink a few things for tile map fonts, so nothing to show until I re-establish the structure.

It works with the four text engines OK so far. It has a few kinks handling tilemap conrol codes though in instances where you want to print the current tile, then one additional tile with spillover knowing the game will the handle the control as normal and  set the tilemap position elsewhere for a fresh start on a new letter/tile. It seems easy enough, but it's been trickier than I thought, especially knowing the variety of different things that could potentially happen during control codes for tile mapped menu engines. Rather than try and handle all possible cases which is impossible, my mentality is it needs to be an independent enough system that it will work regardless of what game might do. Each time through variables are initialized (tilemap location, VRAM location etc.) and it works relative to what the actual values are and can control their update.

So.. my hope is whatever the game does outside of the system should be immaterial because it's initialized with the current instance and all information needed to do it's job each time it's called. It's for this reason the system is called once per character rather than say looping until a tile is finished etc. As you might imaging, the constant information exchange and gathering adds much overhead, but the result is hopefully an independent, reusable rendering system.

It's still very much WIP. Tenshi's 5 or 6 or more (I keep finding additional ones the further I dig into battles and menus, but at least they are similar) text engines are my first goal. If I meet that, I will see about fitting it into other games and see if it can meet it's true potential. That's getting a bit ahead though. :)

Title: Re: Nightcrawler's VWF
Post by Nightcrawler on Feb 12th, 2009 at 5:57pm
I've been back on the job lately and am happy to report that I was able to overcome the obstacles I was having from above! Some restructuring and additions to the VWF core were able to take care of those spillover and control code issues I was having. I also figured out why some of the other menus were crashing and fixed that problem.

Unfortunately, it's still slow. Now that I have it working correctly, I going to look into trying to speed it up a little bit. I will work on getting some text in there for some of the other menus and then I'll be able to make another update on TransCorp with some nice pictures.

After that it'll be time to look at the battle text engine/s and add my 5th supported VWF. So, things are starting to look pretty good as far as this project is concerned.  :)

Title: Re: Nightcrawler's VWF
Post by Next_Gen_Cowboy on Feb 12th, 2009 at 6:41pm
That sounds simply fantastic, and I must say I am impressed with the speed. The number count seems to keep climbing. The implementation process sounds like its running smooth, which is kind of scaring me =p

Anything that goes this well is bound to cause massive spacial distortions, that is simply the way of things.

In all seriousness, in addition to being impressive it also sounds awesome.

Title: Re: Nightcrawler's VWF
Post by Nightcrawler on Mar 9th, 2009 at 10:12am
Things got a bit delayed on the VWf. When I was going to make screenshots, I thought I should have the real text in the menus, so I shifted focus to dumping the rest of the sub menu text and getting that translated.

I got that back a week or so ago and tried putting it in. Unfortunately, as I expected, it doesn't fit with the current font. I'll need to come up with a thinner font to use on the menus. I don't know where I'm going to get one from. I hate font finding. That's why I haven't changed my font in years. ;)

I will probably ask for some help on RHDN to find something that might work, since hardly anybody reads this board anymore!

I also hit a bit of a holdup because some things on the menu such as the HP display and character names naturally use yet another text routine. I haven't decided what I'm going to do with those yet. It's getting ridiculous. I also think I may keep fixed width for numbers such as the HP display. I have to do some thinking.

Title: Re: Nightcrawler's VWF
Post by Nightcrawler on Nov 9th, 2009 at 11:01am
This project saw advancements these last few months. Tenshi had more text engines than I thought. We're up to 7 different routines supported (there's more on the battle menu I haven't begun to hack yet). 5 of them were all tilemap based menu printing routines.

I underestimated the vast possibilities of a tilemap menu printing routine. It's been difficult to support them all while retaining the flexibility level of game and routine independence. I'm still facing speed issues, however there were some optimizations I had overlooked before that will help.

Tenshi does much screen redraw. In fact when it's on the item screen for example, it sits in a loop and constantly refreshes the screen. This has made the scrolling item list for example show off how slow things are.

It has been beneficial to the project that Tenshi has so many routines. I've been able to continually improve and enhance the core VWF system. By the time I get to use it on other games, it should be able to do the job.

I think in the end, there are going to be certain situations and games where you still can't use this. There's just so many possibilities on how game engines work, ESPECIALLY when it comes to menus. However, I think the project is coming out successful thus far that you can set up a new VWF very quickly as is in most cases.

It's been an enlightening project so far. I've found interesting problems with the tilemap based fonts and the extra DMAing of data throws off rudimentary frame counters used for courser blinking and other rough timing. Tenshi for example increments what appears to be a frame counting variable every time it DMA the menu tilemap which it refreshes every frame. This is outside of NMI, so if I add any additional vblank waiting anywhere, it slows things down. For each time the game thinks one frame has passed, more have passed.

The easy and logical solution is to throw your DMA in with the games. However, that's game specific. I try to come up with ways to handle this with universal structure. In this case, I would have to adjust the frame counting variable at the defined place in the universal routine to update game specific variables. This is much more difficult because I actually need to figure out what it should be updated to rather than just throw my data in the existing original DMA routine and the game goes on as normal.

These kinds of issues have shined light on the practicality of my universal routine. In some cases, it's actually simpler and faster to do it game specific and would be undesirable to use my routine. The good thing is my routines are modular enough that I could choose to use only some of it and keep the rest game specific. So, some savings is still achieved.

Anyway, a general site update is coming in the next few weeks that will have several screen shots of the action!

Title: Re: Nightcrawler's VWF
Post by nonme345 on Dec 17th, 2009 at 12:17am
Nightcrawler, are you planning to release the source code for the universal routine? It might be interesting material for study, and such.


From the forums at RHDN.

For those unaware, Nightcrawler has been working on a VWF library for use in SNES translations to basically give you the ability to drop a VWF in regardless of how the text engine is coded.

Title: Re: Nightcrawler's VWF
Post by Nightcrawler on Jan 14th, 2010 at 8:50am
Sorry for the delay. I was unable to type for the past month. I'm back in limited capacity for now.

We'll see how it goes and how the system turns out. It'll be in development for quite some time. It's focused on Tenshi for now. Only after that will I start test casing other games.

If I find I've met my design goals and it's practical enough, I am considering cleaning it up with some documentation for public consumption. If nothing else, I would do a limited release to those interested whom ask for it.

Perhaps Terranigma would be a good first test case outside Tenshi No Uta? :)

Title: Re: Nightcrawler's VWF
Post by Killa B on Jan 24th, 2010 at 7:38am

Nightcrawler wrote on Jan 14th, 2010 at 8:50am:
Perhaps Terranigma would be a good first test case outside Tenshi No Uta? :)

This would be many kinds of awesome.

Title: Re: Nightcrawler's VWF
Post by Nightcrawler on Jan 25th, 2010 at 8:36am
Yeah. The VWF system application should be relatively easy. The bigger obstacle here will be appropriately formatting the text to use a VWF. I don't recall off hand whether that game pulls final text from RAM or ROM. If it pulls from RAM, you can easily stick in some an auto formatting code. However, if it's from ROM, the text will likely need to be dumped, formatted, and reinserted which is significantly more work.

I'll have to remember to take a peek at this game again and see what it does. I was hoping I could just slap the VWF in and add some auto formatting code. I would probably have less interest in the project if it were more involved than that.  :-/

Title: Re: Nightcrawler's VWF
Post by KingMike on Jan 27th, 2010 at 11:48am
I'd say the VWF would be enough if you didn't want to manually format the text.
It's a pretty popular game, so I'm sure there's somebody out there who'd be willing to do that if you don't.

Title: Re: Nightcrawler's VWF
Post by Nightcrawler on Jan 28th, 2010 at 8:17am
It looks like crap without formatting the text. I believe someone already showed off some screenshots at one time. (Maybe DaMarsMan) and the text takes up only half the box horizontally. Ugly.

It is true I could probably find some grunts to do the work. Though I would still have to do the work to dump/insert the text. We're jumping ahead though. This is quite a ways away. I'm just speculating. Though it is probably the single most popular project to test the VWF on that I can think of. Might also be a good example to make some documentation on how to use it with.  :)

Title: Re: Nightcrawler's VWF
Post by Garrett on Feb 2nd, 2010 at 2:02pm
I was curious as to all SNES games were capable of a VWF. I'm not an expert nor do I know a lot about the SNES, but I recall hearing that some games have VRAM limitations or something that prevent a VWF from existing. Thus, technically the code can't be applied to all games.

BTW, love the Terranigma idea, but the purist in me says hack the japanese version and import the official script into it. I recall hearing that there was one minor difference in gameplay with the japanese version having an extra rock or something.

Title: Re: Nightcrawler's VWF
Post by Nightcrawler on Feb 3rd, 2010 at 9:00am
The answer is a bit complicated. We probably can't say all, but I would say most. Difficulty certainly varies by game. But with some ingenuity and time, most games can have a VWF.

The main limitations are VRAM space and speed. Let's talk VRAM. The game may be using all available VRAM, however it's unlikely it's all being used on the screen at once. With some extra time, you can create a hack to swap out unused data if it wasn't free already and swap it back in when needed. Easier said than done though. Doing a hack like this could be difficult if the game has any fancy effects relying on some of that VRAM data. Detection of when it's needed could be hard. Possible, yes. Sometimes not practical though.

Sometimes with item lists on a menu and what not, there's so much text on the screen at once, it just may not be possible to have enough free VRAM to hold the necessary text. With VWF, no tiles are typically reusable. So while the game used to be able to display the text no problem, it can't anymore in VWF format.

Speed is also a factor in the above case because you're dynamically redrawing an entire screens worth of tiles. If the game is already eating much of your vblank time, you can only transfer a little bit at a time and you may see screen slow down. Slowdown however won't stop the VWF from working, just make it impractical.

It's very game specific and there are several considerations. Possible and practical don't always go together either.  :)

Title: Re: Nightcrawler's VWF
Post by Nightcrawler on Jan 5th, 2011 at 8:03am
Wow, I saw I hadn't updated on this in a long while. Some people were talking about this on RHDN and I wrote a post there that ended up being a status update I may as way also put here.

I have done some work this year on this project, and even looked at applying it to Terranigma, which uses sprite based text with color manipulation. That turned out to be pretty different from what I had the routines doing already. So, after I did a little work there, I had to rethink the overall goal and design as far as practicality and speed for all applications.

As far as practicality and speed on the SNES, mileage will vary. There are several text engine scenarios on the SNES (sprite text, straight tilemap text, dynamic draw text etc.) It's definitely fine for dialog where you typically print a character per frame. It's probably OK for anything where the screen is already drawn dynamically. It's generally OK for basic menu screens too if they are fairly static, or don't fill the entire screen with walls of text.

Where you run into issues is when the original font is fully stored in VRAM and text routine was a straight tilemap to that font. The entire screen is typically rendered in a single frame, refreshed each frame in that situation. That's where you really suffer, especially if the screen is completely filled with text such as a scrolling full screen item list. It can be difficult to VWF that situation properly, even when you do a specialized routine (not even possible in some cases if you don't have enough VRAM). Add in the overhead of the universal routine and I've found it very difficult to get acceptable speeds. The more flexible I make my routine, the more overhead it incurs. So, some balance must be struck. It will certainly not be ideal for all cases. It's just not possible.

I am experimenting with several ideas to do a better global job on all situations. Rather than a true universal routine, I can be more modular where you plug in the correct function calls from a library designed to work together for the situation you need. It's not as user friendly (all you do now is define a handful of starting variables and a few things like what values to drop out of the text rendering loop with), but more practical. Another idea is perhaps there should be three VWFs to rule them all, one for each major type (sprite, straight tilemap, dynamic). Then it could be optimized for each target reducing overhead greatly.

So, there's definitely plenty left to do. In the end, it may not be something very useful to others. As an end user, there's a balance between how much time you'd need to learn my system to use effectively versus time saved from not doing it yourself. You already need to be an intermediate hacker to figure out where this routine needs to go and configure it properly. If the learning curve continues upward and requires more of the user, and may deliver slow results, one might be more inclined to do it themselves. We'll see where this experiment goes. It will definitely be useful to me if nothing else.

Title: Re: Nightcrawler's VWF
Post by RedComet on Jan 17th, 2011 at 9:32pm

Nightcrawler wrote on Jan 5th, 2011 at 8:03am:
Where you run into issues is when the original font is fully stored in VRAM and text routine was a straight tilemap to that font. The entire screen is typically rendered in a single frame, refreshed each frame in that situation. That's where you really suffer, especially if the screen is completely filled with text such as a scrolling full screen item list. It can be difficult to VWF that situation properly, even when you do a specialized routine (not even possible in some cases if you don't have enough VRAM).

I'm curious how you typically approach a situation like that. I had a huge problem with that with DBZ Hyper Dimension's character set up menu for the versus mode. What I ended up doing was creating a flag for each variable on screen and then checking if the value had changed and only redrawing the text if the value had changed. That was an annoying problem to fix.

Title: Re: Nightcrawler's VWF
Post by Nightcrawler on Jan 18th, 2011 at 3:15pm
That's a good idea. How I would approach it would definitely vary per game. In many cases, menus are static screens where you can draw once and it doesn't change frequently. Something simple is to detect and not 'draw' blank areas. In the past, I've set up a few calls to redraw the screen only when necessary (screen transitions, selecting something etc.).

Unless there is a need for a dynamic scrolling or other situation where you are forced to draw every frame, you can probably make it fast enough to not need much of the tricks above. Even a dynamic scrolling situation can be handled easily enough if it's only a partial section of the screen. Where you run into issues are those screens that have nearly a full screen of scrolling items or text requiring a redraw very frequently.

See that. Items in the middle, description at the bottom. When you have a full item list and start scrolling through, the description changes each time and entire item region changes. You've got 80% of the screen that needs to be redrawn each frame. Difficult to keep up with as opposed to say only updating a smaller portion of screen such as the description area (if that were the scrolling item list).

I suppose one could use a trick where you shift the tilemap and only actually draw the new line of items and description. That would probably work and save much time. However, that requires some intimate knowledge of the specific screen you're on. It's more difficult to do this if many screens are like this using different VRAM tile locations etc. It may be undesirable in that case.

So, there are a number of things you can do. It comes down to what's easiest for you to hack, what your needs are, and how your particular game is.

Probably none of these things can be done with the universal routine as they are really getting game specific. Raw speed is probably the only weapon there.

Title: Re: Project - nuVWF (formerly Nightcrawler's VWF)
Post by Nightcrawler on Aug 16th, 2011 at 4:02pm
I haven't worked on this project much this year. That pesky TextAngel utility and Table Standard took up way too much time. It will continue when hacking resumes on Tenshi No Uta. In addition, I have plans to try and add sprite based font support to it and ultimately use that in Terranigma. I've got a good chap or two who have volunteered in the past to do some grunt work if I do the heavy lifting. I've always enjoyed Terranigma, so I'd like to see it get a proper treatment at some point. :)

In other news, I think I will officially call this project "nuVWF". While it will officially stands for 'Nightcrawler's Universal VWF', I like the fact that you can also simply pronounce/read it like 'New VWF'!  ;D

Title: Re: Project - nuVWF (formerly Nightcrawler's VWF)
Post by Pete on Aug 18th, 2011 at 4:07am

Nightcrawler wrote on Aug 16th, 2011 at 4:02pm:
In addition, I have plans to try and add sprite based font support to it and ultimately use that in Terranigma. I've got a good chap or two who have volunteered in the past to do some grunt work if I do the heavy lifting. I've always enjoyed Terranigma, so I'd like to see it get a proper treatment at some point. :)

Don't know if this is helpful, but have a look at it: Terranigma 8X16.

Title: Re: Project - nuVWF (formerly Nightcrawler's VWF)
Post by Nightcrawler on Aug 18th, 2011 at 8:42am
Yeah, I've seen that. The problem with that is the script has not been re-formatted accordingly. I believe DaMarsMan (I think it was him) had also done some work on a VWF for Terranigma, but never re-formatted the script. So, there's still some room for improvement in my opinion. :)

Title: Re: Project - nuVWF (formerly Nightcrawler's VWF)
Post by DaMarsMan on Mar 22nd, 2012 at 7:59pm
The script was in some nasty format unlike most games I've seen. That's why I didn't go through the effort to reformat it.

Title: Re: Project - nuVWF (formerly Nightcrawler's VWF)
Post by Nightcrawler on Mar 28th, 2012 at 2:13pm
Perhaps I will take a look at Terranigma as a possible test case during further development of TextAngel. I think I have finally gotten that pesky table standard out of the way now.

Title: Re: Project - nuVWF (formerly Nightcrawler's VWF)
Post by KingMike on Mar 29th, 2012 at 11:13pm
I don't why when Nightcrawler says a "nu" VWF, the first thing I think of is the Nintendo "Ultra" 64.
(perhaps because I can recall when Nintendo Power said to have a happy "NU" year, which they hoped would end playing said console, and I thought it was one of the worst jokes ever. :P )

Title: Re: Project - nuVWF (formerly Nightcrawler's VWF)
Post by Nightcrawler on Feb 4th, 2014 at 8:31pm
I dusted off my nuVWF (Nightcrawler's Universal VWF) project to try and use for Heracles IV's 8x8 menus and screens. I think I will deem my previous incarnation a failure. The approach I took led to way too much overhead, was too difficult to implement into different games, and constantly needed to be extended more so than I anticipated to cover additional text systems and games.

My initial approach ended up turning into a universal text engine that could be dropped into any game. Implementing it into a game consisted of a lengthy user initialization routine to load all necessary game variables and locations, and then a similar closing routine to load the manipulated results back into the game. It started out well, but as I implemented several games and text systems, it wasn't long before what you were being required to do to translate/map the game's variables and data to the universal system was difficult and exhaustive. Not to mention because I ended up creating a universal text engine, I started having to duplicate many things that were already being done perfectly fine in the game already. The engine was expanded to support many things that were out of scope for a VWF. As a result, you also had to hack out and disable more and more stuff in the game, or inefficiently duplicate efforts.

All of this overhead was also causing major slowdowns. It was still fine for dialog (despite being increasing harder to implement), but an atrocity for menus or anything requiring any performance. I ended up sticking it in the closet after I implemented it into Tenshi No Uta and was unable to get any acceptable performance out of it.

Another big pitfall was for ease of user implementation, all VRAM transfers were being done in-line (meaning in normal code and not NMI). Well, there was way too much blocking associated with that (waiting for vblank) going on, crippling performance further. Then, I lost my ease of implementation over time anyway! I really should have seen that coming.

Try, Try, Try Again

I needed to take a different approach and do a redesign to salvage the project. There are still many useful core routines in place and I don't need to throw much away, but a new approach will call for new organization and usage of those routines.

This time around, I have to go for the minimalist approach. I want to leverage everything the game is already doing and be as minimally invasive as possible. I ideally want to make all transfers required to be in the NMI routine and remove any associated blocking. Although, when doing menus, you often need quite a bit of control over when tiles and data are transferred, which may result in similar waiting anyway. Perhaps I will make an option of some type to do NMI transfer queue or buffered in-line.

I think I'm also going to have to require larger chunks of RAM. These things will probably raise the bar for user knowledge to implement. However, I don't think I can make a functional system otherwise. I can make up for it a bit in other areas where there should be reduced complexity to hook into the game.

The real difficulty here is making this a system that you can drop in with a few hooks and defines rather than just a software library of VWF related routines. It has proven more difficult than I thought to make that step from simply a library of reusable VWF related routines to a glued together, fully functional system that can be dropped in with a few hooks.

Current Status

For Heracles IV usage, I'm well into my second redesign. It generally works, but I am still making continual changes for practicality and performance. I'm still not sure how I want it all to come together yet. I'm setting up some flags and trying out several different arrangements.

It's still pretty slow for real-time rendering of menus. Of course, the SNES in general just doesn't make that very feasible. It may simply make more sense for static rendering. So, I am trying to make it so that it can be enabled or disabled, or return to the game's normal tile mapping easily. The idea is you can render the things that need to be done in real time, while disabling it when need be for static rendering, or reverting to the original tile mapping if some things are to be done that way.

I will continue to see how it goes as I finish up Heracles IV and try to shove it back into Tenshi No Uta. Hopefully, I will be able to salvage the project. In the end, I may simply still end up with a set of reusable routines that may or may not be practical in a given game. Time shall see.

Title: Re: Project - nuVWF (formerly Nightcrawler's VWF)
Post by Nightcrawler on Oct 7th, 2015 at 8:29pm
I've been working on this over the past year quite a bit. I've completed my second redesign, and it was a success! I'm pretty happy with it. It's a little rough around the edges. A third version would probably make everything much nicer, but it's good and usable where it is at present.

I am currently using it for everything in both Glory of Heracles IV and Tenshi No Uta. I'm anxious to get some time to try it on some other games. The next time I post here, I will start posting details of the interface and design. There have been a ton of things going on with all of my projects and progress on everything!

Silence has not meant no work here. Just the opposite. I've been so busy working on everything and getting some help on things from others that I haven't had time for proper updating. Probably next week I will be updating the main page again and several posts in the forum.

Title: Re: Project - nuVWF (formerly Nightcrawler's VWF)
Post by Nightcrawler on Oct 13th, 2015 at 12:28pm
*NuVWF Update*


I set out to create a solution that would be able to convert static and dynamic text engines of any type (any bitplane depth, size etc), in any code variety possible on the SNES, into a VWF renderer. That's a tall order, but let's rearrange the problem. We don't really want to convert all of these possibilities to be VWF.  Rather, we want to design a way to be able to easily replace all types of existing text engines with a single VWF rendering engine. Approaching it from that angle was the key for me. This approach means we can abstract ourselves from the countless possibilities and game specific details to the fullest possible extent. It means we can focus only on the common elements that every text engine will have. If we break our system down into modules that address common elements, the result is a drop-in solution that can be hooked into any text engine at common points with minimal work. The devil is in the details of course. What are some of these common elements to think about?

Loading an input character of some bitplane depth, size, and font.
Rendering an output character.
- Rendering for static engines is simply an entry in the tilemap mapping to a static font character in VRAM.
- Rendering for dynamic engines dynamically renders characters to RAM in some output format and quantity.
Transferring rendered characters to VRAM.
- static engines do not to do this, however we will always need to do this for our VWF as it is always dynamic.

At it's core, NuVWF is an input/output VWF rendering engine coupled with an optional transfer subsystem. It renders up to 8 pixel wide characters at 8 or 16 pixel height (Linear tile ordered font chars only!). The input and output can independently be set to 1bpp, 2bpp, or 4bpp. A bit depth auto up-convert will happen when the output bpp exceeds the input. Rendering can be set to use a new internal managed ring buffer, or existing game's buffer.

Rendering Anywhere:

Easily overlooked is the fact that the system needs to be flexible enough to take input from, and render output to, any address on the system dynamically. This is a requirement to work for any game, and/or multiple text engines per game. This is tough to pull off on the SNES. Having such dynamic 24-bit and bank independence forces you to forgo most typical optimizations. You can't rely on having any memory in direct page, or any common banks between font, text, and output locations. As a result, there is significantly more overhead, and a large speed penalty. Speed while maintaining dynamic flexibility is probably the single biggest challenge. It could have been much faster if setup required you to customize various code routines, or if I set up several variations of the same routines to choose from. However, I wanted this to be a drop-in library with one set of routines, that you don't have to touch, that really does work everywhere. That was worth more to me than anything. I'd never have to write another VWF, or deal associated details of those routines again! I have attempted to mitigate the speed and overhead issue by taking a minimalist approach to the whole thing and keeping features limited, but functional enough to accomplish the goal. Some requirements on font have also been imposed to reduce complexity. It is English/Latin font centric, so supporting non-English/Latin fonts was not a consideration. I think it came out fast enough to be used in most circumstances. Certainly this can be revisited in the future. Further refinements and optimizations can surely be made!

Public Interface:

I've written up a few notes on the current public interface.

;* Settings - These need to be set here in this file by the user!
membase             = $XXXXXX   ;base offset for all nuvwf variables. Allocate $40 bytes starting here!
dmaqueue            = $XXXXXX   ;dma transfer queue offset. Each slot is 8 bytes - 0 is debug number, 1 is source bank, 2+3 is 16-bit source, 4+5 is VRAM destination, 6+7 is bytes to transfer.
!dmaqueuesize       = 0         ;size in slots (8bytes each) of dmaqueue. If limit reached, DMA will refuse to add more. Set to 0 if using external transfer method.
!dmachannel         = 0         ;dma channel to use for all dma transfers.
!blankmask          = $00       ;backsplash color - $ff (11=blank (2bpp font) or 1=blank (1bpp font)) or $00 (00=blank (2bpp font) or 0=blank (1bpp font)) .

;* Public external variables that should be set or read via user application.
rendermode          = membase       ;Can be changed at any time. -8
    !VWFMode     = 0                ;Normal VWF Rendering Mode
    !TileMapMode = 1                ;TileMapMode. Run of the mill tilemap output only. No rendering, tile counting, transfers etc.
    !StaticMode  = 2                ;No tile rendering, but positions, tile counting, and index updates. This mode assumes static data is in VRAM already by external means.
    !RenderOff   = 3                ;All output off. Rendering, positions, tiles, etc. do not update.
flag                = membase+$2    ;status flag - Bits 1,2,3 can be written. All others should be readonly -8
                                    ;Bit 7 - Last Rendered Character caused tile advance (spillover), tileindex updated for mapping.
                                    ;Bit 4 - vwfbuffer buffer full
                                    ;Bit 3 - DMA NMI mode Enable
                                    ;Bit 2 - DMA Tile/Dialog mode Enable
                                    ;Bit 1 - DMA Enable
                                    ;Bit 0 - Data Ready to Transfer (Cleared on transfer)
fontoffset          = membase+$4    ;currently used font offset -16
fontoffsetbank      = membase+$6    ;currently used font offset bank -8
vwftableoffset      = membase+$8    ;currently used vwf table offset -16
vwftableoffsetbank  = membase+$a    ;currently used vwf table offset bank -8
vwfbufferbase       = membase+$c    ;currently used vwf output ring buffer offset to be loaded for VWF RAM Output location calculation -16
vwfbufferbasebank   = membase+$e    ;currently used vwf output ring buffer offset bank -8
vrambase            = membase+$10   ;VRAM base offset for tilemap based VWF routines. -16
tilebase            = membase+$12   ;tile number base for tilemap based VWF routines. Should correspond to vram base above.-16
tileindex           = membase+$14   ;tile index for tilemap use in for tilemap based VWF routines. 0-1024 -16
vwfbuffersize       = membase+$16   ;size in bytes for vwfbuffer. Note last tile space is reserved for spillover tile. Minimum of 3 tiles space for proper ring/rollover operation.

;* Public Functions
;nuvwf_Init - Must be called on Initialization before doing anything. Call this ASAP after game start if you added the NMI hook to DMATiles.
;nuvwf_SetInputFormat  - Must be called on init and any time you change the current input font to another format.
;nuvwf_SetOutputFormat - Must be called on init and any time you wish to change the output character format.
;nuvwf_FreshTile - Can be called any time to end the current tile and move to a new tile for VWFMode. Line breaks, string ends etc.
;nuvwf_AddToDMAQueue - Call when ready to add DMA Queue slot for all currently available new tile data to transfer. String Ends, Menus Ends, etc.
;nuvwf_DMATiles - Put in NMI hook and call to transfer and flush DMA Queue. Or, you may call it manually.
;nuvwf_Render - Will Render the current character based on the rendering mode and formats. Should be called once per character.
;nuvwf_ResetBuffer - Resets renderer including vwfbuffer, transfer location, bitpos etc. If in NMI mode, will queue and flush data before reusing buffer.
;nuvwf_RingBufferRollover - Rolls over spillover to beginning of buffer and resets buffer (but NOT bitpos/bitmask). Clears buffer full.
;nuvwf_AdvanceTile  - Advances render buffer positions by x tiles/characters.

;* General Expected Usage
;set variable locations.
;include vwftable
;include font
;hook to initialize. Call to nuvwf_Init() and set all necessary variables (locations, modes, bases). Call to nuvwf_SetOutputFormat() and nuvwf_SetInputFormat()
;find font routine. Add hook to nuvwf_Render() after load character.
;application may grab resulting stored tilemap index and make sure you write that value to tilemap (as well as next value for spillover if needed).
;application may transfer VRAM buffered data. Could be NMI, could be forced transfer when buffer is full etc.
;hook for end of string, new tile/position reset etc. Call to FreshTile().

Nightcrawler's Message Board » Powered by YaBB 2.5 AE!
YaBB Forum Software © 2000-2010. All Rights Reserved.