I don't think that fetching positions from box2d and setting them to sprite is 'logic'It's 'update', so it's definitely not 'drawing' ;)
I don't say it's bad or I want it to change
It's 'update', so it's definitely not 'drawing' ;)It is update but not logic update. That's the point : anything related to visuals (except debug drawing, which is for debug so it can be crapped up) happens in draw() and anything related to game logic happens in Run() or in collision callbacks from box2d. Moving pre-draw update into run can't happen because it'd mix these two unrelated things(now any mistakes can be traced like: -> turn debug drawings on, is sprite at same position as body ->yes = Run(logic) is messed and bodies are at wrong positions, no-> draw(displaying) is messed and graphical representations are at wrong positions),not everything that can be drawn can be Ran and Run() and draw() cycles are not synchronized(they are on 60 fps but it's not requirement and framerate doesn't affect speed of game simulation).
So what do you expect from this discussion?I'm wondering what is most 'clean' and reasonable way to handle that besides breaking const that people use.
and I think you agree with that when you sayPart of the problem(which makes it a rare problem most people might not face?) is I don't iterate through entities to update their positions and don't have chance to update their sprites then.
It is update but not logic update. That's the point : anything related to visuals (except debug drawing, which is for debug so it can be crapped up) happens in draw()Do you just want to update the graphics according to the logics, or do draw() calls advance the animation state each time?
For example, calling draw() twice instead of once should not make a difference with respect to the object state.It doesn't 'change' the object after the first call that happens after world step.
Why can't you write a method updateGraphics() or alike that is not const?Because then I could give up the inheritance from drawable and just roll own abc that does both in one call( or even two calls) since App.draw(**it); (with it being iterator of container of drawable pointers) is no longer safe.
It doesn't 'change' the object after the first call that happens after world step.Okay, so the graphical properties needn't necessarily be members, right? You could create new sprites everytime, but don't do it for performance reasons?
Okay, so the graphical properties needn't necessarily be members, right? You could create new sprites everytime, but don't do it for performance reasons?Well YEAH.. ??? , but that idea is so performance killing I never considered it outside of debug draw class.
I still don't get why it shouldn't be a logic update...Logic updates are things that change the entity and b2world like key pressed, late responses to collision callbacks, setting velocities and applying forces to bodies ect.
It then doesn't matter which 'loop' runs at which FPS, because the sprites position get updated as soon as their logic parts could've changed.When there are more iterations of game logics than graphics, this approach updates the graphics unnecessarily often.
Well YEAH.. ??? , but that idea is so performance killing I never considered it outside of debug draw class.It depends on the amount of work, I have already done that without performance issues. If you reset most sf::Sprite attributes, you are not much faster than the constructor.
When there are more iterations of game logics than graphics, this approach updates the graphics unnecessarily often.Hmm... I see. I didn't really think enough far. :)
Hmm... I see. I didn't really think enough far.Swords' sprites are drawn very rarely so they don't need to be updated most of the time. They are attached to player as sensors and zero out their collision filters and quit their draw after one bool check unless the sword is in use.
It depends on the amount of work, I have already done that without performance issues. If you reset most sf::Sprite attributes, you are not much faster than the constructor.Even if speed was same I'd stay with mutable as is, that way my entity c-tor(which knows the size of physic body but doesn't keep it) can rescale sprite and set origin and texture as needed instead of me doing it every frame in addition to setting position.