forums.ps2dev.org

I think it is a hardware bug, simply because I can't think of any good reason for it to behave in the way it does. If it hits some games and not others, take that to mean that it happens with some combinations of state and not others. I haven't managed to find a way to avoid the problem. It's possib...

Did you get the pspgl tests working? Its very easy to do something simple wrong and end up with a blank screen. In general I find its easiest to debug things on a desktop machine and then get it going on the PSP once you know the code is basically OK. Otherwise, you can start with a known working pr...

Make sure you use pspvfpu.h/libpspvfpu if you want your code to play nicely with other VFPU-using code.

somehow, it's the call to sceKernelChangeCurrentThreadAttr that's causing the crash. Well, that's a new one. Certainly a different problem from NovaCaine's. What firmware are you using? Does PSPGL work at all for you, or does it only crash in SDL? I'm not sure why sceKernelChangeCurrentThreadAttr()...

NovaCaine wrote:Cool, got it working now, maybe it should be written in the readme file to add -DHAVE_OPENGL for openGL support!

Cool. When I built SDL, it was defined by default. Do you have some older version or something?

No, when you built SDL, was it built with -DHAVE_OPENGL on the compiler command line.

I can't see any problem with your code or with SDL, assuming SDL has PSPGL support in it.

I'll try running the code later today.

No, SDL should be doing it for you. HAVE_OPENGL is a build-time config setting for SDL which makes it support OpenGL or not. Hm, it seems to be set OK when I build SDL here...

I have a suspicion the "num_blocks" parameter of sceGuClutLoad() depends on the format of the clut entries, rather than being a fixed /8 scaling. Try an RGB8888 clut, and/or playing with the num blocks parameter.

I haven't used PSPGL with SDL, but it looks like the GL context hasn't been made current; either the context hasn't been created, or eglMakeCurrent() hasn't been called on it.

Was SDL compiled with HAVE_OPENGL defined?

GL/glaux.h is utterly obsolete. Use glut (GL/glut.h).

(1) I mean "* 1/64" is different with ">>6" and following is a sample. short a = -7136; float f = (float)a/64.0; // f is "-115.500" int i1 = f; // i1 is "-111" int i2 = a>>6; // i2 is "-112" I presume you mean 'f is "-111.5"...

Is there a VFPU instruction for ">>1" ? No, but /2 should be exactly equivalent. 1/2 is one of the special constants you can substitute with a prefix, so you don't need to do anything special. Now I am using "vscl.q" to scale "0.5". If I want to ">>6", I can ...

Javascript to lua translation? Why not just port one of the free Javascript interpreters?

One interesting extra feature is that vf2i and i2f have a scaling factor as their 3rd parameter, which is expressed as a power of 2 - in other words, its a shift. I think the appropriate sequence for getting the floats out as unsigned bytes is: vf2iz.q r000,r000,24 // convert floats to ints, truncat...

There are vus2i, vi2us, vs2i, vi2s instructions, which I'm presuming convert unsigned and signed shorts to/from int. I don't know how they would work though. The questions are: does i2us/s use the 16 MSB or LSB of the int? does it expect the shorts to be packed in registers (ie, two adjacent in a si...

Yeah, I'm not sure what they were thinking. You could use it to do channel-by-channel remappings in 3 passes.

OpenGL is similar, and GU isn't too far off either. For me, the main advantage of PSPGL is that you can keep (mostly) the same code running on both the PSP and desktop, which allows for much easier debugging. Also, PSPGL does a lot of things for you which you would have to do on your own in GU (like...

You're not calling ? Without that, the vertex colours computed by lighting will have no effect on the texture. Also, you probably don't need per-vertex colours, since you're using lighting.

ayatollah wrote:Well in the official Docs of Library 1.5 it says:

Hey! Don't ever do that! It's an absolute no-no to post any official docs here.

I'm generating a 64k entry table with RGBA8888 colours in each entry, and then using a 16bit-per-pixel texture with the mode set to GU_PSM_T16.

So you are actually person behind it, right? Yup. Well, I have already used OpenGL in combination with C++ for my visualisation programs, but I used mostly relatively basic and easy elements of it : display lists, basic lighting, basic shading, basic transparencies. No exquisite texturing, no more ...

There isn't much specific to PSPGL. There's the stuff in pspgl/tests directory, and a couple of other demos, and some real program (rRootage, for example). But in general my intention is to make PSPGL familiar to OpenGL programmers (if not actually identical to real OpenGL), so lots of the HeNe and ...

Digging even further (i.e. breaking on thread start) seems we loose 320 bytes of stack in user mode threads before we even have a chance to get our grubby mits on it, 256bytes seems to be allocated to $k0 and $fp takes the other 64bytes. In $fp we have the instruction (syscall #0x2070) which is als...

Hm, if Sony were using toolchain-supported TLS, wouldn't there be evidence of it in their binutils/gcc patches?

Great! Reserving a register to point to the TLS storage is pretty common; on x86 its %gs, but everything else with enough registers reserves a normal integer register for that purpose. Since the MIPS API defines k0 and k1 as being for kernel use (ie, volatile in user-mode; typically they're used for...

char test[size]; should work. "size" needs to be pretty small, because it gets allocated on the stack, and implicitly freed when the function returns (ie, its like any other local). If you want to allocate it on the heap, use char *test = malloc(size); /* C...

Well, apart from the fact that I don't get the point, why anyone would use a 16 or even 32bit indexed palette as it's only memory waste and nothing else... I've been working on two uses: Using the depth buffer as a texture, and using the CLUT to tint the depth buffer in interesting ways. chp has a ...

a) make sure myclut was aligned on 16 byte on allocation Yup, got that. b) you're trying to submit (65536/8) * 8 = 65536 entries. Yet a CLUT4 has only 16 and a CLUT8 only 256 entries. So the only two possible parameters for num_blocks would be 2 or 32. No, you missed my point. The hardware appears ...

I've played with them a bit, but I can't get them to come out right. Is there something stupid I'm overlooking? I'm assuming the index is little-endian, and the CLUT is just linear in memory, and then doing the equivalent of sceGuClutMode(GU_PSM_8888, 0, 0xff, 0); sceGuClutLoad&#...

OK, so that makes it more or less trivial. Here's a first cut: int idct(int *block, int block_stride) { asm volatile( /* Load the input matrix. Assumes row-major order in memory, and each row is 16-byte aligned. Use ulv.q for unaligned loads. */ "lv.q R100, %0\n...