Order of Poly in the PVR List

[JMD]

Hi,

I making a little 2d engine and I use the KOS PVR lib to blit on screen.
All my gfx are TR_POLY, 2D textured with png files and I draw on screen with a classic PVR_LIST :

Code: Select all

    pvr_wait_ready();
    pvr_scene_begin();
    pvr_list_begin(PVR_LIST_TR_POLY);
	?	
    pvr_list_finish();
    pvr_scene_finish();    

I do not use the z coord (z always = 1).

My pbm is that with some sprites, the PVR change the order of the poly and last pushed isn?t in the front of my screen  some sprites are draw behind the tiles (and are invisible).

I think the pbm is here because when I remove the tile layer drawing, I can see the sprites.


Does someone know why PVR do this (though it used z plane to change orders) and how I can force ?last pushed always in front? without use a z plane ?

Thanks

JMD

[JS Lemming]

Why don't you use the z plane and just keep track of it. Like everytime an image is drawn do zIndex++;

[JMD]

Auto increment z plane should cause pbm of zoom when I draw a lot of polys (a tile layer have 300 tiles of 32*32 pixels and I have few of them). The z-plane should be selective background at 0, first plane at 1 etc ... sprites at 5 ...

All my new lib do not use the Z-plane and I have major changes to do :/
I hope a kind of miracle

I made few test with it (nibbler was made with it) and I never had pbm before. First time...

But if miracle does not exist, I will make the changes...

[BlueCrab]

Pretty much, you're gonna have to use the Z coordinate. It shouldn't be that hard to add the stuff in there, just think of Z as being like priority. Sprites would have the highest priority, whereas background would have a much lower one. The PVR depth sorts things, so its apparently messing with your coordinates, and rearranging them how it sees fit.

[JS Lemming]

Wait JMD... Are you saying that increasing the Z index actaully causes an image of size 64x64 to actually draw larger with a larger Z index? I've seriously had nightmares where the PVR worked that way and I had to compensate by drawing images smaller for higher z indexs. I hated it.

I really hope that it doesn't work that way... I thought it was just a priority thing too.

[BlueCrab]

Unless you do matrix transformations, the PVR doesn't resize things based on Z coordinate. (i.e., a 64x64 sprite drawn at z=2 would be the same size as at z=20)

[Rand Linden]

Using a trivial delta for the Z values *DOES* work.

Trust me.

Rand.

[JMD]

Auto increment z plane should cause pbm of zoom when I draw a lot of polys

I was wrong. I tested and using an incremental z value works fine and I have nothing to re-write (except z++ ).

Sorry for the mistake and thanks all for your help.

JMD

[pnpbios]

Is there a way to disable depth testing all together? I plan on porting hxRender, and well, it's kinda a necessity to NOT have depth testing.

[JS Lemming]

I feel much better now!

[showka]

Wow, surprised I remembered my log in from several years ago on my first try.

I just had to say you guys have answered a question that has been bugging the hell out of me!

I was using KGL for awhile and noticed the same thing, essentially that the PVR was trying to depth sort the polygons. I looked in PVRMARK.c included with that development ISO and found I could draw quads which, so far, seem to show the first drawn on top of everything, which is odd.

I was afraid I'd have more problems with the depth but it's nice to be able to confirm that the Z coordinate will handle depth sorting while not resizing the images. That should actually make it incredibly convienent for doing 2D programming!