3D Z Clipping For the PVR + OpenGL

If you have any questions on programming, this is the place to ask them, whether you're a newbie or an experienced programmer. Discussion on programming in general is also welcome. We will help you with programming homework, but we will not do your work for you! Any porting requests must be made in Developmental Ideas.
User avatar
PH3NOM
DC Developer
DC Developer
Posts: 576
https://www.artistsworkshop.eu/meble-kuchenne-na-wymiar-warszawa-gdzie-zamowic/
Joined: Fri Jun 18, 2010 9:29 pm
Has thanked: 0
Been thanked: 5 times

Re: 3D Z Clipping For the PVR + OpenGL

Post by PH3NOM »

Neoblast wrote:How much do you think it'd be possible by improving the pipeline?
I did a little work over the weekend to optimize the pipeline, specifically optimizing glDrawArrays() when GL_LIGHTING is enabled.

First of all, when GL_LIGHTING is enabled, the Vertex Position and the Vertex Normal must be transformed into Model Space, and the Position and the Normal both need to be transformed by separate Matrices.
The standard Vertex Submission Pipeline will do this Per Vertex, meaning the Matrix Register gets re-loaded 2 times per Vertex. Each time the Matrix gets reloaded costs ~11 cycles. So the standard Vertex Submission Pipeline has an overhead of ~22 cycles just re-loading the Matrix Register.

I realized that can be avoided when Submitting Arrays, by making 3 separate passes over the data:
-Pass 1: Load Modelview Rotation Matrix, Transform all Vertex Normals
-Pass 2: Load Modelview Matrix, Transform all Vertex Positions
-Pass 3: Load Render Matrix, then Light then Transform Vertices

This optimization saves ~22 cycles Per Vertex when submitting Lit Vertices through glDrawArrays().

Another optimization I made over the weekend was reducing the number of Vertices output by my ZClipping algorithm.
By making 2 passes over the data, I am able to determine if the entire strip is inside or outside of the Clipping window.
If so, the original strip will be output, instead of being broken down into single triangles and destroying the efficiency of the strip, as was being done previously.

Some new screens, testing all of the changes I made over the weekend:
(1 dynamic light on the terrain)
Image

(3 dynamic lights on the terrain)
Image
User avatar
Neoblast
DC Developer
DC Developer
Posts: 314
Joined: Sat Dec 01, 2007 8:51 am
Has thanked: 3 times
Been thanked: 1 time

Re: 3D Z Clipping For the PVR + OpenGL

Post by Neoblast »

Can't wait enough to be able to use to port some awesome open source opengl games.

It looks very neat, in approximate numbers... how much did you manage to reduce the vertices sent? % wise.
User avatar
PH3NOM
DC Developer
DC Developer
Posts: 576
Joined: Fri Jun 18, 2010 9:29 pm
Has thanked: 0
Been thanked: 5 times

Re: 3D Z Clipping For the PVR + OpenGL

Post by PH3NOM »

Neoblast wrote:It looks very neat, in approximate numbers... how much did you manage to reduce the vertices sent? % wise.
Well, that optimization submits the original Triangle Strip instead of the Strip output as Triangles, in the case that the strip is entirely inside the clipping pane.

As such, the number of Triangles Output by a Strip is (# of vertices)-2;
The number of Vertices Output by my clip algorithm was ((# of vertices)-2)*3;
So as the Strip Length increases, the vertices output reaches ~33.33%.

Today, I decided to add glScissor() to the API to enable multiplayer:
Image
affection56k
Has thanked: 0
Been thanked: 0

Re: 3D Z Clipping For the PVR + OpenGL

Post by affection56k »

Is there anyway you can add a render to texture function? I think it would really help in multiplayer games has you could have a control room where you can see what all the cameras can see,
User avatar
BlueCrab
The Crabby Overlord
The Crabby Overlord
Posts: 5652
Joined: Mon May 27, 2002 11:31 am
Location: Sailing the Skies of Arcadia
Has thanked: 9 times
Been thanked: 69 times
Contact:

Re: 3D Z Clipping For the PVR + OpenGL

Post by BlueCrab »

The PVR hardware can do render-to-texture relatively simply, so I don't see why he wouldn't be able to add such a thing to this library.
User avatar
PH3NOM
DC Developer
DC Developer
Posts: 576
Joined: Fri Jun 18, 2010 9:29 pm
Has thanked: 0
Been thanked: 5 times

Re: 3D Z Clipping For the PVR + OpenGL

Post by PH3NOM »

BlueCrab wrote:The PVR hardware can do render-to-texture relatively simply, so I don't see why he wouldn't be able to add such a thing to this library.
Since I had the day off, I decided to go ahead and do just that.

I have added the function to the API

Code: Select all

void glutSwapBuffersToTexture( void *dst );
All you have to do is pvr_mem_malloc a texture of 1024x512 to fit the 640x480 display, and pass that address as dst to glutSwapBuffersToTexture.

For completeness, today I also implemented GL_FOG using the PVR's fog functions from KOS.

Here is a screenshot with GL_FOG enabled.

On the left, we are rendering using glutSwapBuffers(), with GL_SCISSOR enabled.
A deficiency of GL_SICCISOR, is that the Scissor window must be a multiple of 32 for use with the PVR.
That means in order to GL_SCISSOR a 640x480 window for a horizontal 2-player screen,
the top window is actually 640x224, and the bottom window is actually 640x256, rather than 640x240 each.

On the right, we are rendering using glutSwapBuffersToTexture(), with GL_SCISSOR enabled.
What I am doing here is stretching the rendered texture to achieve a 640x240 screen for each viewport.

Image
These users thanked the author PH3NOM for the post:
1337
park
DCEmu Junior
DCEmu Junior
Posts: 46
Joined: Tue Jun 24, 2008 10:46 am
Has thanked: 0
Been thanked: 0

Re: 3D Z Clipping For the PVR + OpenGL

Post by park »

Not a programmer but been following this since it can kick off 3d dreamcast homebrew in the future.Thank you for your hard work and hope this is included with kos by default. Seems like you might single handedly revitalize 3d dc homebrew.
User avatar
bbmario
DCEmu Freak
DCEmu Freak
Posts: 88
Joined: Wed Feb 05, 2014 5:58 am
Has thanked: 9 times
Been thanked: 3 times

Re: 3D Z Clipping For the PVR + OpenGL

Post by bbmario »

Amazing work. I'm excited to try your OpenGL implementation, after having some problems with the KGL. :mrgreen:
moribus
DCEmu Newbie
DCEmu Newbie
Posts: 6
Joined: Mon Jan 06, 2014 5:46 am
Location: France
Has thanked: 0
Been thanked: 0
Contact:

Re: 3D Z Clipping For the PVR + OpenGL

Post by moribus »

Any news about this project ? :)
Jae686
Insane DCEmu
Insane DCEmu
Posts: 112
Joined: Sat Sep 22, 2007 9:43 pm
Location: Braga - Portugal
Has thanked: 0
Been thanked: 0

Re: 3D Z Clipping For the PVR + OpenGL

Post by Jae686 »

It certainly looks very promissing !
User avatar
PH3NOM
DC Developer
DC Developer
Posts: 576
Joined: Fri Jun 18, 2010 9:29 pm
Has thanked: 0
Been thanked: 5 times

Re: 3D Z Clipping For the PVR + OpenGL

Post by PH3NOM »

moribus wrote:Any news about this project ? :)
Thanks for the interest guys!

Yes, I am still at work on the finishing touches.

I decided to re-write some of the lighting code in pure SH4 assembly to get some speed gains.
Good news, the lighting code is now able to produce over 2 times the throughput as before using c with inline asm.
Spoiler!
sh4_light.S

Code: Select all

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
! SH4 Assembly Light Code (C) 2014 Josh PH3NOM Pearson
! Computes Diffuse and Attenuation Factors
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

.globl _sh4_light_3f

!void sh4_light_3f( void *glLight, void *vertex6f, void *out )
!fr0  = vertex x = dr0 = fv0
!fr1  = vertex y
!fr2  = vertex z = dr2
!fr3  = vertex w
!fr4  = light  x = dr4 = fv4
!fr5  = light  y
!fr6  = light  z = dr6
!fr7  = light  w
!fr8  = normal x = dr8 = fv8
!fr9  = normal y
!fr10 = normal z = dr10
!fr11 = normal w
!fr12 = misc x   = dr12 = fv12
!fr13 = misc y
!fr14 = misc z   = dr14
!fr15 = misc w
!r0   = boolean flag1
!r1   = boolean flag2
!r2   = boolean flag3
!r3   =
!r4   = [arg][void*] glLight Structure
!r5   = [arg][void*] float3  Vertex Position / Normal
!r6   = [arg][void*] float3  Output Write Address FOR D, A light factors

_sh4_light_3f:
    mov  #0,   r1  ! boolean flag2
	fmov @r5+, fr0 ! load vertex to fv0
    fmov @r5+, fr1 !
    fmov @r5+, fr2 !
    fldi0      fr3 ! load 0 for w
    
    fmov @r4+, fr4 ! load light position to fv4
    fmov @r4+, fr5 !
    fmov @r4+, fr6 !
    fmov @r4+, fr7 !
        
    fcmp/gt fr15, fr7 ! light w component set = spot light
    bt .SPOTL1s
    bf .LIGHT1s

.SPOTL1s:           ! Spotlight Calculations
   
    fmov  fr0, fr8  ! copy vertex position to fv12
    fmov  fr1, fr9  !
    fmov  fr2, fr10 !
	fldi0 fr11      ! load 0 for w
		
	fsub  fr4, fr8  ! vetex-to-light vector
	fsub  fr5, fr9  !
	fsub  fr6, fr10 !
    
    fipr  fv8, fv8 ! Normalize vertex-to-light vector
    fsqrt fr11
    
    fcmp/gt fr3, fr11 ! Check for divide-by-zero
    bt .DIV3Fsl
    bf .Csl
    
.DIV3Fsl:
    fdiv  fr11, fr8
    fdiv  fr11, fr9
    fdiv  fr11, fr10
    
.Csl:   
	mov #1,    r1    ! flag input light has read next 4 float vector
    fmov @r4+, fr12  ! load spot light direction to fv8
    fmov @r4+, fr13  !
    fmov @r4+, fr14  !
    fldi0 fr11
	fldi0 fr15
    fipr  fv12, fv8  ! fr11 now holds the cosDir of vertex-to-light
    fmov @r4+, fr15  ! fr15 now holds spot light cutoff

	fcmp/gt fr15, fr11  ! if cosDir > spotCutOff, vertex gets no light
	bf .RET0s
		    
.LIGHT1s:
    fsub  fr0, fr4  ! fv4 = L = normalize(light pos - vertex pos)
    fsub  fr1, fr5
    fsub  fr2, fr6
    fldi0 fr7
    fipr  fv4, fv4
    fsqrt fr7
 
    fcmp/gt fr3, fr7 ! Check for divide-by-zero
    bt .DIV3Fl
    bf .Cl
    
.DIV3Fl:
    fdiv  fr7, fr4
    fdiv  fr7, fr5
    fdiv  fr7, fr6
    
.Cl:     
    fmov  @r5+, fr8  ! fv8 = N = vertex normal     
    fmov  @r5+, fr9
    fmov  @r5,  fr10
    fldi0 fr11       ! load 0 for N w
    
    fmov fr7, fr3    ! store L vector length to fr3
    fldi0 fr7        ! load 0 for L w
		
	fipr fv8, fv4    ! N dot L
		
	fcmp/gt fr3, fr7 ! fr7 = Diffuse Mag >= 0 ? 
	bf .RET0s        ! Diffuse Mag < 0, return 0
    
    fmov  fr3, fr7   ! restore L vector length from fr3
    fldi0 fr3
    
    mov #0, r2    ! Compute Attenuation Factor
    cmp/gt r2, r1 ! check boolean flag for light read pos
    bf .READATT1  ! this means light is not a spot light
    bt .READATT0  ! this means light is a spot light

.READATT1:    
    fmov @r4+, fr12  ! read past spot light direction x 
    fmov @r4+, fr12  ! read past spot light direction y 
    fmov @r4+, fr12  ! read past spot light direction z 	
    fmov @r4+, fr12  ! read past spot light CutOff 
.READATT0:
    fmov @r4+, fr12  ! load Kc light attenuation factor
    fmov @r4+, fr13  ! load Kl light attenuation factor
    fmov @r4+, fr14  ! load Kq light attenuation factor		     
    fmov @r4+, fr15  ! light exponent - not implemented
    
    ! fr13 = Attenuation = 1.0f / (light->Kc + light->Kl * d + light->Kq * d * d);   
    fmul  fr7, fr13  ! light->Kl * d
    fmul  fr7, fr14  ! light->Kq * d * d
    fmul  fr7, fr14
    fadd  fr13, fr12
    fadd  fr14, fr12
    fldi1 fr13
    fdiv  fr12, fr13 ! finsh Attenuation calculation 

.RET0s: 
    fmov fr7, @r6    ! Write D(Diffuse) factor to output
	fmov @r6+, fr7   ! Move write address
    fmov fr13, @r6   ! write A(Attenuation) factor to output
	  
    rts
	nop 

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
EDIT:
As that was the first assembly piece I've ever written, I have realized some problems with that code.
I have since corrected the branching errors, and optimized a few things.
Here is my current code that is producing correct results while being much faster than the C/inline asm implementation:
Spoiler!

Code: Select all

!int sh4_l3f( void * glLight, void * vertex6f, void * out );
!fv0  = vertex position
!fv4  = light position
!fv8  = spotlight,normal
!fv12 = misc
!r0   = return value
!r1   = boolean flag r1
!r4   = [arg][void*] glLight Structure
!r5   = [arg][void*] float6f  Vertex Position / Normal
!r6   = [arg][void*] float3  Output Write Address FOR D, A light factors

.globl _sh4_l3f

_sh4_l3f:

    mov #0, r0        ! set return value r0 to 0
    mov #0, r1        ! set boolean flag r1 to 0
    
	fschg             ! switch to double precision floats
	
	fmov @r5+, dr0    ! load vertex x,y position into fv0
    fmov @r4+, dr4    ! load light position x,y,z,w into fv4
    fmov @r4+, dr6  
	
	fschg             ! switch back to single precision floats
    
	fmov @r5+, fr2    ! load vertex z position to fr2
	fldi0 fr15        ! load 0 to fr15 to use for fcmp/gt 0
	
	    
    fcmp/gt fr15, fr7 ! check light w component - fr7 set to 1 = gl spot light
    bf .LIGHT1

.SPOTLIGHT1:          ! Handle Spot Light Calculations

	fschg             ! switch to double precision floats
	
    fmov dr0, dr8     ! copy vertex postion to fv8 to hold normalized P->L vector
    fmov dr2, dr10

	fschg             ! switch back to single precision floats

    fsub fr4, fr8     ! sub3f light position from vertex position for P->L vector
    fsub fr5, fr9
    fsub fr6, fr10
	
	fipr fv8, fv8     ! normalize P->L vector
	fsqrt fr11
	
	fcmp/gt fr15, fr11
	bf .SPOT1         ! normalized P->L w less than 0 - skip division
	
	fdiv fr11, fr8    ! div3f for P->L normalization
	fdiv fr11, fr9
	fdiv fr11, fr10
		
.SPOT1:               ! branch div3f for P->L normalization

    mov #1, r1        ! set boolean flag r1 to 1 - Indicate BitStream Has Moved forward a vector3f
    fmov @r4+, fr12   ! load spot light direction
    fmov @r4+, fr13
    fmov @r4+, fr14
    fldi0 fr11        ! load 0 for P->L vector w component
    
    fipr fv12, fv8    ! P->L dot Light Dir || fr11 now holds light cosDir

    fmov @r4+, fr15   ! load light cutOff to fr15
    
    fcmp/gt fr15, fr8 ! If cosDir > cutOff, vertex is outside of spot light, return 0
    bt .RETURN0
    
.LIGHT1:  ! process vertex lighting
    
    fsub fr0, fr4     ! transform Light position into L vector ( normalize(Lp-Vp) )
    fsub fr1, fr5
    fsub fr2, fr6
	fldi0  fr7        ! load 0 for L vector w component
	fldi0  fr15       ! load 0 to fr15 for fcmp/gt 0 comparison
	
	fipr fv4, fv4     ! normalize L vector
    fsqrt fr7
    
    fmov fr7, fr3     ! copy L vector length to fr3
    
    fcmp/gt fr15, fr7
 	bf .LIGHTN        ! normalized L w less than 0 - skip division
	
	fdiv fr7, fr4     ! div3f for L normalization
	fdiv fr7, fr5
	fdiv fr7, fr6
    
.LIGHTN:               ! branch past L w division - load normal

    fmov @r5+, fr8     ! load vertex normal to fv8
    fmov @r5+, fr9
    fmov @r5+, fr10
    fldi0 fr11         ! load 0 for vertex normal w component
	fldi0 fr7          ! load 0 for L w component
	
	fipr fv8, fv4      ! N dot L || fr7 now holds Diffuse Magnitude
	
	fcmp/gt fr15, fr7
	bf .RETURN0        ! Diffuse Mag < 0 - Return 0
	
    fmov fr7, @r6      ! write Diffuse Mag to output
    add #4, r6

    cmp/gt r0, r1      ! check if spot light read past vector3f light dir
    bt .READATTEN1
    
    add #16, r4        ! if light is not spot light, read past spot factors
	    
.READATTEN1:           ! compute attenuation factors

    fmov @r4+, fr12    ! Kc load light attenuation factors to fv12
    fmov @r4+, fr13    ! Kl
    fmov @r4+, fr14    ! Kq
	fldi1 fr15         ! load 1 to fr15
	
	fmul fr3, fr13     ! perform attenuation calculations
	fmul fr3, fr14
	fmul fr3, fr14
	
	fadd fr13, fr12
	fadd fr14, fr12
	
	fdiv fr12, fr15    ! 1.0f / Kc + Kl * d + Kq * d * d

    fmov fr15, @r6     ! Write Attenuation Factor to output

.RETURN1:   ! vertex recieves light, diffuse and attenuation are written to output 
	 
    mov #1, r0
    rts
    nop

.RETURN0:   ! vertex recieves no light, return 0
    fldi0 fr3
    fmov fr3, @r6
    add #4, r6
    fmov fr3, @r6    
	    
    mov #0, r0
    rts
    nop

!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
User avatar
PH3NOM
DC Developer
DC Developer
Posts: 576
Joined: Fri Jun 18, 2010 9:29 pm
Has thanked: 0
Been thanked: 5 times

Re: 3D Z Clipping For the PVR + OpenGL

Post by PH3NOM »

Small update, did some testing tonight with the ASM lighting code implemented into my build of OpenGL.

This scene renders a bunch of qubes, created in an un-optimized loop.

Still, we are running at 60fps with 2 dynamic light sources, with near Z vertex clipping enabled.

Image

User avatar
MisterDave
DCEmu Freak
DCEmu Freak
Posts: 58
Joined: Mon Apr 08, 2013 1:16 pm
Has thanked: 0
Been thanked: 0

Re: 3D Z Clipping For the PVR + OpenGL

Post by MisterDave »

Wonderful work PH3NOM. I really appreciate all the effort that you are putting into this library.
affection56k
Has thanked: 0
Been thanked: 0

Re: 3D Z Clipping For the PVR + OpenGL

Post by affection56k »

Wow, your lighting system looks amazing, keep up the amazing work! I love how the lights blend together on the distant cubes in your latest screen capture, looks very impressive for running on the dreamcast.

I have a few questions that have been swirling round in my head for a wee while,

1) Is your OpenGL library just an dreamcast optimized variant of OpenGL 1.2 like the one currently included in KOS or are you using a slightly newer version of OpenGL, such as 1.3?

2) With the dreamcast obviously lacking in GPU power are you going to include backface culling either by default or with a function? I know occlusion culling does something similar but it's always cool to have more variety I suppose.

3) No-offence to your simply amazingly beautiful lighting engine but as you can see the lights are square, is this a hardware limitation or could i make the light different shapes?

4) Do you have a rough estimate of when the the first downloadable version of the library will be available?
User avatar
PH3NOM
DC Developer
DC Developer
Posts: 576
Joined: Fri Jun 18, 2010 9:29 pm
Has thanked: 0
Been thanked: 5 times

Re: 3D Z Clipping For the PVR + OpenGL

Post by PH3NOM »

affection56k wrote:Wow, your lighting system looks amazing, keep up the amazing work! I love how the lights blend together on the distant cubes in your latest screen capture, looks very impressive for running on the dreamcast.

I have a few questions that have been swirling round in my head for a wee while,

1) Is your OpenGL library just an dreamcast optimized variant of OpenGL 1.2 like the one currently included in KOS or are you using a slightly newer version of OpenGL, such as 1.3?

2) With the dreamcast obviously lacking in GPU power are you going to include backface culling either by default or with a function? I know occlusion culling does something similar but it's always cool to have more variety I suppose.

3) No-offence to your simply amazingly beautiful lighting engine but as you can see the lights are square, is this a hardware limitation or could i make the light different shapes?

4) Do you have a rough estimate of when the the first downloadable version of the library will be available?
Well, first off, thanks for the interest.

1.) Yes. Fixed-function pipeline like previous KGL. The only really added features are the lighting system.

2.) Yes, By Function. By default it is disabled. You must specify vertex orientation by calling

Code: Select all

glFrontFace( GLenum mode );
From there, you must specify front or back face to be culled

Code: Select all

glCullFace( GLenum mode );
3.) Yes, you can change the "shape" of the light. In my demo, I simply render a cube at the lights position, with each light being "Omni-directional". The cubes are rendered only for visual cue of the light source, so you can see where the light is coming from. You could render a sphere instead, as in simulating the sun, etc.
You can specify a "spot-light", by setting the lights position w to 1. By setting the lights cut-off, you can change the "shape" of the spot-light.

4.) Things seem to be falling into place quite well, so it should be soon. Stay tuned.
User avatar
Neoblast
DC Developer
DC Developer
Posts: 314
Joined: Sat Dec 01, 2007 8:51 am
Has thanked: 3 times
Been thanked: 1 time

Re: 3D Z Clipping For the PVR + OpenGL

Post by Neoblast »

Oh, imagine all the games that could be ported using this... :)

I'm certainly looking forward to it, impressive job phenom. :mrgreen:
Crystal Triad
DCEmu Newbie
DCEmu Newbie
Posts: 3
Joined: Fri Apr 18, 2014 1:01 am
Has thanked: 0
Been thanked: 0

Re: 3D Z Clipping For the PVR + OpenGL

Post by Crystal Triad »

Awesome! Any news on when there will be a public release?


Thanks,

Crystal Triad
User avatar
PH3NOM
DC Developer
DC Developer
Posts: 576
Joined: Fri Jun 18, 2010 9:29 pm
Has thanked: 0
Been thanked: 5 times

Re: 3D Z Clipping For the PVR + OpenGL

Post by PH3NOM »

Thank you for your interest! The API should be available very soon.

Since I released the beta build I let some devs access, there have been no reported problems with the API, so no major changes have been made. The only reports were that yes, there is a positive advancement over the previous KGL. I am interested to see if anyone is actually able to put my library to good use :wink:

Under the tutelage of BlueCrab, some of my code from the library is now actually a part of KOS, and the library has been reworked to be overall more consistent in a few areas.

So yeah I believe the library is done as a first revision for implementation into KOS.
I just need get a Source Forge account, and BlueCrab is going to give me access to submit code to the KOS repository.

Will probably make a front page news post so stay tuned! :wink:
User avatar
MisterDave
DCEmu Freak
DCEmu Freak
Posts: 58
Joined: Mon Apr 08, 2013 1:16 pm
Has thanked: 0
Been thanked: 0

Re: 3D Z Clipping For the PVR + OpenGL

Post by MisterDave »

PH3NOM,
I am interested to see if anyone is actually able to put my library to good use
Thanks for sending me the build a few weeks back. I still need to get back to this as I was getting a few out of memory errors back then, but I suspect that's due to how I was managing my textures and the slight differences with KGL. Ideally I'd love to be able to benchmark against my full engine, but the nehe examples are probably the best for me to test porting the texture management without the rest of the engine overcomplicating things.
Jae686
Insane DCEmu
Insane DCEmu
Posts: 112
Joined: Sat Sep 22, 2007 9:43 pm
Location: Braga - Portugal
Has thanked: 0
Been thanked: 0

Re: 3D Z Clipping For the PVR + OpenGL

Post by Jae686 »

I am interested to see if anyone is actually able to put my library to good use :wink:
Well you just have to release it :P

:D
Post Reply