Debug draw for box2d physics World

[Azhukar]

You shouldn't need to do love.graphics.setColor(255, 255, 255) before every image you draw.

Yes, only the ones you intend to be drawn with the same color as in the image file.

[tio]

Well, since I don't need to take care about color (in normal circumstances) to draw sprites

Only you do, if you intend to draw your sprites in the color as you have them in your image file then you have to set the color to full white, i.e. 255,255,255 or you will start wondering why your sprites suddenly flicker when you added X feature.

When it happens, I do exactly what I did here

Again, if that's not the right way to do, sorry, my bad. I just found the behavior weird and thought reporting was a good idea.

Nono, you were right, don't listen to Azukar.

Well, it's valid since Azukar did the function

You shouldn't need to do love.graphics.setColor(255, 255, 255) before every image you draw.

So I thought, since wiki doesn't cite it on love.graphics.draw.

[OmarShehata]

You shouldn't need to do love.graphics.setColor(255, 255, 255) before every image you draw.

Yes, only the ones you intend to be drawn with the same color as in the image file.

Think of it this way.

Always taking care to keep a default state for the system removes a lot of headaches. If you have 200 draw calls in your code, 5 of which are rendered with different colors, you'd only need to setColor for those 5 sprites (a total of 10, once before the sprite and once to reset it to the default), allowing you to assume the color will always be 255,255,255 unless you explicitly change it.

There's no right or wrong way to this, as Robin mentioned, but I personally prefer assuming a default state and anything that changes it must change it back after it is done. So that I don't have to worry about resetting color and any other transformations before every draw call.

[Azhukar]

Think of it this way.

Always taking care to keep a default state for the system removes a lot of headaches. If you have 200 draw calls in your code, 5 of which are rendered with different colors, you'd only need to setColor for those 5 sprites (a total of 10, once before the sprite and once to reset it to the default), allowing you to assume the color will always be 255,255,255 unless you explicitly change it.

Repeatedly setting the same state is of course bad, that was not the issue debated.

There's no right or wrong way to this, as Robin mentioned, but I personally prefer assuming a default state and anything that changes it must change it back after it is done. So that I don't have to worry about resetting color and any other transformations before every draw call.

When you're working with libraries from many different people with various habits, the only way to ensure correct state is to always set it the way you want it as you cannot rely on others adhering to your own habits.

[tio]

Think of it this way.

Always taking care to keep a default state for the system removes a lot of headaches. If you have 200 draw calls in your code, 5 of which are rendered with different colors, you'd only need to setColor for those 5 sprites (a total of 10, once before the sprite and once to reset it to the default), allowing you to assume the color will always be 255,255,255 unless you explicitly change it.

Repeatedly setting the same state is of course bad, that was not the issue debated.

It could be, since it's a draw function o/

[Robin]

When you're working with libraries from many different people with various habits, the only way to ensure correct state is to always set it the way you want it as you cannot rely on others adhering to your own habits.

I prefer to use third party libraries that are well-behaved and don't force a particular coding style on me.

But as said, this is a matter of preference, and there isn't really an objective answer here.

[Azhukar]

I prefer to use third party libraries that are well-behaved and don't force a particular coding style on me.

But as said, this is a matter of preference, and there isn't really an objective answer here.

It is not style preference that I'm talking about, this is basics of working with state machines. If you presume a state without checking, you will run into problems.

Acting upon an unknown state is objectively incorrect.

[Robin]

*Sigh*. It's still a matter of preference. You see, my preference is that each component I use has the post-condition of a single, known state (the "default" state, if you will). Therefore, the state is always known.

The ways we like to do are functionally equivalent. You may not like mine, you may feel wrong to you, you may be disgusted by it, it still doesn't make it any less correct than yours.

This discussion is as productive and meaningful as tabs vs spaces, vim vs emacs and single-spacing vs double-spacing.

Robin out.

[Azhukar]

This discussion is as productive and meaningful as tabs vs spaces, vim vs emacs and single-spacing vs double-spacing.

But tabs are obviously better.

[tio]

This discussion is as productive and meaningful as tabs vs spaces, vim vs emacs and single-spacing vs double-spacing.

But tabs are obviously better.

And opening brackets at the same line as function definition