I've spent three days trying to port my newest engine, but ran into some nasty stuff.
For some reason, polys keep "corrupting" and appearing in random areas.
I'm 100% sure it's not my map loader - I've dumped data from map.c to a file and map.c IS functioning 100%.
I've reduced my 3D engine into a set of VERY small files so you guys can examine it to help me.
Here's the source to examine:
http://sanik.hacking-cult.org/WTF.zip
To simplify the code I've removed the camera code - so the camera's stuck in place, but don't worry - it's placed in an area where one can see the flickering.
This is what's happening in the full engine:
Also, a little note, my map data has UVs and Verteces in seperate lists.
The function that puts the lists together and sends the data to drawArray is in sgl.c at the bottom.
Hopefully someone can help =/
Also, this is what happens in the full engine if I send only vertex data (without intertwining the UV list)
(note glitches still happen but not as much as when sending both UVs and Verteces intertwined)
It's either the way I intertwine the lists or it might be some kind of GE buffer overflow...?
HILFEN!
Flickering polys - help
ask and ye shall recieve:
renders perfectly, no glitches, no popping faces. This should handle any size mesh, including ones with more than 65535 points. if you know you dont have anything greater than 65535 points, then comment out the if block after the counter++; line. I tried this without all the sceKernelDcacheWriteback stuff, and still works fine.
Why does it work? You have to keep in mind the GU is running in parallel with the cpu. In GU_DIRECT mode, as you issue drawarray commands, it will work on the data you passed to it immediately, but the cpu is not going to wait for the GU to finish (unless you issue a sceGuSync). In your code, you were trying to reuse the same array you allocated to fill the next batch of triangles, and overwriting data the GU was still working on, resulting in those glitches. If you do want to use a common vertex buffer that you can reuse more than once, you'll have to dig into callbacks and sceGuSignal so you can properly sync the next batch of geometry.
Also you might wanna try this in your makefile:
and get you some vfpu love with the matrix ops
Code: Select all
void sgl_drawA(byte a_type, dword a_vertexTotal)
{
//Allocate RAM
//sceKernelDcacheWritebackInvalidateAll();
struct SGLVertex *vertex=sceGuGetMemory(a_vertexTotal * sizeof(struct SGLVertex));
struct SGLVertex *v = vertex;
//Intertwine lists
int counter=0;
while(counter < a_vertexTotal)
{
v->x = *sgl_vertexVar++;
v->y = *sgl_vertexVar++;
v->z = *sgl_vertexVar++;
if(sgl_uvVar)
{
v->u = *sgl_uvVar++;
v->v = *sgl_uvVar++;
}
v++;
counter++;
if (counter == 65535) {
sceGumDrawArray(GU_TRIANGLES, GU_TEXTURE_32BITF|GU_VERTEX_32BITF|GU_TRANSFORM_3D, counter, 0, vertex);
counter = 0;
vertex = v;
a_vertexTotal -= 65535;
}
}
if (counter) sceGumDrawArray(GU_TRIANGLES, GU_TEXTURE_32BITF|GU_VERTEX_32BITF|GU_TRANSFORM_3D, counter, 0, vertex);
//Reset the vars
sgl_vertexVar=NULL;
sgl_normalVar=NULL;
sgl_uvVar=NULL;
}
Why does it work? You have to keep in mind the GU is running in parallel with the cpu. In GU_DIRECT mode, as you issue drawarray commands, it will work on the data you passed to it immediately, but the cpu is not going to wait for the GU to finish (unless you issue a sceGuSync). In your code, you were trying to reuse the same array you allocated to fill the next batch of triangles, and overwriting data the GU was still working on, resulting in those glitches. If you do want to use a common vertex buffer that you can reuse more than once, you'll have to dig into callbacks and sceGuSignal so you can properly sync the next batch of geometry.
Also you might wanna try this in your makefile:
Code: Select all
LIBS= -lpspgum_vfpu -lpspvfpu -lpspgu -lpsprtc -lm
Last edited by MrMr[iCE] on Sun Feb 25, 2007 12:31 am, edited 1 time in total.
YAY, my 3D engine works now. Gee thanks Mister *_*
Take that Mario! *wham*
http://sanik.hacking-cult.org/MK2HL.zip
Just have to fix the octree BSP sorting issues, PSP's clipping and finish the collision detection code *rolls eyes*
Skeletal animation is working beautifully
Take that Mario! *wham*
http://sanik.hacking-cult.org/MK2HL.zip
Just have to fix the octree BSP sorting issues, PSP's clipping and finish the collision detection code *rolls eyes*
Skeletal animation is working beautifully