Welcome, Guest. Please Login or Register
 
The Purple Parade is marching in full stride to the beat of that 'other' drum we all hear, but generally ignore. Wink
Home Help Search Login Register


Pages: 1 2 
Send Topic Print
Project - nuVWF (formerly Nightcrawler's VWF) (Read 18422 times)
KingMike
Circle of Royalty
*****
Offline


BRAAAIIINS!

Posts: 576
Gender: male
Re: Nightcrawler's VWF
Reply #15 - 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.
Back to top
 
WWW 124792925  
IP Logged
 
Nightcrawler
YaBB Administrator
*****
Offline


The Dark Angel of Romhacking

Posts: 3219
USA
Gender: male
Re: Nightcrawler's VWF
Reply #16 - 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.  Smiley
Back to top
 

ROMhacking.net - The central hub of the ROM hacking community.
WWW  
IP Logged
 
Garrett
Peasant
*
Offline


I Love TransCorp!

Posts: 26
Re: Nightcrawler's VWF
Reply #17 - 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.
Back to top
 
 
IP Logged
 
Nightcrawler
YaBB Administrator
*****
Offline


The Dark Angel of Romhacking

Posts: 3219
USA
Gender: male
Re: Nightcrawler's VWF
Reply #18 - 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.  Smiley
Back to top
 

ROMhacking.net - The central hub of the ROM hacking community.
WWW  
IP Logged
 
Nightcrawler
YaBB Administrator
*****
Offline


The Dark Angel of Romhacking

Posts: 3219
USA
Gender: male
Re: Nightcrawler's VWF
Reply #19 - 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.
Back to top
 

ROMhacking.net - The central hub of the ROM hacking community.
WWW  
IP Logged
 
RedComet
Peasant
*
Offline



Posts: 40
Kentucky
Gender: male
Re: Nightcrawler's VWF
Reply #20 - 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.
Back to top
 
WWW  
IP Logged
 
Nightcrawler
YaBB Administrator
*****
Offline


The Dark Angel of Romhacking

Posts: 3219
USA
Gender: male
Re: Nightcrawler's VWF
Reply #21 - 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.

http://transcorp.parodius.com/newsimages/newsimage88d.png

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.
Back to top
 

ROMhacking.net - The central hub of the ROM hacking community.
WWW  
IP Logged
 
Nightcrawler
YaBB Administrator
*****
Offline


The Dark Angel of Romhacking

Posts: 3219
USA
Gender: male
Re: Project - nuVWF (formerly Nightcrawler's VWF)
Reply #22 - 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. Smiley

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'!  Grin
Back to top
 

ROMhacking.net - The central hub of the ROM hacking community.
WWW  
IP Logged
 
Pete
Peasant
*
Offline


I Love TransCorp!

Posts: 3
Re: Project - nuVWF (formerly Nightcrawler's VWF)
Reply #23 - 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. Smiley


Don't know if this is helpful, but have a look at it: Terranigma 8X16.
http://www.romhacking.net/hacks/684/
Back to top
 
 
IP Logged
 
Nightcrawler
YaBB Administrator
*****
Offline


The Dark Angel of Romhacking

Posts: 3219
USA
Gender: male
Re: Project - nuVWF (formerly Nightcrawler's VWF)
Reply #24 - 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. Smiley
Back to top
 

ROMhacking.net - The central hub of the ROM hacking community.
WWW  
IP Logged
 
DaMarsMan
Nobleman
***
Offline



Posts: 163
Re: Project - nuVWF (formerly Nightcrawler's VWF)
Reply #25 - 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.
Back to top
 

Dragon Quest 5 for ps2 hacker/translator....&&
WWW  
IP Logged
 
Nightcrawler
YaBB Administrator
*****
Offline


The Dark Angel of Romhacking

Posts: 3219
USA
Gender: male
Re: Project - nuVWF (formerly Nightcrawler's VWF)
Reply #26 - 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.
Back to top
 

ROMhacking.net - The central hub of the ROM hacking community.
WWW  
IP Logged
 
KingMike
Circle of Royalty
*****
Offline


BRAAAIIINS!

Posts: 576
Gender: male
Re: Project - nuVWF (formerly Nightcrawler's VWF)
Reply #27 - 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. Tongue )
Back to top
 
WWW 124792925  
IP Logged
 
Nightcrawler
YaBB Administrator
*****
Offline


The Dark Angel of Romhacking

Posts: 3219
USA
Gender: male
Re: Project - nuVWF (formerly Nightcrawler's VWF)
Reply #28 - 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.
Back to top
 

ROMhacking.net - The central hub of the ROM hacking community.
WWW  
IP Logged
 
Pages: 1 2 
Send Topic Print
(Moderator: Nightcrawler)