Skip to main content
gamedev.net
🔒 Locked

std::list sort modifying values?

Started by marshdabeachy 5 replies 550+ views
Original Post
marshdabeachy
marshdabeachy
This is a long shot, but I'm out of ideas and I can't figure out how to solve this problem. I'm having problems drawing sprites... or rather, with the position of sprites. I've got a list of sprite pointers which I'm sorting based on distance to the camera. The problem is that the sprite's positions are sometimes jumping all over the screen. Without getting into too many specifics, let me just say it's almost impossible to debug. The only real solid thing I've found is that if I disable my sprite sort function, the problem disappears. This completely baffles me, because my sort function doesn't do anything except reorder the list of sprites... the only thing that's supposed to change is the order the engine draws the sprites in. List definition:

std::list<Sprite*> spriteList;
Usage:

spriteList.sort( spriteSort );
Sort Function:

bool spriteSort(const Sprite* a, const Sprite* b) {
	return b->distToCamera < a->distToCamera;
}
Has anyone heard of the STL list sort function ever modifying the class data inadvertantly, or am I just grasping for straws?
Zahlman
Zahlman
Any particular reason you're storing the sprites by pointer instead of by value?
marshdabeachy
marshdabeachy
I have other lists containing pointers to some of the same sprites. It shouldn't make any difference should it?
iMalc
iMalc
Quote:
Original post by marshdabeachy
Has anyone heard of the STL list sort function ever modifying the class data inadvertantly, or am I just grasping for straws?
It is impossible. The container doesn't even know if it holds pointers, so there is no way for it to dereference them and then modify what they point to.

Most likely the problem is caused by something else which behaves differently due to the fact that items have changed order.

Make sure you are compiling at the highest warning level (that should catch any single equals which should be double equals).
iMalc
iMalc
Quote:
Original post by marshdabeachy
I have other lists containing pointers to some of the same sprites. It shouldn't make any difference should it?
A list of pointers is okay in the case where the list does not own the objects pointed to, and lifetimes are managed properly. Is that the case?
However, smart pointers usually simplify the situation.
marshdabeachy
marshdabeachy
Hmm... I may have fixed it. Or at the very least, did a workaround. I'm not sure why this works, but I changed my sort function to sort the opposite way, and my render function to draw from last to first. The problem no longer occurs.

Given the number of hours I've spent on this, I think I'll say that's good enough for me.

Thanks for the suggestions though.
ToohrVyk
ToohrVyk
Quote:
Original post by marshdabeachy
Without getting into too many specifics, let me just say it's almost impossible to debug.


Er, why? You've already noted that the bug is a discrepancy in the behaviour of sprites. Proceed as with any bug:

  1. If possible, reproduce the bug reliably. Otherwise, write short code to automatically detect the symptoms and break out.
  2. Determine the code where this behaviour is made visible to the user. This is: a piece of code that should be called but isn't, a piece of code that shouldn't be called but is, or a piece of code that should be called one way but is called in another.
  3. Backtrack through the code to determine where the control flow behaves incorrectly or the variables receive a value that is different from the expected value.
  4. Test your hypothesis by recreating the bug from scratch in an unit test, correct the bug, check that it disappeared both from the test and the real behaviour, and document it.


Working around a bug is not a valid solution, since uncorrected bugs generally reappear as the program evolves, and you're stuck with maintaining a useless workaround and correcting a bug anyway.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.