Choppy/laggy point sprites

Started by
2 comments, last by BauerGL 20 years, 6 months ago
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;
			if( m_base >= m_discard )
				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;
					if( m_base >= m_discard )
						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]

@mikaelbauer

Super Sportmatchen - A retro multiplayer competitive sports game project!

Advertisement
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.

Muhammad Haggag
MHaggag''s corner

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

@mikaelbauer

Super Sportmatchen - A retro multiplayer competitive sports game project!

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

Muhammad Haggag
MHaggag''s corner

This topic is closed to new replies.

Advertisement