I think I know the name of that font for DQ8 or at least one similar to it. I'm using it for DQ5. It probably isn't going to look as good in a smaller size though. I'll post what it is when I get home. Also, you need to create a simple tool to copy your block of code into the gba rom in a single click. I think we have one in our database. That way when you compile, all you have to do is double click a batch file and start the rom.

The font is called Palatino and now that i look at it it's a little wider than DQ8 but similar.

break up r1 into bits. 4 bits per nibble (digit).

1000 0100 0000 0000 0000 0000 0000 0001

Like it says it's storing a word. So we ignore the first 16 bits. Leaving us with.

0000 0000 0000 0001

So let's look at our table...I believe that bit 0 is the left most bit. Our table says 0-4 arean't used. So all we have is.

000 0000 0001

value of 5-6 is 0 so we are using regular increments for the starting adress to copy from.
value of 7-8 is 0 so we are using regular increments for our destination address (vram in this case).
value at 9 is 0 because we aren't repeating DMA. It's a one shot thing in this case.
value at 10 is 0 which means we are transferring 16bit's at a time.
value at 11 is 0 for normal gamepak (don't know what this is but i'm sure it's almost always 0)
value at 12-13 is 0 to start DMA immediately and copy right away.
value at 14 is 0 so IRQ interrupt disabled.
value at 15 is 1 to enable our dma.



Some of this stuff is guessing but it looks pretty similar to what I have seen on SNES. So what happens is whenever a 1 is written to that 15th bit, the cpu starts a DMA transfer with the values. Now what you need to do is check that document and find out where the location for the DMA address to copy from and to are stored. It's probably a register that was already written to. So you are going to need to find where that is and change the starting address to copy from to you position of your VWF tiles in RAM.

Source and Destination are right before that. They are set correctly, that's why I don't understand why nothing gets send to VRAM. Ok, it turns out I used the wrong control word. It must be 84000010 not 01 at the end. Now I've got the tile in VRAM. I think I've got them reversed. I tried to combine i with n and half of n was at the beginning followed by a slightly messed up i. The mess up is propably because I didn't use a real width table yet but instead just used 5 for all widths. I think I'll try to chose a final font now, so I can make a real width table for further testing.

Thanks for your continued help DaMarsMan and Red

Well, it's only 2 tiles^^ I didn't run a whole string through my routine. I haven't replaced the routine completely yet, so I have to jump to it with the debugger manually.



With some fantasy that's the right half of a n with a i plus messed up dot, don't you think?^^

What do you guys think, this looks very very close to the DQVIII font to me:



But only with Font Smoothing enabled, without it's kind of blurry, but that may be for other reasons? I hope I can transfer this into the game without messing the font up, I hate all kind of image editing >_<


Yeah, but I find it much easier to test with a real font since I immediately see if it's correct or wrong. In the end I'll have to insert a font anyway, so why not do it now? If there are problems related to the width stuff I'll know while debugging (hopefully^^).

I have accounted for that in my code, but I haven't tested it yet, maybe it works already, maybe not. I'll see when I got that font in.


 

Thanks!

Yeah, I'm already noticing this >_<.

Does anyone know a good 8x16 vwf which might come out good on the GBA?

Ok I inserted a proper font now and created a width table for it. Now I can do some real debugging. I immediately notice, more than 2 letters on one tile won't work (I haven't look into why yet). The more severe problem - combining two tiles doesn't work either. It seems as if the endianess kills it. If a row is 17 11 11 11 in RAM and I copy it into a register it will become 11 11 11 17. The first variant was the right one. What should I do now? Save the font in reverse byte order? Can I do that easily with a modified tile definition for FEIDIAN? Any other suggestions?
The DMA routine copies the data stright into VRAM, the original font is stored in normal byte order and it will appear normal in VRAM as well there.

Edit: Just thought about something. Would it be enough to reverse my shifts? Turn all right shifts into left ones and vice versa? Because, when the registers are saved back the bytes are in right order again.

Ok, seems as if exchanging shifts took care of that problem for now. I now know the problem why tiles which consist of more than 2 characters don't work yet and I expect another problem to arise.

Let's examine how a row of pixels is stored on the GBA. Every nibble presents one pixel, however, the ordering is not so straigth forward.


Second Pixel ->     17h    <- First Pixel.

So, the Bytes are reversed, the first nibble is the second pixel and the second nibble is the first pixel. I think my code only works as long as the number of pixels to shift is even. For an uneven pixelcount it propably cuts out the column with the last pixel instead of the column after that. Does anyone know how I can adjust my shift logic to take this into account? I couldn't come up with anything yet. A workaround I thought of was to have every character an even pixel count, but that would be cheating a bit :p

I'll look into the problem with tiles with more than 2 characters for now, I hope in the meantime someone can give me advise on the shifting problem.

Thanks