forums.ps2dev.org

I recently hacked in png/dat support for gskit, because I wanted a simple way to render alpha blended/transparent fonts. I couldn't get the spacing quite right as I had to multiply the gsFont->Additional values by 1.5 in the gskit_font_print_scaled function(). That's a ttf font converted with Bitmap Font Builder. It only takes up 6.61 kb's of space :D.

http://homebrew.thewaffleiron.net/ragna ... nap006.PNG

If anyone wants it, I can fix up the code and supply a patch later.

Edit:
Nevermind, heh. I had some free time so I grabbed the latest version of gsKit and made a patch :D. I included all the #ifdef HAVE_LIBPNG #endif's as well.

http://homebrew.thewaffleiron.net/ragna ... ont.tar.gz

To use:
I added gsFont->Path_PNG and GSKIT_FTYPE_PNG_DAT so you pretty much just use them like normal bmp/dat files. I haven't tested rendering in persistent mode, just one shot.

Thanks, it seems useful.

Thanks a bunch!

This will go into SVN very soon, I'll review it all and make sure it's merged in SVN head.

Nice work :)

I've added this patch the repository.

Nice, thanks :D.

Oh yeah, before I forget. I've been running into a NULL pointer exception error when compiling with the latest version of gsKit. I haven't been able to get printf() output from ps2link/ps2client or xlink, lately, so I'm not sure where it's occurring just that it's prior to anything being displayed on screen. It seems only to affect my v6 PS2 with a network adapter/hdd in it and not my v7 without a network adapter/hdd.

The list of functions I call prior to drawing something on screen in order (arguments clipped so it's more readable): I've been using revision 1386 which still works on both my PS2's. Maybe resetting the queue prior to drawing anything is setting it off? Though I think the crash might be happening earlier than that.

If you get an exception, try building with -g flag and using ee-addr2line to locate the problem in the source. I wrote a short tutorial on how to do so: http://lukasz.dk/programming/playstatio ... debugging/

I tried using ps2client netdump, but all ps2link would do afterwards is stall at executing the elf file without any output from either side. I couldn't use -g on all the files, as this created a 5 megabyte elf file, and ps2link would stall while executing it. I did a bunch of builds with -g on the core emulator code and -g on the ps2 frontend code, logged the exception errors I was getting from the output on the screen, and plugged them into the ee-addr2line command after compiling a full compile with -g on every source file.

The results came back to pngrtran.c:0 in libpng every time, but the source file may not be accurate if gsKit passes a null pointer to a function residing within that file. I compiled without png support in gsKit, and the exception disappears. I tried compiling libpng with the -g flag, but ps2link kept stalling when executing the elf. I commented out all the gsKit_texture_png() function calls in my program, but the exception was still occurring even though no png relevant code was called.

I hope this information helps, heh.

I'd just add printfs to debug libpng, as it seems to be causing the exception and find the bug the that way.

Alternatively, you can use ee-objdump to disassemble the ELF and find the EPC address and see if you can locate the function where the exception occours, since ee-addr2line isn't working for you.

All the exceptions just take me to different labels like 1834dc:
001834d8 <$LC127>:
1834d8: 322d5347 andi t5,s1,0x5347
1834dc: 00333130 tge at,s3,0xc4

Depending on the way I compile, the offset is always a few bytes around there. Unfortunately, it doesn't look like it says much :/. I'm guessing that's at or near the operation that causes the exception, and addr2line traces it back further... I tried tracing it back manually, but my understanding of mips assembly is pretty much nil, heh.

ragnarok2040 wrote:All the exceptions just take me to different labels like 1834dc:
001834d8 <$LC127>:
1834d8: 322d5347 andi t5,s1,0x5347
1834dc: 00333130 tge at,s3,0xc4

Depending on the way I compile, the offset is always a few bytes around there. Unfortunately, it doesn't look like it says much :/. I'm guessing that's at or near the operation that causes the exception, and addr2line traces it back further... I tried tracing it back manually, but my understanding of mips assembly is pretty much nil, heh.

I can't say I understand very much of what's happening here either, but there is one thing I do understand. It can't just be pure chance that the constant 0x5347 just happens to be the numeric interpretation of the character string "GS" ('S'==0x53 is used for MSB since it's the second character, 'G'==0x47 is used for LSB since it's the first character).

If we convert all the bytes here from longword and opcode format into hex byte sequence and string format, we get the following:

Hex Byte sequence:
47 53 2D 32 30 31 33 00

String (including NUL terminator at end):
"GS,2013"

To me it looks very much as if this 'code' is in fact a string constant.
Have you checked out all references to this label, and verified what they actually do with it ?

Best regards: dlanor

I think I found the problem. This time I cleaned my code, and rebuilt gskit the way it was, and setup everything as it was when it first occurred. The exception occurred again, then I just used a full + source intermixed objdump, then looked up the epc address, and saw that it was occurring during the switch() statement in fread, the second instruction listed in the disassembly under <fread>. This told me that fread was being passed a NULL pointer as the file stream, so I searched for all the fopen() functions in gsKit, since it returns a NULL pointer on fail. Adding a check to gsKit_texture_png() to see if File was NULL before doing anything else and returning -1 if it was, fixed the exceptions I was getting.

Lines 93, 276, 608, and 707 of gsTexture.c all use fopen(), but don't check if File is NULL prior to using the File pointer. I wasn't getting any exceptions after adding the check to gsKit_texture_png(), so I think the -g flag was making my program unstable for some reason.

I made a patch:
http://homebrew.thewaffleiron.net/ragna ... pen.tar.gz

It just adds "if (File == NULL)" statements after the fopen calls, print's an error message and returns -1 if the condition returns true.

I've added this patch to the repository.