Drawing Everything

[qsik]

is there a way to draw everything w/o having to write window.draw(whatever) every single time you have something new?

[quasius]

is there a way to draw everything w/o having to write window.draw(whatever) every single time you have something new?

No.  But just use an STL vector of Sprites.

Code: [Select]


for (unsigned int i = 0; i < vSprites.size(); ++i)
      window.draw(vSprites[i]);


It's not that big of a deal.  How would you expect SFML to know what "everything" is anyway?  SFML does not have a sprite manager.  You can and should make your own.

[eleinvisible]

But I think he means, he wants the entire screen to redraw, not all the objects. Like in SDL you can call SDL_Flip(Screen).

[Kernelpanic]

A sprite isn't bound to one window, so it wouldn't be possible to detect all sprites, which must be drawn in one specific window.

@quasius
It would be good to use iterators for the loop:

Code: [Select]


for(vector<Sprite>::iterator i = vSprites.begin(); i != vSprites.end(); i++)

So you can use easily all types of containers.

[quasius]

@quasius
It would be good to use iterators for the loop:

I was trying to keep it simple and intuitive...

[Nexus]

Sorry, if it's a little bit off-topic...

It would be good to use iterators for the loop:
[...]
So you can use easily all types of containers.

Is this faster with iterators or is it just more general and easy to port? What is a reason against indexes?

[eleinvisible]

Sorry, if it's a little bit off-topic...

It would be good to use iterators for the loop:
[...]
So you can use easily all types of containers.

Is this faster with iterators or is it just more general and easy to port? What is a reason against indexes?

Seconded, because the reason I use STL vectors is because they're fast, and allow index access with [] and at, otherwise I don't think I'd like STL containers as much.

[quasius]

Sorry, if it's a little bit off-topic...

It would be good to use iterators for the loop:
[...]
So you can use easily all types of containers.

Is this faster with iterators or is it just more general and easy to port? What is a reason against indexes?

Seconded, because the reason I use STL vectors is because they're fast, and allow index access with [] and at, otherwise I don't think I'd like STL containers as much.

It might be faster with iterators.  But since the indexing syntax is so common, I'm sure any good optimizing compiler just uses an iterator anyway in release build.  It's nothing to worry about.
The biggest reason to use iterators (and it's not that big) is if you wanted to switch to another container (list, map), it would be a bit easier.  List and map will obviously be faster and better than vectors in certain situations.  List doesn't use indexing and map indexing works differently from vector indexing (in a map, if you reference an index that doesn't exist, it will create that entry automatically which can cause unexpected behavior if you don't understand what's going on.)
There's probably nothing wrong with using index syntax for vectors if you like.

[workmad3]

I don't think any compiler would replace index notation with iterator constructs. It's not really an optimisation (especially if the iterator coding isn't quite as optimal as possible).

The point of using iterator notation rather than index notation is that iterator notation is pointer notation, which can be used with ANY container that is standard in C++, not just STL ones. That means that the same (templated, generic) code will work with raw arrays in the same way as it will work for vectors, or maps or deques or whatever.

However, if you want a good way to do what you are suggesting, I would suggest using boost and doing:

Code: [Select]


BOOST_FOREACH(Sprite s, vSprites)
{
   s.Draw();
}

as then you don't need to worry about messing around with iterators, indices or anything else There is an STL version of for_each but it isn't as useful as the boost version, although I think there may be an improved version in C++0x.

[Nexus]

I just asked because I don't like iterators, either. Sometimes I really hate them

Most of the time, you can avoid using iterators, but unfortunately, the erase() function doesn't work with indexes - sometimes, that's really annoying. I really don't understand why there is no overloaded function with an index integer as parameter.

[Kernelpanic]

For some containers like list they are really faster.
I think for containers like vector and deque they are a little bit faster, because the program can contact the adress directly.
Somtimes I hate them, too, because I had a situation, where I needed one int-counter and one iterator in a for-loop, for(int i=...) and inside of the loop an iterator.

[Laurent]

Most of the time, you can avoid using iterators, but unfortunately, the erase() function doesn't work with indexes - sometimes, that's really annoying. I really don't understand why there is no overloaded function with an index integer as parameter.

You can always construct a vector iterator from an index :

Code: [Select]

vector<xxx>::iterator it = v.begin() + index;

[qsik]

Code: [Select]

void CategoryArray()
{
for (int sprite = 0; sprite < 6; sprite++)
{
if (sprite == 1)
Categories[sprite] = sf::Sprite(Who);
if (sprite == 2)
Categories[sprite] = sf::Sprite(Dates);
if (sprite == 3)
Categories[sprite] = sf::Sprite(Where);
if (sprite == 4)
Categories[sprite] = sf::Sprite(Numbers);
if (sprite == 5)
Categories[sprite] = sf::Sprite(Random);
}
}

Code: [Select]

for (int number = 1; number < 6; number++)
{
Window.Draw(Categories[number]);
};

this code should assign and display 5 sprites but it only displays 4, what am i doing wrong?

[Laurent]

Wow, I'm always impressed how people can make simple things much more complicated :shock:
What about this code ?

Code: [Select]

void CategoryArray()
{
    Categories[1] = sf::Sprite(Who);
    Categories[2] = sf::Sprite(Dates);
    Categories[3] = sf::Sprite(Where);
    Categories[4] = sf::Sprite(Numbers);
    Categories[5] = sf::Sprite(Random);
}
Or, if you just want to assign a new image and don't want to reset all other attributes :

Code: [Select]

void CategoryArray()
{
    Categories[1].SetImage(Who);
    Categories[2].SetImage(Dates);
    Categories[3].SetImage(Where);
    Categories[4].SetImage(Numbers);
    Categories[5].SetImage(Random);
}

But I agree, your code should display 5 sprites. Maybe the error is in another part of the code.

[Nexus]

You can always construct a vector iterator from an index :

Code: [Select]

vector<xxx>::iterator it = v.begin() + index;

I know, but that's what I hate... I think

Code: [Select]

MyVector.erase(3); would be much easier instead of

Code: [Select]

MyVector.erase(MyVector.begin() + 3);
At least there should be an overloaded function which would accept both iterators and index integers.

But do you think it's better to use iterators all the time (even as loop-counting variables)? Because at the moment I try to avoid them wherever possible
Might it be significant for the performance if I got big sf::Sprite vectors which are drawn every frame?