Jump to content

  • Log In with Google      Sign In   
  • Create Account


We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.

Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!


Member Since 29 Mar 2012
Offline Last Active Yesterday, 02:45 PM

Posts I've Made

In Topic: Stuttering on game start - missed collisions

20 December 2014 - 02:36 AM


I believe most JVMs use heuristics to determine which code is important enough to spend time compiling and optimising. So on startup, it uses a basic mechanism to get the program running, as much initialisation work is done once and never executed again. As the program spends more time running particular segments, these are progressively recompiled and optimised.


It is possible that you're seeing this in action. It would be interesting to keep a record of the delta times and number of updates in a buffer, and log them.


Other than that, mousetail is probably right. You might need to increase your physics rate to handle this, or use a physics library that helps address this, e.g. Box2D has the concept of "bullets":


Game simulation usually generates a sequence of images that are played at some frame rate. This is called discrete simulation. In discrete simulation, rigid bodies can move by a large amount in one time step. If a physics engine doesn't account for the large motion, you may see some objects incorrectly pass through each other. This effect is called tunneling.
By default, Box2D uses continuous collision detection (CCD) to prevent dynamic bodies from tunneling through static bodies. This is done by sweeping shapes from their old position to their new positions. The engine looks for new collisions during the sweep and computes the time of impact (TOI) for these collisions. Bodies are moved to their first TOI and then halted for the remainder of the time step.
Normally CCD is not used between dynamic bodies. This is done to keep performance reasonable. In some game scenarios you need dynamic bodies to use CCD. For example, you may want to shoot a high speed bullet at a stack of dynamic bricks. Without CCD, the bullet might tunnel through the bricks.
Fast moving objects in Box2D can be labeled as bullets. Bullets will perform CCD with both static and dynamic bodies. You should decide what bodies should be bullets based on your game design. If you decide a body should be treated as a bullet, use the following setting.
bodyDef.bullet = true;
The bullet flag only affects dynamic bodies.
Box2D performs continuous collision sequentially, so bullets may miss fast moving bodies.



I am already using box2d, but implemented a particle system on top of it and i am calculating the contact points based on the static fixtures (Chain shapes) myself, including the solving of the velocity constraints using an sequential impulse method - nearly the same method box2d uses, but without rotation dynamics (not needed for particles).


Maybe changing the solver to a CCD like system would help. I heard about speculative contacts, but had problem understanding the "Conservative Advancement" part.



It hangs for a while, maybe 10 frames and then it starts normally. If i increased my gravity to a normal earth-like level 9.81, then some line segment collisions are being missed.

Fix your timestep.

Your fundamental problem is that a variable-length frame time is causing your physics to behave differently. Your physics simulation should be deterministic (not affected by any randomness). It is currently being affected by the randomness of frame time. That's a bug.

You also generally need to cap your frame time (to avoid the spiral of death), have graphics interpolate between physics states (to avoid jittery animations), and tie almost all of your other game systems to the fixed timestep (to avoid all the other possible bugs regarding overly long or unexpectedly short frame times).


It looks like maybe you are using a fixed timestep. Double check that you're using the fixed dt in your game logic and not the variable one. If you only see this bug during a long frame, it's definitely a time step issue. If you see it all the time, your objects are moving too fast and you need to cap their speed, use continuous collision detection, or decrease your fixed timestep time.



I already use a fixed timestep update loop. But i was unsure if this is correctly implemented, therefore i posted just the code partition for the game loop.

Also i use linear interpolation for the rendering part and record the previous position for every entity as well.

In Topic: Jump impulse based on length of pressed jump-button in box2d

05 December 2014 - 05:58 AM

Thats the approach i implemented now, works really good after tuning the properties. Thanks.


Box2D objects each have a gravity scale, if i remember correctly, so you could do as ferrous said.

Alternatively, you could keep a force or impulse accumulator in you object, let's call it jump_energy, and each frame you want to apply F amount of force if the jump key is down, first check if the object has any jump_energy left, by taking force_to_apply = std::min(jump_energy, F), subtract jump_energy -= force_to_apply, and do object.applyImpulse(force_to_apply). You have to fiddle with the numbers to get the right feel, but this is one way to do it.
You could do something similar, but with distance travelled as the check, or with a timer so the player can keep the jump key down for x seconds before you stop applying the jump impulse every frame.


Also, i seem to vaguely remember there being a problem with this if applying impulses every frame, and it's done with forces instead, but don't hold me to this, and try it both ways.

In Topic: Is there a better way for putting game logic in beginContact

30 November 2014 - 12:00 PM

Thanks for the tips.


I now using a list for every which is contained of other entities (collision list) and just add/remove an entity to/from that list.

The only difference is what an item in the collision is a pair of an counter how many this entity does being touched and the entity itself.

Works great so far...


Here is a bit code:

	public void beginContact(Contact contact) {
		if (contact.getFixtureA().isSensor() || contact.getFixtureB().isSensor()) {
			GameObject sensorObject = (GameObject) contact.getFixtureA()
			GameObjectList sensorList = sensorObject.getCollisionList();
			GameObject enemyObject = (GameObject) contact.getFixtureB()
			GameObjectList enemyList = enemyObject.getCollisionList();

	public void endContact(Contact contact) {
		if (contact.getFixtureA().isSensor() || contact.getFixtureB().isSensor()) {
			GameObject sensorObject = (GameObject) contact.getFixtureA()
			GameObjectList sensorList = sensorObject.getCollisionList();
			GameObject enemyObject = (GameObject) contact.getFixtureB()
			GameObjectList enemyList = enemyObject.getCollisionList();

In Topic: How to create line segments from tile map outlines

07 November 2014 - 04:44 PM

I did it, it works - Now i just need to remove the vertices between the corners and i am done!

The best thing was it was just two more steps in my state-based contour tracing system... :-)

In Topic: How to create line segments from tile map outlines

03 November 2014 - 01:30 PM

Ok i implemented a much better algorythmn which detects all the outlines perfectly... but i still havent figured out a way to traverse the created edges and create the chain-edges / line segments yet.


There are two things which needs to be done i thing to get this thing to work.


First of, the connected edges should be fixed, so that that shared vertices get removed.

Secondly, built a algoryhtmn that traverse the tile in the directions and create line segments out of it.


What i have created is:


- A list of edges. A edge is pair of two indices to the actual vertices + the actual tile position + the edge index (is it a left, right, top, ot bottom edge)

- A list of vertices without any duplicates.


Does someone have an idea?


Here is a image from all the tile edges drawing its vertices (blue) just connected with a red line and displaying each tile position for every edge center.



Greetings Final.