Questions about the PSP 3d System & issues with sceGumRo

subbie · Post by **subbie** » Tue Nov 08, 2005 2:24 am

Hey I have a few questions regarding the psp's 3d system.

1) Is there a way to have the psp modify polygons that are clipping the front plane? I have many polygons that are disapearing at the bottom of the screen since I believe they are going though the front clipping plane.

2) I have a huge issue with sceGumRotateXYZ. When ever I use it it feels like it's not rotating at 0,0,0 but rotating around 0,0,0. If I do this bit of code below. It gets worse the farther I translate from 0,0,0. Why is it doing this?

sceGumRotateXYZ(&myCamera.vAxisRot);
sceGumTranslate(&myCamera.vPosition);

chp · Post by **chp** » Tue Nov 08, 2005 3:46 am

Try enabling GU_CLIP_PLANES. This will give you a little bit of front-plane clipping, but be aware that if the polygons goes outside the virtual coordinate system of 4096x4096, you will get artifacts. You can thank the sony engineers for that.

You're doing the operations in the wrong order. If you want to translate and then rotate, you have to do

Code: Select all

sceGumTranslate&#40;...&#41;;
sceGumRotateXYZ&#40;...&#41;

since you move in and out of coordinate systems. There was a bug previously that caused the operations to be applied in the reverse order, but it has been fixed, and GUM now acts the same way as OpenGL.

subbie · Post by **subbie** » Tue Nov 08, 2005 3:49 am

sorry i'm a bit new to 3d coding in gernal but shouldn't I be rotating then translating because that is how I am doing my camera in opengl (i wrote a small q3 bsp loader last week and it works correctly this way).

subbie · Post by **subbie** » Tue Nov 08, 2005 4:53 am

yep it's an sdk bug. My setup was correct (rotation then translation). A friend compiled with the new sdk and it works but now for some reason sin/cos functions are not working (when they worked before).

also I have GU_CLIP_PLANES but I still get major polygon clipping in my display. Can't the psp fix this issue like opengl does?

jsgf · Post by **jsgf** » Tue Nov 08, 2005 7:37 am

You could do clipping in software, but then you lose a lot of the benefit of the PSP's hardware transform. If you use smaller triangles, the problem won't be as bad.

I've thought about adding a software transform clipping pipeline to PSPGL, but it seems like a lot of work for not much gain.

subbie · Post by **subbie** » Tue Nov 08, 2005 1:09 pm

New problem.

Before I was using sin & cos to allow me to move in the direction I am facing. This all worked dandy till I tried compiling my src at work (durring lunch break), sin & cos did nothing. Now even back at home my sin & cos are giving me nothing.

Any idea?

--edit--
ignore this stupid post. Did not notice that the rotation calls were using radians.

subbie · Post by **subbie** » Wed Nov 09, 2005 2:23 am

New question.

Can the PSP do multipass texturing?

I am writing a quake 3 bsp loader and at the moment I have the lightmaps going fine and dandy but I am wondering, can I do 2 textures on a single surface (texture + lightmap) ?

chp · Post by **chp** » Wed Nov 09, 2005 7:25 am

Since you have only one texturing-unit on the PSP, you'll have to do multipass for anything more than single-texturing. I guess the question you really wanted answered was if the PSP can do multitexturing... And no, it cannot. You have to blend on top to create your effect.

subbie · Post by **subbie** » Wed Nov 09, 2005 8:13 am

chp wrote:Since you have only one texturing-unit on the PSP, you'll have to do multipass for anything more than single-texturing. I guess the question you really wanted answered was if the PSP can do multitexturing... And no, it cannot. You have to blend on top to create your effect.

So you mean I have to render everything twice to obtain the same effect?

chp · Post by **chp** » Wed Nov 09, 2005 4:14 pm

Yep. Just like the good old days of 3DFX & friends (and the PS2 of course).

subbie · Post by **subbie** » Fri Nov 11, 2005 2:22 am

more questions.

1) What is the difference between GU & GUM ?

2) Are spline/bezeir surface suported in the current sdk?

3) Is there a simular method to DrawElement for psp? Or some way to do this?

glVertexPointer( 3, GL_FLOAT, sizeof(Quake3BspVertex), &m_Vertex[iVertOffset].Position[0] );
glDrawElements( GL_TRIANGLES, pSurface->NumMeshVerts, GL_UNSIGNED_INT, &m_MeshVert[iMeshOffset] );

Post by **mrbrown** » Fri Nov 11, 2005 2:29 am

1. GUM is to GU as GLU is to GL.
2. Yes.
3. Why aren't you using pspgl? It supports the fragment you posted.

jsgf · Post by **jsgf** » Fri Nov 11, 2005 2:55 am

GUM is more like the matrix stuff which is already part of the GL API. GLU has a bunch of other useful things, like functions for scaling images, building mipmaps, and tesselating complex shapes. (Though the PSPGL version of GLU is very limited at present.)

PSPGL also has extensions to support bezier and spline surfaces. In fact, the only major hardware feature PSPGL doesn't currently support is mesh morphing, and that's on my todo list.

subbie · Post by **subbie** » Fri Nov 11, 2005 3:01 am

How much of a cost in performance do I take for using PSPGL over GU/GUM ?

Also, I am guessing my issue lies with the indices to be able to do what I was doing above. Or are the indices pointer in DrawArray for something else?

Also my choice at the moment for GU/GUM over PSPGL is I plan to in the future rewrite everything using the official sdk for work. ATM I am just learning 3d and building up a freeware 3d engine that anybody can use for homebrew projects.

--edit--
I figured out the answer to one of my old questions. It was indices. The problem was my indice list was 32bit and I also did not set the indice flag in the draw array function. This works like a charm now.

sceGumDrawArray( GU_TRIANGLES, GU_TEXTURE_32BIT|GU_COLOR_8888|GU_VERTEX_32BITF|GU_TRANSFORM_3D|GU_INDEX_16BIT, MyMap.m_Faces.NumMeshVerts, MyMap.m_MeshVert + MyMap.m_Faces.MeshVerts, MyMap.pBspVert + MyMap.m_Faces.Vertex );

jsgf · Post by **jsgf** » Fri Nov 11, 2005 3:34 am

subbie wrote:How much of a cost in performance do I take for using PSPGL over GU/GUM ?

It depends, but if you set things up right there should be effectively no difference. PSPGL will do more for you, like manage command buffer, varray+index and texture memory, but that probably won't add more than a couple of percent to time spent in the library, which should be a fairly small percentage of your total app time.

Of course, you can do things in an inefficient way which will cause PSPGL to do more work, and then it can get pretty horrible. But the fast paths are already fairly tuned to be fast.

subbie · Post by **subbie** » Fri Nov 11, 2005 7:19 am

thanks for the info. ATM I am just going to keep to the Gum stuff since it's working out wonderful. I just tried out the DrawBezier and its fantastic. How come the psp can do this but wont let us render 2 textures in a single pass. :(

Zenurb · Post by **Zenurb** » Fri Nov 11, 2005 8:01 am

subbie wrote:thanks for the info. ATM I am just going to keep to the Gum stuff since it's working out wonderful. I just tried out the DrawBezier and its fantastic. How come the psp can do this but wont let us render 2 textures in a single pass. :(

Because the PS2 can't, and we will probably see alot more games ported from PS2 to PSP.

jsgf · Post by **jsgf** » Fri Nov 11, 2005 10:09 am

subbie wrote:thanks for the info. ATM I am just going to keep to the Gum stuff since it's working out wonderful. I just tried out the DrawBezier and its fantastic. How come the psp can do this but wont let us render 2 textures in a single pass. :(

Yeah, the PSP's design has a lot of interesting tradeoffs - a fixed-function transform pipeline as sophisticated as they ever got in the PC hardware space (before they all went programmable), coupled with a very old-fashioned rasterizer.

However, the PSP has embedded VRAM, which is much faster than any external memory could be. This means that fill rate and texture fetches aren't really a big bottleneck, so rendering a primitive twice isn't necessarily a huge burden.