Slowdown up close to a sprite?

Blitz3D Forums/Blitz3D Beginners Area/Slowdown up close to a sprite?

DH(Posted 2005) [#1]
Anyone know why you get painfull slowdown when your close to a sprite or even just a quad in space???

My frame rate will drop by 60% with a sprite, or quad created in a mesh when it takes up over 40% of the screen.

Anyone know?


Ross C(Posted 2005) [#2]
I think it has something to do with a thing called "Fill Rate". How much the graphics card has to draw onscreen. If a texture is filling the whole screen, some lesser graphics cards can be slowed down a fair bit by that. I'm not sure if changing the texture size to something smaller would help any though...


jfk EO-11110(Posted 2005) [#3]
It happens when your Sprite is using Alpha Transparency (it's default AFAIR), and if there are multiple Alpha Sprites "obscuring" one another. So the Hardware has to calcualte everything behind it trough multiple alpha filters. Using other blendmodes like "Multiply" is probably faster.


DH(Posted 2005) [#4]
Actually, I am noticing it when using a quad with a mask. I downed the texture size to 32x32 (from 128x128), changed the graphics mode to 640x480x16, and still no luck.. Getting close to it gives a massive perforamnce hit..

I have a geforce 4200 128 mb card..

I inserted a bunch of timeing functions and found that the problem lies at the flip (I have it flip(false) at the moment and it doesnt change anything). The flip takes 20-25 ms. I would think if it were a fill-rate issue that a complex scene (terrain with a good amoung of texturing) would slow it down the same way, however I can do stuff like that at 1024x768 at full frames...

I am just really puzzled, Any other thoughts?


Stevie G(Posted 2005) [#5]
regardless, simply delete the particle when it's too close to the camera ( looks shite anyway :) ).. problem solved?


DH(Posted 2005) [#6]
Thanks, but not solved... I am not using this on a particle system.. It's on a tree/leaf system. If I start loosing leaves when the tree comes closer all I will see is a dead tree. Nice effect, but it wont fit the 'lush forest' I am trying to create. From a distance, the forest looks good, but i have to keep the leaves above viewer height so the cam doesnt get to close.

I dont want to do this though, because the 'leaves' do look good close up.


Ross C(Posted 2005) [#7]
Try this. Try taking the texture off altogether and see what happens.


DH(Posted 2005) [#8]
No change.

I am still fiddling around with the system to see where the slowdown is taking place.

Thanks for your help though, to everyone who has responded.


jfk EO-11110(Posted 2005) [#9]
if you're using windowed mode, try fullscreen instead, for test purpose.


DH(Posted 2005) [#10]
well I'll be damned.... It is because of windowed mode (wow, talk about overlooking the obvious)!!!

Thanks JFK...

I am posting a test engine of this in one of the showcases. it will output graphs for people to compare results with.

Thanks again!


DH(Posted 2005) [#11]
http://www.blitzbasic.com/Community/posts.php?topic=46177

There is the test, anyone care to try it out?


Ross C(Posted 2005) [#12]
Sure thing.


jfk EO-11110(Posted 2005) [#13]
I am still waiting for a new machine since my CPU used to melt down an create a china syndrom in my appartment. So I can't test this right now. But in windowed mode there is only a fake double buffer. Flip will not swap the buffer adresses, but has to Copyrect the content of the backbuffer to the frontbuffer that is on the desktop. But it's still unbelievable that this is takeing 25 ms.

Did you really measure it like this:

t1=milisecs()
flip 0
t2=millisecs()
print t2-t1
waitkey()
?