gsKit Development and Discussion Thread
-
- Site Admin
- Posts: 72
- Joined: Sat May 22, 2004 9:29 pm
- Location: Copenhagen, Denmark
- Contact:
Ok I grabbed the svn version. I compiled it ok but I'm having trouble creating a proper rgba integer.
This code
Works.
This code
does not.
I have two quads being drawn, with slight overlap, and I wish to make to make the second(Overlapping) rect alpha blend in, so I do this,
But it's not transparant at all. Am I shifting the alpha the appropriate amount?
I know gsKit has a built in function but it uses hex, something I'm not too familar with.
Meg!? :)
This code
Code: Select all
uint64 MakeRgb(int r,int g,int b)
{
return ((uint64)(r) <<0) | ((uint64)(g) << 8) | ((uint64)(b) << 16);
}
This code
Code: Select all
uint64 MakeRgba(int r,int g,int b,int a)
{
return ((uint64)(r) <<0) | ((uint64)(g) << 8) | ((uint64)(b) << 16) | ((uint64)(a) << 32);
}
I have two quads being drawn, with slight overlap, and I wish to make to make the second(Overlapping) rect alpha blend in, so I do this,
Code: Select all
gsKit_prim_sprite(gsGlobal, 100.0f, 100.0f, 200.0f, 200.0f, 5, MakeRgba(128,128,128,128));
I know gsKit has a built in function but it uses hex, something I'm not too familar with.
Code: Select all
the version in the SVN is the 0.3 (beta something), it's definitely the most up-to-date version, so the answer is YES !
Ha, no, the function has nothing to do with hex... Hex and decimal can be used more or less interchangably in C/C++Kojima wrote: I know gsKit has a built in function but it uses hex, something I'm not too familar with.
Shoot Pixels Not People!
Makeshift Development
Makeshift Development
The last shift constant is incorrect. It should be 24 instead of 32.Kojima wrote:does not.Code: Select all
uint64 MakeRgba(int r,int g,int b,int a) { return ((uint64)(r) <<0) | ((uint64)(g) << 8) | ((uint64)(b) << 16) | ((uint64)(a) << 32); }
No.I have two quads being drawn, with slight overlap, and I wish to make to make the second(Overlapping) rect alpha blend in, so I do this,
But it's not transparant at all. Am I shifting the alpha the appropriate amount?Code: Select all
gsKit_prim_sprite(gsGlobal, 100.0f, 100.0f, 200.0f, 200.0f, 5, MakeRgba(128,128,128,128));
The four ABGR components should each have one byte out of the lower 32-bit word of that 64-bit value. So for this usage (no Q) the upper 32 bit word should be zero, but that's where you place the alpha value. So in a way, what you have there is really 'MakeRgbq' instead of 'MakeRgba'.
I'm not sure which function you mean, but the obvious tool to use here is the macro GS_SETREG_RGBA(r, g, b, a), which performs exactly the operation you need, and without any function calls. And when you're using constants (like above), the compiler should even be able to perform the entire calculation at compile time, so that the runtime code only contains a simple load of the combined constant to a register. That can save a lot of time compared to your explicit function calls...I know gsKit has a built in function but it uses hex, something I'm not too familar with.
I think you should have a look in gsinit.h, where that macro (and lots of other stuff) is defined.
Best regards: dlanor
-
- Posts: 83
- Joined: Wed Jul 13, 2005 12:25 am
Any news on the new version?
I'm still having text display problems, letters being distorted, screen flickering because the letters can't decide what they want to be; and sometimes it just cuts off a part of the screen.
This is really the only thing stopping me from releasing an irc client I made, the fact that you can't read any of the messages/text on the screen.
I'm using the built in font, and my ps2 is a NTSC V7(don't think that matters, but hey, can't hurt to add it)
Also a small side question, should I be in persistent or oneshot mode when drawing text?
I'm still having text display problems, letters being distorted, screen flickering because the letters can't decide what they want to be; and sometimes it just cuts off a part of the screen.
This is really the only thing stopping me from releasing an irc client I made, the fact that you can't read any of the messages/text on the screen.
I'm using the built in font, and my ps2 is a NTSC V7(don't think that matters, but hey, can't hurt to add it)
Also a small side question, should I be in persistent or oneshot mode when drawing text?
Hey,
I'm actualy playing with gsKit font on ULE, and i encountered the same problem Ubergeek42 have. :(
All chars have a very bad quality, and are not readable. :(
Could someone help us, please.
@Ubergeek: Did you find something conserning this problem, because i saw you release a first version of you irc client. ;)
I use fnt font format.
Here a screenshot of ULE with gsKit font use, it's in non-interlaced mode, because interlaced mode flicker a lot with gsKit font. :(
All chars are printed one by one, because some of them are only in ULE build-in font and are printed with ULE fonction ( like O, X, ... which you can see on the pic quality is better ).
But top line ( Just a little test. ) is a 'standard' print ( from a string in a char* ).
I've enable alphablending like alpha example do, because text was print with a black background if i follow the font example.
I think the problem is here because when alpha is off, there is a black square under the char but quality is good.
Here drawChar fonction:
Help, please. ;)
Other point, like Ubergeek i'd like to know what's the way to create a proper fnt file for gsKit?
Best regards
Polo
I'm actualy playing with gsKit font on ULE, and i encountered the same problem Ubergeek42 have. :(
All chars have a very bad quality, and are not readable. :(
Could someone help us, please.
@Ubergeek: Did you find something conserning this problem, because i saw you release a first version of you irc client. ;)
I use fnt font format.
Here a screenshot of ULE with gsKit font use, it's in non-interlaced mode, because interlaced mode flicker a lot with gsKit font. :(
All chars are printed one by one, because some of them are only in ULE build-in font and are printed with ULE fonction ( like O, X, ... which you can see on the pic quality is better ).
But top line ( Just a little test. ) is a 'standard' print ( from a string in a char* ).
I've enable alphablending like alpha example do, because text was print with a black background if i follow the font example.
I think the problem is here because when alpha is off, there is a black square under the char but quality is good.
Here drawChar fonction:
Code: Select all
void drawChar(unsigned char c, int x, int y, u64 colour)
{
gsGlobal->PrimAlphaEnable = GS_SETTING_ON;
gsKit_set_primalpha(gsGlobal, GS_SETREG_ALPHA(0,1,0,1,0), 0);
gsKit_set_test(gsGlobal, GS_ATEST_OFF);
gsKit_font_print(gsGlobal, gsFont, x, y, 1, colour, &c);
gsKit_set_test(gsGlobal, GS_ATEST_ON);
gsKit_set_primalpha(gsGlobal, GS_BLEND_BACK2FRONT, 0);
gsGlobal->PrimAlphaEnable = GS_SETTING_OFF;
}
Other point, like Ubergeek i'd like to know what's the way to create a proper fnt file for gsKit?
Best regards
Polo
-
- Posts: 83
- Joined: Wed Jul 13, 2005 12:25 am
The problem I was having was actually with fontm, which is the font built into the bios, and used for the dvd subtitles(I think).
For my irc client, I gave up on fontm, and switched to a 256x256 bmp image containing all the letters. I can't remember if I used the built in functions for using a bitmap font, but I think I made my own.
I also modified the load texture function for bitmaps to load from an embedded buffer, so I wouldn't have to depend on external files.
I forget if im in interlace or not, but im pretty sure I don't explicitly set it to something, so it should be the gsKit default.
I also am unsure about the alpha stuff...since I use a black background, although I will need to change this soon, when I add in custom color abilities and background images.
Same with the fnt file, I tried to make one at some point, couldn't figure it out.
For my irc client, I gave up on fontm, and switched to a 256x256 bmp image containing all the letters. I can't remember if I used the built in functions for using a bitmap font, but I think I made my own.
I also modified the load texture function for bitmaps to load from an embedded buffer, so I wouldn't have to depend on external files.
I forget if im in interlace or not, but im pretty sure I don't explicitly set it to something, so it should be the gsKit default.
I also am unsure about the alpha stuff...since I use a black background, although I will need to change this soon, when I add in custom color abilities and background images.
Same with the fnt file, I tried to make one at some point, couldn't figure it out.
Hey,
First of all, i've to say, we ( ULE developers ) have just released the first version of ULaunchELF using gsKit lib.
I'm here to report a trouble found in this new version of ULE. :(
We found a bug in our text editor, sometime editor completly crash the prog.
After some investigation for debugging this problem, we found gsKit is responsible.
If a text contain more them 1800 chars in first 'page', prog crash.
I mean gsKit is not able to print more then 1800 chars on screen.
So, to give more infos:
In ULE, gsKit is initialize with PrimAAEnable ON, DoubleBuffering OFF, ZBuffering OFF and mode ONESHOT.
Other parameters are initialized with 'standard' init.
ULE load a screen_width*screen_height texture for background, we always load it at gsGlobal->CurrentPointer=0x140000.
Chars are printed pixel by pixel from ULE font, and with ULE fonctions.
I mean with a call to 'gsKit_prim_point' for each pixel of each chars.
Like Dlanor say: "The solution I hope for is a method for rendering gsKit_* commands to the real screen buffers gradually, instead of doing it all at once in "drawScr" like we do now, because it is precisely this 'all at once' method which has created the problem."
@Neovanglist, or other gsKit author: Thanks to contact us to solve tis problem.
Best regads
Polo
First of all, i've to say, we ( ULE developers ) have just released the first version of ULaunchELF using gsKit lib.
I'm here to report a trouble found in this new version of ULE. :(
We found a bug in our text editor, sometime editor completly crash the prog.
After some investigation for debugging this problem, we found gsKit is responsible.
If a text contain more them 1800 chars in first 'page', prog crash.
I mean gsKit is not able to print more then 1800 chars on screen.
So, to give more infos:
In ULE, gsKit is initialize with PrimAAEnable ON, DoubleBuffering OFF, ZBuffering OFF and mode ONESHOT.
Other parameters are initialized with 'standard' init.
ULE load a screen_width*screen_height texture for background, we always load it at gsGlobal->CurrentPointer=0x140000.
Chars are printed pixel by pixel from ULE font, and with ULE fonctions.
I mean with a call to 'gsKit_prim_point' for each pixel of each chars.
Like Dlanor say: "The solution I hope for is a method for rendering gsKit_* commands to the real screen buffers gradually, instead of doing it all at once in "drawScr" like we do now, because it is precisely this 'all at once' method which has created the problem."
@Neovanglist, or other gsKit author: Thanks to contact us to solve tis problem.
Best regads
Polo
i whant gskit help
i want gskit lib help
eny body can helpme? i donloawd the gskit from ps2dev but i cant find her library in folder lib."libgskit.a","libdmakeit.a".
plus this versions not have documantion
eny body can helpme? i donloawd the gskit from ps2dev but i cant find her library in folder lib."libgskit.a","libdmakeit.a".
plus this versions not have documantion
I found a bug in the font loader for bmp/dat files. The Path_BMP and Path_DAT members of GSFONT are never defined. It's an easy fix but was annoying until I found the problem.
I fixed it with
in gsFont.c
Also, I don't know what other program you use to make bmp/dat pairs, but I use Bitmap Font Builder. The current version uses 16 bits for the width of characters instead of 8 so I modified the code to load the dat to a temp array, then copy the widths one by one into Additional as u8s.
I fixed it with
Code: Select all
else if( gsFont->Type == GSKIT_FTYPE_BMP_DAT ) //original line
{
gsFont->Path_BMP=calloc(1,strlen(gsFont->Path)+4);
gsFont->Path_DAT=calloc(1,strlen(gsFont->Path)+4);
sprintf(gsFont->Path_BMP,"%s.bmp",gsFont->Path);
sprintf(gsFont->Path_DAT,"%s.dat",gsFont->Path);
if( gsKit_texture_bmp(gsGlobal, gsFont->Texture, gsFont->Path_BMP) == -1 ) //original line
Also, I don't know what other program you use to make bmp/dat pairs, but I use Bitmap Font Builder. The current version uses 16 bits for the width of characters instead of 8 so I modified the code to load the dat to a temp array, then copy the widths one by one into Additional as u8s.
Code: Select all
gsFont->Additional=malloc( 0x100 );
u16 temp_buffer[512];
if (File > 0)
{
fioLseek(File, 0, SEEK_SET);
if(fioRead(File, &temp_buffer, 0x200) <= 0)
{
printf("Could not load font sizes: %s\n", gsFont->Path_DAT);
return -1;
}
fioClose(File);
for (i = 0; i < 0x100; i++)
{
gsFont->Additional[i] = (u8)temp_buffer[i];
}
}
-
- Site Admin
- Posts: 72
- Joined: Sat May 22, 2004 9:29 pm
- Location: Copenhagen, Denmark
- Contact:
-
- Site Admin
- Posts: 72
- Joined: Sat May 22, 2004 9:29 pm
- Location: Copenhagen, Denmark
- Contact:
Could you post this in udiff format against the current SVN?KaylaKaze wrote:I found a bug in the font loader for bmp/dat files. The Path_BMP and Path_DAT members of GSFONT are never defined. It's an easy fix but was annoying until I found the problem.
I fixed it with
in gsFont.cCode: Select all
else if( gsFont->Type == GSKIT_FTYPE_BMP_DAT ) //original line { gsFont->Path_BMP=calloc(1,strlen(gsFont->Path)+4); gsFont->Path_DAT=calloc(1,strlen(gsFont->Path)+4); sprintf(gsFont->Path_BMP,"%s.bmp",gsFont->Path); sprintf(gsFont->Path_DAT,"%s.dat",gsFont->Path); if( gsKit_texture_bmp(gsGlobal, gsFont->Texture, gsFont->Path_BMP) == -1 ) //original line
Also, I don't know what other program you use to make bmp/dat pairs, but I use Bitmap Font Builder. The current version uses 16 bits for the width of characters instead of 8 so I modified the code to load the dat to a temp array, then copy the widths one by one into Additional as u8s.Code: Select all
gsFont->Additional=malloc( 0x100 ); u16 temp_buffer[512]; if (File > 0) { fioLseek(File, 0, SEEK_SET); if(fioRead(File, &temp_buffer, 0x200) <= 0) { printf("Could not load font sizes: %s\n", gsFont->Path_DAT); return -1; } fioClose(File); for (i = 0; i < 0x100; i++) { gsFont->Additional[i] = (u8)temp_buffer[i]; } }
If so I'll merge it into the gsKit code and add you to the contributors section.
Thanks!
(I don't really use the GSFONT stuff much so it's no suprise there are bugs in it)
Regards,
Neovanglist
Neovanglist
-
- Site Admin
- Posts: 72
- Joined: Sat May 22, 2004 9:29 pm
- Location: Copenhagen, Denmark
- Contact:
The issue is just that it has a sprite prim for each character - and also if the character is not in the same texture page that is currently in VRAM it has to upload a new one :)Polo35 wrote:Hey,
First of all, i've to say, we ( ULE developers ) have just released the first version of ULaunchELF using gsKit lib.
I'm here to report a trouble found in this new version of ULE. :(
We found a bug in our text editor, sometime editor completly crash the prog.
After some investigation for debugging this problem, we found gsKit is responsible.
If a text contain more them 1800 chars in first 'page', prog crash.
I mean gsKit is not able to print more then 1800 chars on screen.
So, to give more infos:
In ULE, gsKit is initialize with PrimAAEnable ON, DoubleBuffering OFF, ZBuffering OFF and mode ONESHOT.
Other parameters are initialized with 'standard' init.
ULE load a screen_width*screen_height texture for background, we always load it at gsGlobal->CurrentPointer=0x140000.
Chars are printed pixel by pixel from ULE font, and with ULE fonctions.
I mean with a call to 'gsKit_prim_point' for each pixel of each chars.
This can eat up your drawchain superfast if you have thousands of characters onscreen at once.
The solution is exactly what you did... just increase the size of your oneshot drawbuffer, and optionally you can turn down the size of the persistent drawbuffer.
Regards,
Neovanglist
Neovanglist
-
- Site Admin
- Posts: 72
- Joined: Sat May 22, 2004 9:29 pm
- Location: Copenhagen, Denmark
- Contact:
Also... I'm looking into this FONTM strangeness...
I really can't figure it out at the moment, it seems extremely tempermental.
It's not specific to any one character.. and it only happens under strange conditions.
I think it's something texture address/DMA related, but I'm really not sure yet.
I'll let you guys know when I've sorted it out.
I really can't figure it out at the moment, it seems extremely tempermental.
It's not specific to any one character.. and it only happens under strange conditions.
I think it's something texture address/DMA related, but I'm really not sure yet.
I'll let you guys know when I've sorted it out.
Regards,
Neovanglist
Neovanglist
I designed a new font type I'm currently calling Alpha Font. It's an 8-bit TGA/DAT combo (like the bmp_dat font) but it loads the TGA into the alpha channel and uses a solid white as the RGB portion of the font texture. This allows the font to be antialiased on the edges and be transparent in the black area (which is something I couldn't get BMP_DAT to do). The TGA handling isn't very sturdy though so right now it only works with the 8-bit TGA files exported from Bitmap Font Builder.
-
- Site Admin
- Posts: 72
- Joined: Sat May 22, 2004 9:29 pm
- Location: Copenhagen, Denmark
- Contact:
Why would you use TGA and deal with the unpacking if you could just use straight RBGA?
One of the reasons BMP was used is because it's pretty straightforward... I'd think it would be easier to just use a RBGA or palleted glyphset, then simply use the provided alpha channel.
With fontm, the glyphset itself is just a T4 texture and a greyscale ramp pallete with linear alpha. (I note this in the codedoc in gsKit)
That seems the most straight-forward way to do it to me, because then you can even substitute the pallete to get different color fonts, etc... which looks quite nice :)
One of the reasons BMP was used is because it's pretty straightforward... I'd think it would be easier to just use a RBGA or palleted glyphset, then simply use the provided alpha channel.
With fontm, the glyphset itself is just a T4 texture and a greyscale ramp pallete with linear alpha. (I note this in the codedoc in gsKit)
That seems the most straight-forward way to do it to me, because then you can even substitute the pallete to get different color fonts, etc... which looks quite nice :)
Regards,
Neovanglist
Neovanglist
BFB creates uncompressed TGA files, while the BMP it outputs are based on screen colordepth. Basically, the BFB TGA 8-bit file is just a file header followed by 1 byte per pixel (non-flipped) raw data which I feed directly into the alpha channel (actually, I think I had to do 0x80-(image[x+y*width]>>1) because of the PS2's alpha being 4-bits instead of 8 (or something like that)). So I didn't have to mess with compression or anything.
This method does allow for the font color to be changed the exact same way as the other fonts (based on the color passed in the print command). It was my understanding that FONTM is read from the PS2 system, not an external font. Using this, you can create your own fonts from any TrueType Font and still (as far as I can see) get the benefits of using FONTM.
This method does allow for the font color to be changed the exact same way as the other fonts (based on the color passed in the print command). It was my understanding that FONTM is read from the PS2 system, not an external font. Using this, you can create your own fonts from any TrueType Font and still (as far as I can see) get the benefits of using FONTM.
Is FONTM blocking progress?
Dear Neovangelist... Congrats for your nice library.
Like many, I've suffered atrocious impossible to understand nasty DMA alterations while using FONTM, and of course, like others, I've finally used my own textures instead (in my case data exchanged between packet driver and tcp/ip stack became literally corrupted).
In your status file, we can guess you are blocked with that nasty dma issue, and the VU related planned work is left unreachable for now.
Don't you think FONTM could be just put as an external texture as a workaround for now? (a call to export data outside, and functions use them as external texture to upload - which proved to work perfectly)
That part is not so essential to us. I know it's raging to not detect an issue in one's code, but when I see dates on posts it seems you suffer from it for too long now.
I think your future VU related work will be much more exciting...
Keep the good work!
Like many, I've suffered atrocious impossible to understand nasty DMA alterations while using FONTM, and of course, like others, I've finally used my own textures instead (in my case data exchanged between packet driver and tcp/ip stack became literally corrupted).
In your status file, we can guess you are blocked with that nasty dma issue, and the VU related planned work is left unreachable for now.
Don't you think FONTM could be just put as an external texture as a workaround for now? (a call to export data outside, and functions use them as external texture to upload - which proved to work perfectly)
That part is not so essential to us. I know it's raging to not detect an issue in one's code, but when I see dates on posts it seems you suffer from it for too long now.
I think your future VU related work will be much more exciting...
Keep the good work!