Jump to content

  • Log In with Google      Sign In   
  • Create Account


PixelPrime11

Member Since 08 Mar 2011
Offline Last Active Nov 13 2012 01:45 AM

Posts I've Made

In Topic: Static self referencing classes, a good idea or not?

10 November 2012 - 06:43 AM

Thanks, I can see your point about it potentially closing the door to using further instances of the class for other reasons.

It might help to give some background on the class. It's a Canvas for a drawing / modelling application, so I know for a certainty that there can only ever be one instance of the class active at any time (this isn't a multiple-workspace type of project). A workspace can only have one canvas.

Perhaps I need to think about reorganising the communication of data between the classes outside of the workspace so that rather than relying on a call directly to a static method inside of the Canvas object, I can pass a reference to the (only) instance of the Canvas to the required classes as an argument.

It'll just mean a bunch of refactoring - but eh, if we had a few bucks everytime we did that... Posted Image

In Topic: Matrix operation order causing positioning problems!

09 November 2012 - 01:45 PM

I'm not sure what you mean by which Matrix Library, unless you mean LWJGL's implementation of this?

The methods I use to accomplish the transformations are as follows:

[source lang="java"]glLoadIdentity();glTransform3f(camera.x, camera.y, camera.z);glRotate3f(camera.yaw, 0.0f, 1.0f, 0.0f);glRotate3f(camera.pitch, 1.0f, 0.0f, 0.0f);[/source]

So, if I were trying to draw an object in the world, I'd call the above code first, then this:

[source lang="java"]// move to the object's coordinatesglTranslate3f(position.x, position.y, position.z);// rotate the object (Y axis only)glRotate3f(rotation.y, 0.0f, 1.0f, 0.0f);// draw the objectglBegin(GL_QUADS); // vertex draw operationsglEnd();[/source]

In Topic: 2D Platform edge collisions

17 October 2011 - 10:33 AM

SOLVED!

Ok, so the solution was a combination of things actually, but in the end I've found something that's now producing the perfect result - no more sticking, jittering or unsightly artefacts! And all this with pixel-perfect collision responses.

I finished with an implementation of the checking of X intersections first, then the Y. The Y checks would only run if the X checks failed.

Here's the final collision code:

N.B. This code assumes that the player's bounding box will be smaller than the bounding boxes of objects it needs to be stopped by (i.e. walls, floors etc).


function DoCollisions()
{
	var newX = Player.x + speedX;
	var newY = Player.y + speedY;
	var runCheckY = true;
	var runCheckX = true;
	
	for (var i = 0; i < Level.numChildren; i++)
	{
		var clip = Level.getChildAt(i);
		
		if (getQualifiedClassName(clip) == "BLOCK")
		{
			var objectBothAxes = new Rectangle(newX, newY, Player.width, Player.height);
			
			if (WillIntersect(objectBothAxes, clip))
			{
				var objectOnlyMoveX = new Rectangle(newX, Player.y, Player.width, Player.height);
				
				if (WillIntersect(objectOnlyMoveX, clip))
				{
					if (runCheckX)
					{
						// we've intersected on the X axis, so stop horizontal movement
						if (speedX > 0)
						{
							// moving right, colliding with the LEFT side of the block
							speedX = 0;
							Player.x = clip.x - Player.width;
							runCheckX = false;
						}
						else
						{
							// moving left, colliding with the RIGHT side of the block
							speedX = 0;
							Player.x = clip.x + clip.width;
							runCheckX = false;
						}
					}
				}
				else
				{
					if (runCheckY)
					{
						var objectOnlyMoveY = new Rectangle(Player.x, newY, Player.width, Player.height);
						
						if (WillIntersect(objectOnlyMoveY, clip))
						{
							// we've intersected on the Y axis, so stop vertical movement
							if (speedY > 0)
							{
								// moving down, colliding with the TOP side of the block
								speedY = 0;
								Player.y = clip.y - Player.height;
								runCheckY = false;
							}
							else
							{
								// moving up, colliding with the BOTTOM side of the block
								speedY = 0;
								Player.y = clip.y + clip.height;
								runCheckY = false;
							}
						}
					}
				}
			}
		}
	}
}


This code, however, strongly relies on important checks made to this function, which looks for the intersect:


function WillIntersect(object, clip)
{
	if (object.x + object.width - 1 < clip.x || object.y + object.height - 1 < clip.y || object.x + 1  > clip.x + clip.width || object.y + 1 > clip.y + clip.height)
	{
		return false;
	}
	else
	{
		return true;
	}
}


I discovered that the problem wasn't with zeroing out the speedX and speedY values, but with the code I was using the reposition the object in the collision response.

I found out that if I change the line of code Player.x = clip.x + clip.width (in response to moving left into the right side of a block) to the following code:

Player.x = clip.x + clip.width + 1

I wouldn't get any more 'sticking' or jumping artefacts. However, it left me with a 1 pixel gap between the collision surface and the player.

Solving it was simply a matter of changing the collision intersection threshold by 1 pixel, thus moving it from collision response to collision detection. You can see the 1 pixel threshold has been moved into the WillIntersect(...) method. This means, technically, that you're actually allow to invade the block by 1 pixel before the check returns a valid collision, whereas before you could still trigger it by being slightly outside, or on the edge.

Wow, that has been a week-and-a-half long problem now resolved.

I can't thank you both enough for giving me a fresh perspective on this, and I hope the information contained in my reply above will help others overcome this issue.

In Topic: 2D Platform edge collisions

17 October 2011 - 09:52 AM

These are both quality suggestions, thank you both so much!

I'll see if I can implement a good checking method taking these points into account. It's unfortunate that something so simple can turn out to be so complicated to resolve!

I'll post my findings, and if solved, my final code for anyone else having these problems too!

In Topic: Universe Entity Storing and Retrieving

17 October 2011 - 09:49 AM

It really does sound like the way to go. So basically the player position (possibly the center of the screen) would tell which node the player is currently at, and then it would page back from there loading entities till it reaches a node that covers the entire screen? I should probably do a lot of reading up on quadtrees first before asking to many questions as I believe there there are lots of information on this to read, but any more input on this is still appreciated of course. :)

Thanks PixelPrime11 for the response!


No worries at all.

I just had a thought - if you're making a 3D game then a quadtree might not be the ultimate solution since that deals mainly with 2D data structures. The last time I checked we lived in more than 2-dimensions!

Octrees are the 3D equivalent, although it's possible to still represent a galaxy in a Quadtree - providing, of course, you don't have one element sharing the same Y position in space as another. Of course, that's impractical, so looking at Octress for full space partitioning would be the way forward, I think.

Your reasoning is sound, however. You'd locate your player's position in relation to the relevant tree node and work outwards until you've encompassed your entire 'active' region. Superimposing your intended new position into the quadtree should give you the overlapping nodes and give you the new data structures to peek inside. Quad or Octree, it's pretty much the same theory either way, just more dimensions to think about.

I don't have a tremendous amount of experience working with anything other than quadtrees, though, so you might need some advice from someone else much more versed in these matters :)

PARTNERS