Flickering polys - help

Discuss the development of new homebrew software, tools and libraries.

Moderators: cheriff, TyRaNiD

Post Reply
SANiK
Posts: 29
Joined: Tue Jul 05, 2005 5:25 am

Flickering polys - help

Post by SANiK »

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.
Image

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:
Image

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)
Image
(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!
MrMr[iCE]
Posts: 43
Joined: Mon Oct 03, 2005 4:55 pm

Post by MrMr[iCE] »

ask and ye shall recieve:

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&#40;counter < a_vertexTotal&#41;
  &#123;
    v->x = *sgl_vertexVar++;
    v->y = *sgl_vertexVar++;
    v->z = *sgl_vertexVar++;
    if&#40;sgl_uvVar&#41;
    &#123;
      v->u = *sgl_uvVar++;
      v->v = *sgl_uvVar++;
    &#125;
    v++;
    counter++;
    if &#40;counter == 65535&#41; &#123;
		sceGumDrawArray&#40;GU_TRIANGLES, GU_TEXTURE_32BITF|GU_VERTEX_32BITF|GU_TRANSFORM_3D, counter, 0, vertex&#41;;
		counter = 0;
		vertex = v;
		a_vertexTotal -= 65535;
	&#125;
  &#125;
  if &#40;counter&#41; sceGumDrawArray&#40;GU_TRIANGLES, GU_TEXTURE_32BITF|GU_VERTEX_32BITF|GU_TRANSFORM_3D, counter, 0, vertex&#41;;

  //Reset the vars
  sgl_vertexVar=NULL;
  sgl_normalVar=NULL;
  sgl_uvVar=NULL;
&#125;
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:

Code: Select all

LIBS= -lpspgum_vfpu -lpspvfpu -lpspgu  -lpsprtc -lm
and get you some vfpu love with the matrix ops
Last edited by MrMr[iCE] on Sun Feb 25, 2007 12:31 am, edited 1 time in total.
hlide
Posts: 739
Joined: Sun Sep 10, 2006 2:31 am

Post by hlide »

:o)

GE primitive command using a 16-bit word for the count of vertex, no wonder there is some problem. And yes, MrMr[iCE] rulez : he may become the new VFPU+GE dominator ! ;P
SANiK
Posts: 29
Joined: Tue Jul 05, 2005 5:25 am

Post by SANiK »

YAY, my 3D engine works now. Gee thanks Mister *_*

Take that Mario! *wham*
Image
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
Post Reply