Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Speedproblems with draw to window  (Read 3524 times)

0 Members and 2 Guests are viewing this topic.

elwydd

  • Newbie
  • *
  • Posts: 9
    • View Profile
Speedproblems with draw to window
« on: May 06, 2014, 05:37:26 pm »
Hello yeah I know again a thread but I think here it's better placed.

I'm measuring time with an sf::clock

t3=mClock2.restart().asSeconds();
draw(asteroids,bullets,ship,window,BgSprite);
t4=mClock2.restart().asSeconds();

like that I get the delta t used for this function, except I'm terribly wrong.

now like I said in the other thread I have lag issues. Because sometimes t4 jumps to 120 ms.
so what does this draw function?

void draw(std::vector<Asteroid>& asteroids, std::vector<Bullet>& bullets, SpaceShip& ship, RenderWindow& window, Sprite& BgSprite)
{
    window.clear();
    window.draw(BgSprite);
    for(b_it=bullets.begin(); b_it!=bullets.end();)
    {
        b_it->Draw(window);
        ++b_it;
    }
    for(a_it=asteroids.begin(); a_it!=asteroids.end();)
    {
        a_it->Draw(window);
        ++a_it;
    }
    ship.Draw(window);
}

Well not much at all, I handle over the vectors with the asteroids & bullets, my ship , my background and my render window.

The Draw(window) are just drawing the sprites to die render window.

I'm not sure that I pass the vectors the best way, but if you have an idea what it could be tell me.

Again sorting out the main problem these few lines of codes take sometimes (most of the time not) above 1/10 of a second.

thank you in advance

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10998
    • View Profile
    • development blog
    • Email
Re: Speedproblems with draw to window
« Reply #1 on: May 06, 2014, 06:07:41 pm »
If you refer to a thread, you should also link it. We get around 50 new posts or so a day, you wouldn't expect us to remember each and every of them, would you? ;)

You're a bit all over the place with your post.
What exactly should happen, what exactly does happen and what is your precise question?

Since you only draw things and not modify anything, you could pass the vectors by const reference (and make the Draw method const as well if they aren't), or probably even better, don't use free functions for this, but instead use a dedicated application class or similar, that way the vectors could be within the class' scope.

If you only iterate over a vector you should definitely put the ++it within the for loop. And if you use C++11 you could use a range based for loop.
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

elwydd

  • Newbie
  • *
  • Posts: 9
    • View Profile
Re: Speedproblems with draw to window
« Reply #2 on: May 06, 2014, 06:56:14 pm »
The thread was in the project directory, but since I only want to solve this problem and don't want to get any © problems because of images *cough*, I made a new thread. ;)

If any of my answers sound stupid for you I'm sorry. I'm a newb to C++ and SFML I learnt it all while I was programming the game.

So to the problem

What should happen:
Well that's easy
1. clear render window
2. draw the background
3. iterate through bullets and draw them
4. iterate through asteroids and draw them
5. draw the ship

What happens?:
Exactly what I mentioned above.
But (here is my problem) sometimes there is something hanging up in there. Taking a huge amount of time which the player sees as lag.

And now my question what can cause lags in these codelines ?


To work down your post

Quote
If you only iterate over a vector you should definitely put the ++it within the for loop
Didn't I ?

Quote
and make the Draw method const as well if they aren't
like that?
void Object::Draw(RenderWindow& Window) const
{
    Window.draw(mSprite);
}
I saw somewhere that a draw function from the visible game objects was virtual would this help ?


Quote
or probably even better, don't use free functions for this, but instead use a dedicated application class or similar, that way the vectors could be within the class' scope.
yeah nasty habit of me, for testing purposes in a free function, can this cause major problems ?

Could you make an example of
Quote
you could pass the vectors by const reference

Other questions will come later :)

dabbertorres

  • Hero Member
  • *****
  • Posts: 506
    • View Profile
    • website/blog
Re: Speedproblems with draw to window
« Reply #3 on: May 06, 2014, 07:45:25 pm »
Quote
Quote
If you only iterate over a vector you should definitely put the ++it within the for loop
Didn't I ?
No, you put it in the braces. Like this instead:
for(b_it=bullets.begin(); b_it!=bullets.end(); ++it)

Quote
Quote
and make the Draw method const as well if they aren't
like that?
void Object::Draw(RenderWindow& Window) const
{
    Window.draw(mSprite);
}
Yes.

Quote
Could you make an example of
Quote
you could pass the vectors by const reference
void draw(const std::vector<Asteroid>& asteroids, ....)

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10998
    • View Profile
    • development blog
    • Email
Re: Speedproblems with draw to window
« Reply #4 on: May 06, 2014, 07:57:36 pm »
But (here is my problem) sometimes there is something hanging up in there. Taking a huge amount of time which the player sees as lag.

And now my question what can cause lags in these codelines ?
Lag spikes can have many origins, it's often rather hard to figure out exactly what does wrong.
Is your graphics driver up to date? Does it happen in release mode as well? Does it still happen if you disable your AV? Do you have any applications running in the background?

I saw somewhere that a draw function from the visible game objects was virtual would this help ?
No, they most likely derived from sf::Drawable where the draw function is virtual.

yeah nasty habit of me, for testing purposes in a free function, can this cause major problems ?
Not necessarily but it's not a very nice code design.
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

elwydd

  • Newbie
  • *
  • Posts: 9
    • View Profile
Re: Speedproblems with draw to window
« Reply #5 on: May 06, 2014, 08:18:59 pm »
Ah you meant like this in the for loop :) thx why is it better this way ?

Do I need a to specify the Iterator different if i iterate over a const std::vector?
Because my compiler bombarded me with errors when I passed the vectors as constants :/

In function 'void draw(const std::vector<Asteroid>&, std::vector<Bullet>&, SpaceShip&, sf::RenderWindow&, sf::Sprite&)':|
error: no match for 'operator=' in 'a_it = (& asteroids)->std::vector<_Tp, _Alloc>::begin<Asteroid, std::allocator<Asteroid> >()'|


Quote
Is your graphics driver up to date? Does it happen in release mode as well? Does it still happen if you disable your AV? Do you have any applications running in the background?

Drivers are up to date. It happens also in release mode. Without AV a bit better but that could just be luck. But without codeblocks it seems to run smoother.
Or perhaps the program is just trolling me....

ahh perhaps I should just sleep

thanks for your replies perhaps till tomorrow

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10998
    • View Profile
    • development blog
    • Email
Re: Speedproblems with draw to window
« Reply #6 on: May 06, 2014, 08:33:40 pm »
Do I need a to specify the Iterator different if i iterate over a const std::vector?
Yes, you need to use cbegin() and cend().
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

Jesper Juhl

  • Hero Member
  • *****
  • Posts: 1405
    • View Profile
    • Email
Re: Speedproblems with draw to window
« Reply #7 on: May 06, 2014, 09:47:42 pm »
Do I need a to specify the Iterator different if i iterate over a const std::vector?
Yes, you need to use cbegin() and cend().
What's really needed seems to be to learn C++ properly.
I know you are just trying to help (as I often do myself), but in this case I would say that the correct medicine would be to spend a week or two with a good C++ book and then come back to the problem.

(Sorry if I'm being an ass, I don't intend to; I'm just trying to be frank).

elwydd

  • Newbie
  • *
  • Posts: 9
    • View Profile
Re: Speedproblems with draw to window
« Reply #8 on: May 07, 2014, 12:43:02 pm »
Well I know what you mean, and I would do that If I would have the time to learn all the basics. But I don't. So I won't. And I don't think that  the proper C++ coding knowledge would help to solve my initial probs.

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10998
    • View Profile
    • development blog
    • Email
Re: Speedproblems with draw to window
« Reply #9 on: May 07, 2014, 12:49:33 pm »
Good C++ knowledge and experience with basic C++ classes etc. will make a lot of problems "vanish". It will also save you a lot of time, that you're now spending in trial-and-error rituals. ;)
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

select_this

  • Full Member
  • ***
  • Posts: 130
  • Current mood: just ate a pinecone
    • View Profile
    • darrenferrie.com
Re: Speedproblems with draw to window
« Reply #10 on: May 07, 2014, 12:58:39 pm »
I would do that If I would have the time to learn all the basics. But I don't. So I won't.

I have to question why you're programming at all if you 'don't have time to learn the basics'. Not meaning to discourage you, but I think you'll need a change in attitude if you want to improve as a programmer and, as a consequence, spend less time debugging and asking questions / waiting for answers on common issues.
Follow me on Twitter, why don'tcha? @select_this

elwydd

  • Newbie
  • *
  • Posts: 9
    • View Profile
Re: Speedproblems with draw to window
« Reply #11 on: May 07, 2014, 03:35:06 pm »
Yes you're right it would safe me a lot of problems if I would know more about everything. But where isn't that so. And I do belive I know some basics about C++ classes. The Objhandler with drawing and update position is now a class yay.... (Still have these lags perhaps codeblocks like I said yesterday when I was halfasleep and asked every question I got, without thinking about itself)

@Ghostmemory
I've and I want to program a game for a project in the university. I never waited for any of your answers I was trying to find the answers myself in the meantime.
The problem is that I don't have time right now because it's not the only thing I've to do for university and yes there is a deadline.
What can I do if the prof didn't teach us the basics and just said make a game...
But when I'll have time I'll take a book and take my time.
Till then I won't bother you anymore

select_this

  • Full Member
  • ***
  • Posts: 130
  • Current mood: just ate a pinecone
    • View Profile
    • darrenferrie.com
Re: Speedproblems with draw to window
« Reply #12 on: May 07, 2014, 03:42:16 pm »
@Ghostmemory
I've and I want to program a game for a project in the university. I never waited for any of your answers I was trying to find the answers myself in the meantime.
The problem is that I don't have time right now because it's not the only thing I've to do for university and yes there is a deadline.
What can I do if the prof didn't teach us the basics and just said make a game...
But when I'll have time I'll take a book and take my time.
Till then I won't bother you anymore

That makes more sense now; in the post I quote you came across as a little obstinate, that's all, and now you've explained more clearly I understand where you're coming from. Just please be aware that a deeper understanding of the tools you're using will only aid you in the long run and all will be fine and dandy  :)

In relation to your original question, I can't see anything that would immediately cause lag besides what other people have already highlighted. You might want to eliminate other outside factors too e.g. other processes hogging the CPU (I've noticed this happen a lot on Ubuntu 14.04 recently).
Follow me on Twitter, why don'tcha? @select_this