+  RHDN Forum Archive
|-+  Romhacking
| |-+  ROM Hacking Discussion
| | |-+  VWF Explained
Pages: [1] 2
Author Topic: VWF Explained  (Read 2 times)
RedComet
Guest
« on: January 15, 2008, 01:58:06 pm »

Thought this would help any and all of you fledgling asm hackers grasp the concept of a VWF:

Quote from: Nightcrawler
Ok.. whew.. let's start with this.  If you get a good grasp on the VWF concept, your buffer size matters not.  You can work with a 8x16, 16x16 space, 32x16 etc.. and the code will be virtually the same. Your goal in theory is to keep pumping out letters to your buffer until your reach the end.  Then transfer to VRAM, start filling up the buffer again, BUT the buffer must start with the 'spill over' of the previous buffer.
 
Let's start with an easy example.  Let's use a simple 8x16 buffer. We want to print 'Time' on the screen.  'T 'is 6 pixels long and 'i' is 3 pixels long.
 
This is the beginning of the text window, so your buffer must be clear and there is no 'spillover' to print.  Now you want to print your 6 pixel wide 'T'.  So pound out those 16 bytes(assuming 1bp font).  The key to a VWF is to keep track of your pixel/buffer position.  We've printed a T.. We didn't fill up the 8x16 buffer yet, so  do NOT send to VRAM.  We mark we're on pixel 6 and call up the next letter.. 
 
It's now time to print 'i'.  Oh nuts! we only have 2 width pixels left in our 8 pixel wide buffer, and 'i' is 3 pixels!! What do we do?
 
We take our data for 'i'.. and shift each byte 6 pixels to the right.  Here's tricky part number 2.  You must 'catch' the 'spillover'. After shifting the 'i' data 6 bits over, you only have two bits of the 'i' data and the rest are 0's.  One way to 'catch' the 'spillover' is to use all 16-bits of the accumulator.  You have the low byte clear and high byte contains your 'i' data.  Now switch to 16-bit mode  and shift right 6 times.  Now the high byte has the first two pixels data of 'i' and the low byte contains your 'spillover'.. or the last pixel of the total 3 you had for 'i'.
 
SO... now you will OR your high byte data with your buffer location which had the 'T'.  Because you shifted the 'i' data by 6.. and 'T' only had 6 pixels worth, your can combine the 'i' data with 'T' data and not mess anything up.  They will combine nicely.  NOW you have a full buffer with 8 pixels of valid data.
Send it to VRAM! 
 
NOW.. the last tricky part is the start of filling up the buffer again.  Before you call a new letter, you need to take care of the one pixel 'spillover' from our 'i'.  All you do is recall the low byte result you had from our 16-bit shifting and slap that in our buffer.
 
Now.. you call the next letter.. 'm'.. and you shift that 1 pixel.. OR it with the 'i' data we just posted and repeat.. Say 'm' is only 6 bits long.  Now you combined one pixel of 'i' and 6 pixels of 'm', now you're on pixel position 7.... Buffer isn't full yet.  Call another letter! Now your 'e' will be shifted 7 times, so you'll only actually put ONE pixel of data in your OR and the rest will be spillover for next time! Transfer to VRAM.
 
Then you just keep repeating over and over! Be sure to make some sort of trap for control codes though!! Say our 'm' was a control code.. you better have some code to dump out of your routine when that happens rather than try and add it to the buffer!
 
So, you see.. it doesn't matter if your buffer is 8 pixels, 16 pixels, or 32 pixels wide, you do the same thing.  Keep calling letters until it's full.  Then transfer to VRAM and remember your 'spillover' at the start of each buffer.

Original post can be found here.
Tauwasser
Guest
« Reply #1 on: January 15, 2008, 02:48:02 pm »

Well, it's sort of a messy explanation. And the fact that he doesn't send to vram every time does not make for a good scrolling dialogue vwf imho...

For a real tutorial or anything it should be a lot clearer on terms and contain actual dataq dumps/images so the reader can grasp what it is all about Smiley

cYa,

Tauwasser
DaMarsMan
Guest
« Reply #2 on: January 15, 2008, 03:04:11 pm »

The original game should have existing send to vram code. You have to change it to fit your hack.
Nightcrawler
Guest
« Reply #3 on: January 15, 2008, 03:35:57 pm »

Yeah, the point of that post was for first timers and fitting the VWF code into th current game's framework as easily as possible. In those cases, you're going to let the game send to VRAM, which is typically after every tile, or after every 2 or 3 (for 16x16, or 12x12 respectively).

You can say 'send to VRAM' was synonymous with pass back to normal game control (which would then write to VRAM as normal) for it's intended meaning.

Anyway, it's not a tutorial. It's a single post to a single person, several years old. It's unnecessary to dissect it. That's why I have never bothered to release any tutorials ever.  Roll Eyes

Thanks Red. Tongue (I know you meant well for people it might actually help)
UglyJoe
Guest
« Reply #4 on: January 15, 2008, 03:43:53 pm »

Quote from: Nightcrawler on January 15, 2008, 03:35:57 pm
Thanks Red. Tongue (I know you meant well for people it might actually help)

I'm not actually planning on using a VWF any time soon, but your summation was good enough for me to understand the basic concept.
Bongo`
Guest
« Reply #5 on: January 15, 2008, 03:59:44 pm »

  Maybe I should rewrite my VWF tutorial... I guess it wasn't good enough...

UPDATE:
  I notice only one of my tutorials are online. The first one was not much better
but it had a pic to show what was happening the the DOC file...
« Last Edit: January 15, 2008, 04:34:25 pm by Bongo` »
DaMarsMan
Guest
« Reply #6 on: January 15, 2008, 04:00:30 pm »

Games do the DMA part different. Some use only two tiles or so and increment the VRAM position. Other games DMA the whole textbox every character. You can program it either way. To me, the whole textbox area is easier if you have enough extra room in RAM. If not the other will work but requires a couple more variables.

I really didn't like the VWF tutorials and sources in our database. I may write one when I do my first VWF hack.
KaioShin
Guest
« Reply #7 on: January 15, 2008, 04:55:41 pm »

I remember this post well, and helped me quite a bit when I wrote my own VWF. As I always say, I find concept explanations much more valuable that example code (which is still the only thing we have in the database for the topic!).

It would be cool if someone would write a proper document on the topic. I'd do it myself, but I don't think one vwf is nearly enough experience to do an adequate job for it.
RedComet
Guest
« Reply #8 on: January 15, 2008, 07:04:08 pm »

Quote from: Nightcrawler on January 15, 2008, 03:35:57 pm
Thanks Red. Tongue (I know you meant well for people it might actually help)

In my defense I know of at least two people now other than myself who have said your explanation helped them understand how a VWF works. I thought it'd be nice if it were in a place where it could help more. Smiley
MathOnNapkins
Guest
« Reply #9 on: January 15, 2008, 11:47:21 pm »

VWF was one of the first things I stumbled upon in reading old irc logs found on Google circa 2002-3 (probably Gideon Zhi schooling some newbie). Though, I must say I had no freaking clue what it was, and it held no value for me either, since I wanted to hack other things. That discussion actually helped me figure out how to convert SNES rom adress to cpu addresses. I was totally lost up until then.
Nightcrawler
Guest
« Reply #10 on: January 16, 2008, 08:33:53 am »

Quote from: RedComet on January 15, 2008, 07:04:08 pm
Quote from: Nightcrawler on January 15, 2008, 03:35:57 pm
Thanks Red. Tongue (I know you meant well for people it might actually help)

In my defense I know of at least two people now other than myself who have said your explanation helped them understand how a VWF works. I thought it'd be nice if it were in a place where it could help more. Smiley

Sure. It's helped a good number of people. I get periodic requests to dig it up for people, even now. It seems to be explained at just the right level conceptually to lend itself well to people who have a hard time grasping what's really going on and what they need to do for a VWF hack. No other readily available explanations seem to hit that particular mark I guess. I should have been a teacher. Smiley
DarknessSavior
Guest
« Reply #11 on: January 16, 2008, 08:36:58 am »

You should've been a teacher NC. =D

Seriously though, no real good conceptual guide exists for a VWF. Gemini wrote something about it, but it's in Italian, and since the Stealth Translations one helped him learn to make VWFs, he believes it is golden, and won't translate his guide. >.>

~DS
tomaitheous
Guest
« Reply #12 on: January 16, 2008, 11:01:05 am »


 VWF is the natural proceeding step/level from hacking FWF routines, right? I don't want to sound like a jerk, but the logic behind VWF logic itself is pretty simple and I don't really see the need for a tutorial. If one *has* experience with assembly and has done quite a few ASM level FWF print routine hacks, then VWF shouldn't be a problem. Nightcrawler's explanation is fine. All you really need is the basic concept to give you the idea/starting point.
MathOnNapkins
Guest
« Reply #13 on: January 16, 2008, 11:56:38 am »

Just out of curiosity are there any special tricks to optimizing the speed of a VWF (on SNES specifically)? I sort of tried a few things but it didn't end up being much faster maybe a 10% increase in speed at best. I can get about 10-16 characters outputted per frame, depending on their widths. Their old approach was a pixel by pixel generator, so I attempted to do the whole 8 pixels of a line at once. But after configuring all the bit masks the end result is less than I had hoped for. (For reference, the game is Zelda: A Link to the Past for SNES). It seemed easy to speed up at first, until I realized, yes, I also have to draw blank (transparent) space, not just the actual text graphics. Maybe some trickery with DMA and register $2180? I thought about using $2180 with a table (or maybe more than one table depending on the approach you take).
Nightcrawler
Guest
« Reply #14 on: January 16, 2008, 12:47:33 pm »

I'm not sure I follow what your problem is. I'd say yes, there's usually always some things you do for a speed up. You have to first identify what the current bottleneck is.

How often are you writing to VRAM? What are you writing each time and when do you increment the position? How are you writing to VRAM? I'd definitely suggest using DMA in every case. $2180 probably won't help much.

8 pixels of a line at once? A line of text? I'm confused. I don't know why would you be doing that.

Pages: [1] 2  


Powered by SMF 1.1.4 | SMF © 2006-2007, Simple Machines LLC