Page 1 of 1

3D performance - from SetPixel to Blit

PostPosted: Jul 15, 2002 @ 11:11am
by Conan

PostPosted: Jul 15, 2002 @ 12:22pm
by BurningSheep

copying longs instead of shorts

PostPosted: Jul 15, 2002 @ 1:22pm
by Conan

Speed improvement by using Lock optional parameter

PostPosted: Jul 15, 2002 @ 5:35pm
by Conan
I changed the x,y based loop to a simple loop just moving pixels & that did not improve things so I turned to Lock & Unlock. The major speed improvement came when I changed over to using:-
Lock(buffer,true);
instead of just Lock(buffer);
The routine is 30% faster now

I don't know if a simple copy loop works on all hardware but for the moment I'm using

for(int y = 0; y < 76800; y++)
{
buffer.pixels[offset] = VScreen[offset];
VScreen[offset] = 0;
ZBuffer[offset] = FAR_CLIP;
offset++;
}

PostPosted: Jul 15, 2002 @ 5:53pm
by BurningSheep
you are still copying 2 bytes per cycle into buffer.pixels[]. What I meant was to push 4 bytes per cycle into it. But looking at the code, why not use memcpy to copy VScreen into the buffer?

And also instead of
VScreen[offset] = 0;
ZBuffer[offset] = FAR_CLIP;
use memset() to set them to 0 and FAR_CLIP respectively.

PostPosted: Jul 15, 2002 @ 6:13pm
by Conan
Main reason for not moving 4 bytes instead of 2 was not figuring out how to do it as buffer.pixels seemed to want an int & not a long. I did have a go but got nowhere. ( assembler is so much easier but I am making progress with C++ so I must keep at it )

I will look up memcpy & see how to use it.

As I mentioned is seems to be the lock & unlock side of things which causes most of the cycles to be used up but any speed improvement is welcome.

( In Space Treker the use of 3D will be fairly simple with ship selection & planet & base views and already the speed is fine. I won't actually use a full screen, just 240 x about 200 ).

UPDATE: memcpy & memset worked fine for the data and the init of vscreen but as FAR_CLIP is an int I can set it with memset so I'm looking for a function to set ints. Anyway this shaved about 10% off execution time so another good optimisation.

PS: It's vacation time so I'm off to Norway until the 28th July :)

PostPosted: Jul 16, 2002 @ 7:35pm
by Kzinti
See my other reply about your questions on Swizzle()/Unswizzle(), this will help you understand the performance issues you have.

Basically, you want PocketGL to draw directly to PocketFrog's backbuffer. You also want to make sure Swizzle()/Unswizzle() is not called by the Lock()/Unlock() methods. For Lock(), simply specify "bDiscard = true". For the Unlock(), the only way is to configure PocketGL to render to the screen's format (240x320 or 320x240) depending on the hardware orientation. You can obtain this information from Display::GetOrientation().