#### Archived

This topic is now archived and is closed to further replies.

# Choppy/laggy point sprites

This topic is 5181 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hi, I've made a particle "system" using point sprites based on the example in the SDK. I don't know if this is a real problem, I just want to make sure that I'm doing it the right way. Here is the rendering code, m_num_particles is the amount of particles that are alive.
// Set up renderstates/textures etc

// m_flush = 1/10 of the max amount of particles ( in this case 1000)

// m_discard = 2048 or set to the max amount of particles if that is less than 2048

PointVertex	*p_vertices				= 0;
DWORD		 particles_to_render	= 0;

m_base += m_flush;
m_base = 0;

if( FAILED( mp_VB->Lock( m_base * sizeof( PointVertex ), m_flush * sizeof( PointVertex ), (void**)&p_vertices, m_base ? D3DLOCK_NOOVERWRITE : D3DLOCK_DISCARD ) ) )
return E_FAIL;
for( int i = 0; i < m_num_particles; ++i )
{
p_vertices->pos.x = mp_particle_list[i].m_pos.x;
p_vertices->pos.y = mp_particle_list[i].m_pos.y;
p_vertices->pos.z = mp_particle_list[i].m_pos.z;

p_vertices->color = D3DCOLOR_XRGB( 200, 100, 0 );

if( ++particles_to_render >= m_flush )
{
mp_VB->Unlock();
p_device->DrawPrimitive( D3DPT_POINTLIST, m_base, particles_to_render );

m_base += m_flush;
m_base = 0;

if( FAILED( mp_VB->Lock( m_base * sizeof( PointVertex ), m_flush * sizeof( PointVertex ), (void**)&p_vertices, m_base ? D3DLOCK_NOOVERWRITE : D3DLOCK_DISCARD ) ) )
return E_FAIL;
particles_to_render = 0;
}

p_vertices++;
}
mp_VB->Unlock();

// render remaining particles

if( particles_to_render )
p_device->DrawPrimitive( D3DPT_POINTLIST, m_base, particles_to_render );

With this I get really sloppy results rendering 10 000 point sprites when I'm looking at it fairly far away. Is this normal? Is there something "wrong" with my rendering code? My specs - Athlon 900mhz, 512mb sdram, geforce2 gts 32mb Any help is welcomed! Edit: The above choppiness also occurs when rendering 1000 sprites, though only when up pretty close. So it's probably a fillrate problem? Edit2: When rendering the (10 000) sprites without texture there is almost no choppiness whatsoever (unless I'm reaaally close to the origin of the particles). I'm off to sleep now.. hopefully someone has a good answer/confirmation on this. Thanks for reading. [edited by - BauerGL on October 11, 2003 9:08:17 PM] [edited by - BauerGL on October 11, 2003 9:08:55 PM]

##### Share on other sites
I''ve not stress-tested particle effects/engines before, but 10,000 particles seems pretty extreme to me. The particles sample that comes with the SDK has a limit of 2048 particles, and I don''t think it even reaches it.

Anyway, you''re most probably limited by fillrate - if you get no debug output saying otherwise.

Why do you need 10,000 particles anyway? Particles are not used for general 2D effects, due to limitations in their max point size for example - Some things are better done with billboards.

MHaggag''s corner

##### Share on other sites
Yea, I know that they aren''t the ultimate solution to every particle usage. Though I read in another thread that I (or someone) should be able to render ~10 000 point sprites with almost no change in FPS. So that''s why I wanted to make sure that it wasn''t me doing something wrong but that I simply shouldn''t be able to render that many particles without speed loss. So thanks for your answer, I''ll use less particles from now on

##### Share on other sites
quote:
Original post by BauerGL
Yea, I know that they aren''t the ultimate solution to every particle usage. Though I read in another thread that I (or someone) should be able to render ~10 000 point sprites with almost no change in FPS.

Such a statement is inaccurate - it all depends on the size of the sprites. Such effects are usually fill-rate limited. For example, the Geforce4 supports a particle size up to 8192, as far as I recall. That''d simply suck your fill-rate even if you render a few particles.
You can calculate the fillrate consumed by your sprite system if you know the exact size of each particle, and the exact number rendered per frame. Calculate that and compare it to the "theoretical" fill-rate, and keep in mind that:
- There are other things being render beside particles
- Theoretical fill-rate is, well, theoretical