Application gets slow/stuck

[vicer1234]

Hi,
     I am making a game with couple of level. each level is represented in terms of states, like we can push and pop each state.

Each level have common functions like
Initialise()->HandleEvents->Update()->Draw()

In one level i am having couple of sprite and I am using sfml functions like Sprite->Move(x,y)  etc to manipulate the entities.

In this level i tried to call function from my particle engine. In the particle engine i have tried to display the particle using opengl primitives. It will look like

Code: [Select]


glMatrixMode(GL_PROJECTION);
glLoadIdentity();
gluPerspective(90.f, 1.f, 1.f, 500.f);
std::list<Particle>::iterator iter;
for( iter = mL_Particle.begin(); iter != mL_Particle.end(); ++iter)
{
if((iter)->m_Energy > 0)
{
//if the particle is still alive, then draw
glPushMatrix();
glTranslatef((iter)->m_ParticlePosition.x, (iter)->m_ParticlePosition.y, -400.0f);
std::cout<<(iter)->m_ParticlePosition.y<<std::endl;
glRotatef((iter)->m_Angle,0,0,1);
//glScalef(1.0f, 1.0f, 1.0f);
glColor4ub((iter)->m_Color.r, (iter)->m_Color.g, (iter)->m_Color.b, (iter)->m_Color.a);
glBegin(GL_QUADS);
glTexCoord2f(texCoords.Left,  texCoords.Top); glVertex2f(-halfWidth, -halfHeight);
glTexCoord2f(texCoords.Left,  texCoords.Bottom); glVertex2f(-halfWidth, halfHeight);
glTexCoord2f(texCoords.Right, texCoords.Bottom); glVertex2f(halfWidth, halfHeight);
glTexCoord2f(texCoords.Right, texCoords.Top); glVertex2f(halfWidth, -halfHeight);
glEnd();
glColor4ub(255, 255, 255, 255);
glPopMatrix();
}

}


Couple of problem is happening:
1) The positioning of the particle is not correct.Since in the particle case its using the Opengl co-ordinate with origin at centre of the screen.
2) It gets slow and frame rate decreases ..I dont know why this is happening...Is it because i am using one draw() for smfl related case and another draw() is getting called  for Opengl.?

Everything runs smooth and when i click a button to generate a particle effect it get slower and slower!!!!!


All suggestions are welcome

[vicer1234]

'BUMP'

[Nexus]

Please have some patience, don't bump when less than a day has passed. People are not always online to respond immediately.

All suggestions are welcome

You have already told that in the other thread. There, I have given you a lot of advice, which you apparently ignore completely, e.g. std::list<Particle> or ++iter. So, I don't know whether suggestions are really welcome.

[vicer1234]

You have already told that in the other thread. There, I have given you a lot of advice, which you apparently ignore completely, e.g. std::list<Particle> or ++iter. So, I don't know whether suggestions are really welcome.

I haven't ignored those , I have already made those changes in my Particle engine. Sorry for been less patient  

[vicer1234]

Does calling  the opengl primitives in between the sfml rendering ...causes any sort of performance issue?

[Groogy]

Well if you use the *GLStates functions then yes. Though if it get's slower and slower it is more likely that it is because of memory leak or that you keep creating more and more particles without removing the old ones.

[Nexus]

Though if it get's slower and slower it is more likely that it is because of memory leak or that you keep creating more and more particles without removing the old ones.

That is one of the reasons why I suggested std::list<Particle> instead of std::list<Particle*>

I haven't ignored those , I have already made those changes in my Particle engine.

I just meant it because the code shown in the initial post did still use the old versions before your edit.

You should try to isolate the code which is responsible for the performance loss, i.e. don't mix everything at once, test the single features of your particle system. And avoid manual memory management wherever possible, it causes far more often trouble than even experienced programmers may think.

[Groogy]

Ah well it's a std::list? Linked list are pretty bad to iterate trough as cache misses are made for every step. I would consider using a std::vector that has a pre-allocated size(you should be able to calculate the maximum amount of particles that will be alive at the same time for this emittor) and use that instead.

It will change so that only one large allocation is done instead of several small ones and also like I said iteration will go smoother for the CPU.

Don't know if this is the culprit but just a recommendation.

UPDATE:

Code: [Select]

if((iter)->m_Energy > 0)

From this it looks like if you never ever remove your particles. You just skip them when they are dead. That is probably the reason why it slows down. The for-loop still iterates trough the dead particles.

[vicer1234]

I am making all the changes as stated and its showing little bit of improvement. I still analysing to see where to optimise the code.

[Laurent]

I removed the second part of your post since you already opened a new topic for it. Please don't duplicate posts.