Page 1 of 1
bad 16bits texture display
Posted: Tue Apr 22, 2008 7:26 am
by kouky
I'm getting my first interesting results with gsKit, but it's still not perfect.
I'm displaying a GSTEXTURE onto a "gsKit_prim_sprite_texture".
the graphics data is on RGB 5 5 5 format, is 320x240 pixels and comes from an array of 320x240x unsigned short.
my settings:
Code: Select all
fb[0].Width = 320;
fb[0].Height = 240;
fb[0].PSM = GS_PSM_CT16S;
fb[0].Mem = memalign(128, gsKit_texture_size_ee(fb[0].Width, fb[0].Height, fb[0].PSM));
fb[0].Vram = gsKit_vram_alloc(gsGlobal, gsKit_texture_size(fb[0].Width, fb[0].Height, fb[0].PSM), GSKIT_ALLOC_USERBUFFER);
I'm getting this :
But it's supposed to be this:
Did I reached a limit of the textures data size?
Posted: Tue Apr 22, 2008 12:54 pm
by J.F.
No. Textures need to be in bitmaps that adhere to powers of two. 320x240 has to be stored as 512x256. Some older GPUs even need them to be square (e.g., 512x512). I don't think the PS2 needs that though.
EDIT: Actually, I think I'm going to correct myself. I believe the max the PS2 can handle is 256x256, but that won't fit in the texture cache, leading to slow drawing. You want to vary the size of the texture blocks you use to fit the cache. It varies by the color depth of the samples.
Texture Sizes that fit into Texture Cache:
- 4bit 128x128
- 8bit 128x64 (with CLUT)
- 16bit 64x64
- 32bit 64x32
So you want to split your big picture into multiple smaller textures that match the sizes in the table above according to the color depth of the texture.
Posted: Tue Apr 22, 2008 8:07 pm
by cosmito
J.F. wrote:So you want to split your big picture into multiple smaller textures that match the sizes in the table above according to the color depth of the texture.
I don't think this is necessary. In the gsKit examples, some full screen size images are read from the host: and shown without you have manually split them. I remember perfectly a 640x480 jpg image. However, the example uses a variant of "gsKit_prim_sprite_texture" which uploads the texture into the GS in chunks but it's transparent for the programmer, so no need to worry about it.
I would say it would be an aligment problem, but the fact that the colours are right drives me away from this hypothesis. If the picture is not in jpg, convert to it and try to use like in the bigtexture example of gsKit (at a first attempt, rescale the picture to the example picture (640x480) and if it works, use your original size. What's the format of your picture? Raw?
Posted: Tue Apr 22, 2008 8:13 pm
by ragnarok2040
Try setting fb[0].TBW to 4.
Posted: Tue Apr 22, 2008 11:35 pm
by kouky
Thanks for your help,
I'm currently trying to change the texture size, and try different value for TBW.
By the way, "fb[0].TBW =4;" what is this setting for ?
Posted: Tue Apr 22, 2008 11:59 pm
by ragnarok2040
I'm not exactly sure, but I think it's some sort of alignment modifier for the texture vram or something. I was getting the same tiled effect your texture was getting in FCEUltra before I decided to play with that setting, 2 made the top half of the screen gstexture split into 2, and 4 made the screen display properly.
Posted: Wed Apr 23, 2008 12:48 am
by kouky
Yes!
I've been able to display my picture (actually a video) correctly !
In case someone is facing the same kind of issue, here's my method:
so the picture to be displayed is 320x240 pixel 15bits depth.
I've splitted it into two gsKit_prim_sprite_texture next to each other.
first one is 256x256 , TBW =4
second one is 128x256 , TBW=2
Maybe TBW stands for "Texture Width Buffer" and has to be equal to:
(width of the texture / 64)
thanks for your help guys :)
Posted: Thu May 08, 2008 7:48 am
by cosmito
kouky wrote:Maybe TBW stands for "Texture Width Buffer"
From gsInit.h, TBW stands for "Texture Base Width".