forums.ps2dev.org

[Mega Man]

Hello,

I have a problem with gsKit and fontm. I can't print the following string correctly: "host:initrd.gz".
The character "d" is replaced by a strange letter (I think this is japanese).
On every second frame the character "g" is replaced by a dot.
I used the fontm example in gsKit and changed the main loop to:

[ragnarok2040]

I experienced the same issue with arial.fnt and lucida.fnt and fontm. Reverting to an earlier version of gsKit fixed it though, so I don't think the .fnt files are bad, but perhaps converting from the fio* based functions to stdio file functions is giving different output than what the original code expects. I'm not actually sure why it was changed.. since the fio* functions support "pfs#" based paths just as well as "mc#" and "mass". I never did look into it much since I went a different direction. Are you using the latest revision? A patch recently went in that added checks to see if a FILE pointer was NULL before trying to read from it, which fixed the exception I was getting... though it was weird since I was giving the fopen() function a valid path from the very beginning, at least I remember thinking that I was. It was a bit ago, now.

For the fontm bug, I never found a fix for the recent revision, only a workaround for revision 1386, which didn't actually work well for me. Polo35 mentioned that setting "uploaded = 0;" to "uploaded = 1;" in the gsKit_font_print_scaled() function and then copying and pasting an extra gsKit_texture_send_inline() call reduced the glitch significantly but the gsKit code has changed a lot since then so it no longer applies. He thought maybe the prim_sprite() call was a little too fast after the send_inline() call. I noticed the glitch tended to be less noticeable with the more burdens placed on the GS. The problem I was getting involved c/x (ascii 63/78 fontm 3/233) replacement, and . with a small | (ascii 46/124 fontm 4/47, I believe, but I think it wasn't a ascii mapped fontm character) and a few other anomalies.

[ps2devman]

Try avoiding any dma activity while displaying font.
Sounds strange, but issue cause is strange anyway.

[Mega Man]

Yes, I am using the latest version.
I see that fread is failing. It seems that the calculation for the variable "size" is wrong. When I remove the check for the command "fread(gsFont->Texture->Mem, size, 1, File)", it is working.
I think the code for fontm is very strange. It is very difficult to understand, how the textures are uploaded. I believe that the wrong fontm page is selected. Why is "aligned" the key for finding a texture line, "idxoffset" would be make more sense.

[Mega Man]

I looked over the code and now I am understanding what the code does. There are two pages in the VRAM used for the font. The font is not compeltely uploaded, but uploaded in small blocks. The blocks are stored in the 2 pages. The commands for uploading and drawing a char are put into a DMA queue. The queue is executed in FIFO order. So it is possible to reuse each page after a char is drawn. But I remember that I read somewhere that the GS has something like a cache. In the manual is written that a cache is used at least for the palette (CLUT is for every char the same). The chars are very small and would fit into the smallest cache and when memory is reused, we need a cache flush.
So my solution is to use the page which is not recently used for the last char. My patch is as follows:

[ooPo]

I've added this fix to the repository.

[ps2devman]

Wow! Nice brain, Mega man! Grats on finding that fix!

[Neovanglist]

Thanks!

Yea, I added this vram page feature later for fontm and didn't do extensive testing with other fonts... thus creating this timing issue.

I really appreciate the patch :)
_________________
Regards,
Neovanglist

[Mega Man]

I detected that the texture cache is bigger and my patch didn't fix it. It just reduces the error rate.
So I was looking at the GS manual. There must be a flush function and I found it. We need just to access TEXFLUSH register.
I was suprised as I saw that this is already done in the texture uploading function, but I was still sure that the error must be here.
So I checked the access against the other GS register accesses and I saw the order is incorrect.

The original code does:

*p_data++ = GS_TEXFLUSH;
*p_data++ = 0;

Other code put first the value in and then the register, so I changed it to:

*p_data++ = 0;
*p_data++ = GS_TEXFLUSH;

This solves the problem!

The bug is in 2 functions:
gsKit_texture_send
gsKit_texture_send_inline

We should leave my old patch in the code, because an LRU algorithm should lead to less uploads.

[cosmito]

Wow Mega Man

That solved (almost) the glitches I found - see http://forums.ps2dev.org/viewtopic.php?t=9012.

There is still sometimes a glitch but I was getting also some crazy letters (some charaters changing during display) and that was solved.

Thanks!

[cosmito]

I guess the changes Mega Man pointed should go into the repository. Anyone with commit rights would like to take the task?

[LBGSHI]

Agreed; though I don't have commit rights (Oobles was going to create an account for me, but I suppose never got around to it...).
_________________
I may be lazy, but I can...zzzZZZzzzZZZzzz...

[ragnarok2040]

Since I've just got done merging ntba2's libjpg interface with dlanor's and Polo's changes with libjpeg 6b-14 (with debian's patches) and a C++ header fix, I need to modify gsKit's Makefile.eeglobal to build with it so I can add the fixes while I'm doing that and make a patch. I'll investigate the reason the arial.fnt example keeps crashing too and see if I can't fix that as well :D.

Found it, division bug in fread...

[ragnarok2040]

I consolidated all of my updates into a single archive at http://homebrew.thewaffleiron.net/ragnarok2040.The updates.tar.gz package has the _ps2sdk_* stdio symbols for linking against fileXio and fileio, that updated crt0.s that was posted by chp which I've been using extensively, the last fix for gsKit by MegaMan plus a makefile.eeglobal change for libjpeg, libpng-1.2.33, zlib-1.2.3, libjpeg-6b-14 which has debian's patches with ntba2's alignment fix and ntba2's interface functions with Polo and dlanor's additions plus a C++ fix for the libjpg header,

All the gsKit examples work fine for me now :D.

[ooPo]

[ragnarok2040]

Oops, I had forgotten to add a subdirectory to my local copy of libjpeg using 'svn add' so 'svn diff' didn't include it in the libjpeg patch. I guess I just overlooked the size of the patch. I checked out the latest revision and made a new patch for it with the full update this time called libjpeg.diff.tar.gz. I also included it in updates.tar.gz. Sorry about that :/.

Edit:
fread() actually was fine, so I'll submit a patch to revert my change.I thought it was a division precision error but I guess it wasn't :D. gsKit_texture_fnt() tries to read in 262144 bytes of data (the size of the texture) but there's only 262143 bytes to be read, so fread() returns 0 like it ought have.

[ooPo]

[ragnarok2040]

That should do it. I'll see if I can't fix the font code a bit. :D