Punching holes in const corectness (of sf::Drawable)

[FRex]

Do you ever do that? It at times does get annoying how draw is const method.
Things like updating position of a sprite, updating animation count, updating frame count, ect. become a bit problematic, especially if the reason for derieving from drawable in the first place was for polymorphism.
It seems the only other way around that would be to create own drawable abc and then derieve all the sfml drawables from it.

[Laurent]

This is exactly why draw is const -- to force people to do things right, even if it pisses them off

Although mixing update and draw is sometimes convenient, a good practice is to always separate logic and drawing.

And, most important, if draw was non-const it would break a lot of users code in which the whole drawing process is const.

[FRex]

I don't say it's bad or I want it to change, I say it might be annoying at times. I don't think that fetching positions from box2d and setting them to sprite is 'logic'. Especially if the object has no logic part in it and just displays a sprite at box2d coords. I would have to inherit it from my runable abc and then 'run' it(even though it does nothing except update sprite pos - which doesn't affect the game). And also my fps(whatever/second) and update cycles(60/second) are untied so I'd update sprites too often or too rarely.

[Laurent]

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'

But ok, I understand your concern. But it would certainly be worst to make it non-const; and I think you agree with that when you say:

I don't say it's bad or I want it to change

So what do you expect from this discussion?

[FRex]

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.
Update proc dedicated to pre-drawing updates beats the point of inheriting from drawable instead of making own public Draw(sf::RenderTarget& target,sf::RenderStates states) without const and putting draw and update there since at some point we would need to know the real type to call our pre-drawing anyway.

and I think you agree with that when you say

Part 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.

[Nexus]

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?

Does it make a difference for the object if draw() is called once or twice?

[FRex]

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.

while(App.isOpen())
{
/*world step*/
App.draw(something);
}

Would look exactly same as

while(App.isOpen())
{
/*world step*/
int a=5;
while(--a)
App.draw(something);
}

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.

[eXpl0it3r]

I still don't get why it shouldn't be a logic update...

You don't update the logic position yourself, but Box2D does and thus after letting Box2D update the (logic) positions you copy them onto your sprites. 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.

Maybe I got you all wrong, but I don't see the need for having updates in the draw call.
If you don't feel comfortable with the update/draw or update/updateGraphics/draw solutions then you're maybe better of with your own draw function...

[Nexus]

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?

In this case, there is indeed a better approach: Member variables that are not part of the object's logical state can be attributed with mutable to allow cache semantics. If you use this keyword, make sure none of those variables appear in the class's interface.

[FRex]

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.

[Nexus]

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.

[eXpl0it3r]

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.

[FRex]

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.