Debug draw for box2d physics World

[Azhukar]

Pass this function your physics world object and call it in love.draw(). Helps with seeing what's going on.

Fixtures have random color, sensors are always pure blue, joints are green lines/points, contacts are red points.

Code: Select all

debugWorldDraw = require("debugWorldDraw")
function love.draw()
	debugWorldDraw(world,x,y,width,height)
end

--x,y = top left corner of drawn world area
--width,height = width and height of drawn world area

Update:
-fixed a bug causing multi-fixture bodies to be drawn many times
-modularized
-now uses math.newRandomGenerator

[fxva]

cool

[tio]

There's a little problem in this function: the colors and line widths are not restored at the end of function.
Despite that, it's a very great function

[Azhukar]

the colors and line widths are not restored at the end of function.

You never restore color or line width after you change it, you always change it before you use it. That way you never run into a problem with colors/etc leaking into other draw calls.

[tio]

I always thought that this was the right way (save current colors, change to draw a thing and change it back), mainly because of bitmap drawing.
Good to know that

[Robin]

I always thought that this was the right way (save current colors, change to draw a thing and change it back), mainly because of bitmap drawing.
Good to know that

Both ways are the right way, really. Libraries should always restore things like colours, so that you can always use it. Code that doesn't restore colours can only be used with the change-colours-every-time way of doing things.

[Azhukar]

Both ways are the right way, really. Libraries should always restore things like colours, so that you can always use it. Code that doesn't restore colours can only be used with the change-colours-every-time way of doing things.

Working with a state machine and acting upon baseless assumptions of the state it is in is prone to unexpected behavior.

If you call a draw operation and desire it to use a certain color, yet you did not check whether the color you desire is the color you're using then you are in fact doing it the wrong way.

Comically by your own example the code that doesn't presume state will perform as expected, yet code that does won't.

[tio]

Well, since I don't need to take care about color (in normal circumstances) to draw sprites, I often don't need to set color values. When I do, I restore to whatever state it was before (since previous state was working as expected).

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.

[Azhukar]

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.

[Robin]

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.

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