| View previous topic :: View next topic |
| Author |
Message |
Hedonis
Joined: 25 May 2005 Posts: 6
|
Posted: Wed May 25, 2005 1:00 pm Post subject: confusing problem with setup |
|
|
Heya's, Ive got a problem and hopefully you guys will be able to point me in the right direction.
Basically I spent the past few days finally trying to get my development setup running which included grabbing the ps2sdk from the cvs and compiling it and then the latest gskit from the website.
After compiling gskit I thought i'd start playing with the texture example and thats when I hit a snag... using texture.elf via inlink I noticed it would fail with:
open name host:bitmap.raw flag 1 data 41378
open fd = 2
[NET] : Sent bitmap.raw at 190KB/s
Texture 1 Height: 256
Texture 1 Width: 256
open name host:bsdgirl.bmp flag 1 data 41378
open fd = -1
Could not load bitmap: host:bsdgirl.bmp
So I have a look at the texture.c and nothing really stands out so I modify the example so that it only does one texture with
gsKit_texture_bmp(gsGlobal, &Tex2, "host:bsdgirl.bmp");
now, I get
open name host:bsdgirl.bmp flag 1 data 41378
open fd = 2
Get Reboot Request From EE
After playing around gstexture source I came to the conclusion that the offending line in gsKit_texture_bmp was:
FTexSize = fioLseek(File, 0, SEEK_END);
which was returning -1 when it should be working fine. My only solution was to move it to the top of the function when the file is first opened. Once that was done, my example would at least show a black box where the bmp should be and not crash out.
Finally I try to load the texture example using the above mod to gstexture.c and it still fails with
open name host:bsdgirl.bmp flag 1 data 41378
open fd = 2
Texture 2 Height: 384
Texture 2 Width: 256
open name host:bitmap.raw flag 1 data 41378
open fd = -1
Could not load texture: host:bitmap.raw
and right about now im frustrated, is this a problem with my fileio compile, is it something I dont see in gskit or is it inlink not sending the 2nd file etc.
Im sorry if this hasnt made sense to anyone but im at a total loss
Hed |
|
| Back to top |
|
 |
Drakonite Site Admin

Joined: 17 Jan 2004 Posts: 989
|
Posted: Wed May 25, 2005 4:34 pm Post subject: |
|
|
Inlink has a lot of bugs. I'd really suggest you try a different loader before you claim there are any bugs with the code. _________________ Shoot Pixels Not People!
Makeshift Development |
|
| Back to top |
|
 |
ooPo Site Admin
Joined: 17 Jan 2004 Posts: 2032 Location: Canada
|
|
| Back to top |
|
 |
Hedonis
Joined: 25 May 2005 Posts: 6
|
Posted: Thu May 26, 2005 7:39 pm Post subject: |
|
|
You were absolutely right guys, seems inlink was the issue!
thanks
Hed |
|
| Back to top |
|
 |
Hedonis
Joined: 25 May 2005 Posts: 6
|
Posted: Thu May 26, 2005 10:30 pm Post subject: |
|
|
Sorry got another question, started playing around with gskit and wanted to try and load a couple of textures which are 256x256 but im finding that gsKit_vram_alloc is failing as the the current pointer in the buffer is going past a magic number 4194304
if(gsGlobal->CurrentPointer >= 4194304)
so the output I get is
Input ELF format filename = host:main.elf
0 00100000 0002c020 ...
Loaded, host:main.elf
start address 0x100008
gp address 00000000
CP: 00000000, size: 00168000
CP: 00168000, size: 00168000
CP: 002D0000, size: 000B4000
open name host:Image/test.bmp flag 1 data 41378
open fd = 2
CP: 00384000, size: 00040000
open name host:Image/test.bmp flag 1 data 41378
open fd = 2
CP: 003C4000, size: 00040000
ERROR: Not enough VRAM for this allocation!
VRAM Allocation Failed. Will not upload texture.
Is there 'rules' to how much/size etc that can be stored in the buffer and does anyone have a suggestion as to how I could then display a full screen texture?
Hed |
|
| Back to top |
|
 |
boomint
Joined: 13 Apr 2004 Posts: 80 Location: Sheffield, UK
|
Posted: Fri May 27, 2005 12:01 am Post subject: |
|
|
| Hedonis wrote: |
if(gsGlobal->CurrentPointer >= 4194304)
|
is 4mb vram limit :) _________________ --( someone stole my sig! )-- |
|
| Back to top |
|
 |
Hedonis
Joined: 25 May 2005 Posts: 6
|
Posted: Fri May 27, 2005 4:35 am Post subject: |
|
|
yup that makes sense but even if I have enough space left in vram it still seems to stuff up on large textures and I cant see why.
I'll stuff around with it tomorrow, I need sleep
Hed |
|
| Back to top |
|
 |
ooPo Site Admin
Joined: 17 Jan 2004 Posts: 2032 Location: Canada
|
Posted: Fri May 27, 2005 9:12 am Post subject: |
|
|
I don't know if gsKit works around it but there's a limit to the size you can transfer to vram in one go. It is a limitation of the GIFTAG used to specify the transfer itself - I believe you can only send 512k at a time.
The easiest way around it is to split up your transfer into two pieces. Remember to split on a page boundary or you'll get garbage. |
|
| Back to top |
|
 |
Hedonis
Joined: 25 May 2005 Posts: 6
|
Posted: Sat May 28, 2005 1:52 am Post subject: |
|
|
It looks as if it should but after doing a bit of reading up through tutorials etc I think I can see a problem. In the part of upload code which sets up the Image data transfer
| Code: |
while (packets-- > 0) {
*p_data++ = DMA_TAG( DMA_MAX_SIZE, 1, DMA_REF, 0, (u32)p_mem, 0 );
*p_data++ = 0;
p_mem+= (DMA_MAX_SIZE * 16);
test++;
}
if (remain > 0) {
*p_data++ = DMA_TAG( remain, 1, DMA_REF, 0, (u32)p_mem, 0 );
*p_data++ = 0;
test++;
}
|
DMA_MAX_SIZE is defined as xFFFF which is the entire vram size rather than the limit that you've mentioned ooPo (16384 qwords). Changing it appears to only partially work as it seems to ignore the 'remainder' qwords. I'll keep reading and trying to compare it with how others do it but at least its helping me get my head around it all.
Hed |
|
| Back to top |
|
 |
|