moonman

[eigenbom]

Thx, haha, no it's not a feature. My next milestone is to rewrite a lot of the physics stuff to make it nice and solid.

[eigenbom]

But it's still possible, for instance if you take image above and just walk to the left into the water and then as far left as possible. The moonman's head will then be stuck in the wall and if you jump it's sometimes possible to fall down.

So I spent the last few weeks integrating Box2D into moonman, so now all tiles are completely impenetrable.

Here's a pic!


There's a test build here (windows) but nothing's really changed on the surface, and I've disabled animation. But if you're interested in seeing a SFML/Box2D/tile-based platformer in action then give it a go.

F1: profiler
F8: show physics bodies



CHANGELOG

0.21 06/11/2012
Refactored physics to use Box2D
added glm lib
added variable jump height and jump after fall delay
fixed ascent control
added platforms
Use a smaller fixed timestep with proper accumulator
Renderer interpolated for smoother results
Added basic ladder support in physics (not yet in-game)
Added physics debug drawing (f8)
Smoothed camera a bit
Sped up physics by ~400% with a simple 4x4 tile grouping optimisation
increased platform height, added contact normal check, and decreased foot height
Stackable blocks now act properly, can't have stackable slopes unless upside down
Upside down slopes behave properly now
moved physics sim() to execute phase, added fluid manager toprofiler
basic support in physics for multiple chunks
incremented version number, disabled animation
mm accelerates faster up slopes to give fluidity
extended platform length
platforms only collide if normal has a small x component, which fixes hitting the sides of the platforms
tuned some constants in physics
Made logging more verbose, but still needs to be verboser

[The Terminator]

Moon man looks cool! I'm on my iPhone at the moment so I can't try it but it looks pretty fun. I like the water update

[FRex]

Cool. Did you make own box2d debug drawer or..?
Also, what did you use for tiles? Chain shapes? I ask cus the physics seem a bit jiterry. But since every tile is removeable it has to be own shape.. :|
Also may I ask why choose cegui instead of certain other gui dedicated for sfml?

[Nexus]

Cool, looks already quite nice

The first time, the game crashed at starting with 1024x768, now it works.

The collision detection is not very fluent, one changes the height while walking. When you stand still, the character trembles for a short time. I don't know what you can do on Box2D side, but I'm sure you find a possibility

[eigenbom]

thx guys, yeh the jittery-ness is because of both the camera movement and box2d, and to be honest i hadn't really noticed it, but i do now!

for the debug drawer i just hacked apart the box2d one, i basically just do an AABB query of the screen rectangle to get all the visible fixtures then use slightly hacked versions of the debug drawing routines in b2World, just copied and pasted into my own classes.

the tiles are all just separate polygon shapes, grouped into bodies of 4x4 tiles to speed up the broadphase. i'm actually super-stoked to see it running at under 2ms/frame on my comp, but i'll have to address that jitteriness, most likely just in the renderer.

hmm cegui, yeh ... you know i think I tried tgui and sfgui a while back , as well as other gui libs like gwen etc., but i think i settled on cegui mainly because it has been used successfully in commercial projects, although it is quite a beast to use, considering my gui requirements are quite low!

[eigenbom]

The first time, the game crashed at starting with 1024x768, now it works.

Hmm, could you try crashing it again and checking/posting the log.txt? Is your screen resolution less than 1024x768?

[FRex]

I think somewhere in the manual it's stated that you can have all static fixtures on one body. Also , the jitter can be caused by using 1 shape/ 1 tile, that's the reason edge chains exist(to fix problem with jitter movement over touching shapes).

[eigenbom]

I think somewhere in the manual it's stated that you can have all static fixtures on one body.

Oh really? I'll have to check that out.

Also , the jitter can be caused by using 1 shape/ 1 tile, that's the reason edge chains exist(to fix problem with jitter movement over touching shapes).

Yeh I considered chain shapes, and they are still an option, but they require a more complex algo to setup. I solved earlier inter-tile issues by using a circle for moonman's feet, so if I can fix the small amount of jittering in the renderer then I'll be happy.

[FRex]

Note that every fixture must have a parent body, even fixtures that are static. However, you can attach all static fixtures to a single static body.

http://www.box2d.org/manual.html in 2.2
I don't know what impact on performance would that have but probably none since density, mass, velocities and dampings don't apply to static bodies.

[eigenbom]

Note that every fixture must have a parent body, even fixtures that are static. However, you can attach all static fixtures to a single static body.

http://www.box2d.org/manual.html in 2.2
I don't know what impact on performance would that have but probably none since density, mass, velocities and dampings don't apply to static bodies.

Note that every fixture must have a parent body, even fixtures that are static. However, you can attach all static fixtures to a single static body.

Hmm .. yeh it says that you can do it, but doesn't say anything about whether its optimal to do so or anything. As far as I understand it, Box2D uses a body's AABB in its broadphase, so being smart about how you group your static fixtures into bodies should give a speed-up, which is basically what I've done.. but then again I have no idea what magic Box2D is doing underneath..

[FRex]

It's optimal. Trust me. 
I know, you don't...well, suit yourself  :
Erin recommends it:
http://www.box2d.org/forum/viewtopic.php?f=3&t=7968

I recommend placing many fixtures on to a few static bodies. I would use one static body per 100 meters.

Box2D has some traversals of the body list that can be slow when the lists are huge.

[eigenbom]

It's optimal. Trust me. 
I know, you don't...well, suit yourself  :
Erin recommends it:
http://www.box2d.org/forum/viewtopic.php?f=3&t=7968

I recommend placing many fixtures on to a few static bodies. I would use one static body per 100 meters.

Box2D has some traversals of the body list that can be slow when the lists are huge.

Ah cool, thx heaps for the link. It's not that I don't trust you, its just that its a complex problem, and I have no idea what your experience with tile-based box2d programs are..

I don't think Erin is talking about terrain that can undergo lots of local changes like mine, but rather probably a single static body that is created at start-up and not changed afterwards. But if I get a chance I'll do a quick hack and test it out, only when I implement it and see the actual speed-up would I be convinced. And its currently working so fast anyway, I've already reduced it from like 40ms to 2ms per frame, which is approaching 'fast enough' for me.

[FRex]

None really, but googling "<library name> forum <problem>"(ie "box2d forum many fixtures on one static body" top 5th result) is extremely effective.

[eigenbom]

None really, but googling "<library name> forum <problem>"(ie "box2d forum many fixtures on one static body" top 5th result) is extremely effective.

um, ok then, well thx