So, to be honest, I'd never recommend writing a loop like this. It's a style favoured by a handful of old-school C programmers, and it is hard to read and maintain even for experienced devs.

Prefer something like this:

do_something( actors[0], actors[1], actors[2], actors[3] );
 
for (int i = 4; i < numActors; ++i) {
    do_something_else( actors );
}

Yeah, I'd recommend using another array to hold the special first 4 elements as well but since they asked how to do it I told them ;)

int nbActors = gScene->getNbActors();
NxActor** actors = gScene->getActors();
while(nbActors--) {
  NxActor* actor = *actors++;
  ///render all the stuff with physics :)
}

...

SOMEONE GET THIS MAN A FOR-LOOP!

Ok so i am working on this program using PhysX and one of the samples that comes with the library has a while loop that runs in the rendercall back function. like so

int nbActors = gScene->getNbActors();
NxActor** actors = gScene->getActors();
while(nbActors--){

NxActor* actor = *actors++;

///render all the stuff with physics

}

What i dont understand is that while loop. whats going on there exactly. from what i would guess its like incrementing through the number of actors and running the loop for each one but im not sure. could some one explaine this use of a while loop and or perhaps the use of the decrementer as something being passed like that.

That while-loop is an obfuscated way of writing this for-loop.

int nbActors = gScene->getNbActors();
for (int i = 0; i < nbActors; ++i)
{
    NxActor* actor = actors;
    // ...
}

the world is full of Klever Koders.

This. Looks like a way to purposely obfuscate a loop more than anything else. Its almost "Coding Horrors" subforum worthy.

Hmm, not really. It's just counting backwards, which was a win on the PS1 cos you had a hard wired register that always read zero so comparing to zero was faster than checking the loop condition. If the optimiser doesn't do it, you should compare against zero anyway since you don't need to do a compare you just check the zero flag... The optimiser probably does it though...

Hmm, not really. It's just counting backwards, which was a win on the PS1 cos you had a hard wired register that always read zero so comparing to zero was faster than checking the loop condition. If the optimiser doesn't do it, you should compare against zero anyway since you don't need to do a compare you just check the zero flag... The optimiser probably does it though...

This is an example of bad optimization:

• It's a level 3 'wtf' to anyone who encounters it.
• The number of cycles saved by the comparison optimization is beyond trivial.
• It's error prone. (I'd be delighted if gScene->getNbActors() returns -1 on error.)
• Based on what it's doing I doubt that it's within a tight loop -> it doesn't need to be optimized.

Hmm, not really. It's just counting backwards, which was a win on the PS1 cos you had a hard wired register that always read zero so comparing to zero was faster than checking the loop condition. If the optimiser doesn't do it, you should compare against zero anyway since you don't need to do a compare you just check the zero flag... The optimiser probably does it though...

And if this snippet was from a tutorial on optimising loops for the PS1, fair enough.

Since it's meant to be a tutorial on writing physics callbacks, not so much...