Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 13 Aug 2006
Offline Last Active Oct 11 2014 04:55 PM

Topics I've Started

Ammo.js Collision Separation

04 September 2014 - 07:31 PM

I'm using Ammo.js with the Goo webGL engine, and I'm working on trying to get triggers implemented, but I'm having some struggle finding a 'good' way to handle collision separation.


Here is a jsFiddle which shows how to handle collision starting:




I'm also planning to implement a 'callback' type thing like this:




So when one object collides with another, it will pass in some collision info.


The problem I am having, is figuring out a good way to handle the separation, when the two previously colliding objects are no longer colliding.


Supposedly, there are gContactProcessed and gContactDestroyed callbacks which I could tap into, but I don't think these are currently possible.




So I'm reaching out, before I start from scratch creating my own functionality, to see how other people have handled this.


Here is my main idea:


1. Have a map of collisions.

2. At the start of each pass, set a boolean value for all current collisions to false.

3. The fist time a collision is added to the map, trigger the onCollisionBegin callback, with the data from the collision.

4. During the collision check, if two objects are still colliding, set their boolean value to true.

5. For each collision in the map, if their boolean value is still false, trigger the onCollisionEnd callback and remove it from the map.


Does something like this seem good?  Are there any current implementations of Ammo.js with collision separation mechanics that I can look at?


Thank you in advance!

'Fixed Timestep' wrap around problem

03 May 2013 - 02:40 AM

I've been working on a personal 2d HTML5 Canvas engine, and I am trying to implement Glenn Fiedlers fixed time step algorithm:



I have read through these other examples of how Box2D did it:




The problem I am having is that objects don't wrap around the edges of the screen properly.


For example, if I have a scrolling background, and the position gets to greater than 800, and I want to wrap it back around to 0, you can see it visually moving there, rather than instantly appearing.


I am thinking, perhaps i don't know the proper way to implement this awesome algorithm.


Here is a basic pseudo code of what I am doing...


function update(){
// code to determine time passed, etc
 while (accumulated >= TIC) {
  fixedUpdate( TIC );
  accumulated -= TIC;
 ticLeft = accumulated / TIC;
function resetSmooth(){
 renderPos = oldPos = currentPos;
function fixedUpdate( dt ){
 oldPos = currentPos;
 currentPos += velocity;
function render (ticLeft){
 smooth = 1.0 - ticLeft;
 renderPos = (currentPos * ticLeft) + (oldPos * smooth)


The smoothing is awesome, but it is just the wrap around warping that I need help figuring out.  Also, in my collision detection  and what not, do I use currentPos, oldPos, or renderPos ? biggrin.png


Thank you for any help, and here is a quick demo of what I am talking about:




It works in IE 10.0.4, Moz 20.0.1, and Chrome 26.0.1410.64 m

Nearest node to START, but in the direction of GOAL?

28 March 2013 - 02:42 PM

I have a grid of nodes, which contain a list of neighbor nodes.  I wanted to create a FindPath function, with a Start position and a Goal position (both 3d Vectors, using X and Z, UP is 0).  I can easily get the nearest node to start, and the nearest node to goal, but I wanted to also make sure these nodes are in the direction the unit would be travelling.


For example, I don't want the unit to go AWAY from the goal, and then back track toward the goal, because the 'nearest' node to him was behind him.  I'll supply a picture to make more sense.




So in this picture, you can see the 'nearest' nodes to start and goal are where the red X's are.  Start is where the spider is located, and goal is where the black arrow is pointing.  You can see, the nearest start node, is actually in the other direction of the goal, where the yellow circled one is in the direction of the goal, even though it is further than the 'nearest' one.  The same goes for the nearest goal node.


I may be making this harder than it needs to be, but I can't seem to figure out the proper maths involved to get the nodes circled in yellow as 'start' and 'goal' nodes.


Here are the things I know:






I need to use this information, while iterating throughout the list of nodes to determine:





While iterating, I can figure out:





So using all this information, I need to determine nearest node to startVector and the nearest node to goalVector, which are also in the direction from start to goal.


Any ideas?

I want your opinions on Mobile controls and general game play.

30 January 2013 - 07:53 PM

The game is meant to be developed for portable tablets, specifically the Android.  It is an RPG dungeon crawler style game, using 'rogue' like dungeon generation.


I am debating between two control schemes for mobile devices.

1. Taps and Swipes:

Game mechanics, such as movement, attacks, etc would all be handled through tapping and swiping the screen.

2. DPad + Buttons:

Movement and actions would be performed using a DPad icon in the lower left corner, and 2-4 buttons on the lower right corner.


The second opinion I am interested in is for overall gameplay.

1. Turn Based:

The user would be able to move around the level freely, until combat begins, at which time combat would go into a turn based mode.  The enemies would have a turn to move and attack, then the user would have a turn to move and attack.  Initiative would be random.

2. Real Time Action:

The user would be able to move freely around the level, combat would be handled in real time.  Basically, the user would enter a room and start hacking and slashing.


I would appreciate any feedback about these topics.  The engine I will be using is Unity3d.  Thank you in advance.

Javascript - Better to instantiate variables, or leave them undefined?

14 October 2012 - 06:55 AM

In Javascript, if I know a variable type, but not necessarily the value, is it better on memory or run-time performance to instantiate it with a 'dummy' value, or is it better to just leave it undefined, and then only instantiate it when it is first needed?

For example...

var array1;
var number1;
var string1;
/* vs */
var array2 = [];
var number2 = 0.0;
var string2 = "";

// later in code...
function onInit(){
number1 = 3.142;
number2 = 2.718;
string1 = "Hello";
string2 = "World";

Is it best to fill the variable with a dummy 'type' or just leave it 'undefined' ?