LÖVE

Posted: **Sat Nov 13, 2010 11:25 pm**

Taehl wrote:What same rule? Your code talks about widths and heights and positions... Not a uniformly-sized, grid-aligned tile system.

You can easily implement it in an environment like that, though.

Posted: **Sat Nov 13, 2010 11:44 pm**

Robin wrote:
zac352 wrote:
thelinx wrote:Do you write all your code that you dump in every other post in the reply view?
... Maybe.
Oh god. I can picture you programming. Typing everything in the reply box on the forums, pressing Preview, copying the resulting text, pasting it in an empty Word document, saving that as plain text and then running it...

Once I used wordpad to prove I knew HTML. There were weird unicode characters everywhere.

Posted: **Sun Nov 14, 2010 3:29 am**

If it's so easy to implement, you need to show me how it's done. As far as I can see, what you posted is incompatible with my code.

Posted: **Sun Nov 14, 2010 4:09 am**

Taehl wrote:If it's so easy to implement, you need to show me how it's done. As far as I can see, what you posted is incompatible with my code.

*is annoyed* I try to help, and you -1 me.

To test an x,y,z with your player, you must have a scale for the size of these boxes. We'll make the variable s that scale. Each cube has 8 points on it, but you only need to do two tests to check if a given point is inside of it. To get these two points,
V1=P+[-1/2s,-1/2s,-1/2s]
V2=P+[1/2s,1/2s,1/2s]
, where P is your block's position. Now we need to get all 8 points of your player.
P1=P+[-1/2s,-1/2s,-1/2s]
P2=P+[ 1/2s,-1/2s,-1/2s]
P3=P+[ 1/2s,-1/2s, 1/2s]
P4=P+[-1/2s,-1/2s, 1/2s]
P5=P+[-1/2s, 1/2s,-1/2s]
P6=P+[ 1/2s, 1/2s,-1/2s]
P7=P+[ 1/2s, 1/2s, 1/2s]
P8=P+[-1/2s, 1/2s, 1/2s]
That may look like a lot, but look closely. Now we check to see if your player intercepts the box:
Pn>V1, and Pn<V2
Do this for all the points on your player. If any given point comes out to true, you have a collision.
If you do this for each axis, instead of all at a time, you can get which axis is colliding with the box. So we do a check for each axis, and if the collision comes out to true, set the velocity on that axis to 0. If it doesn't, leave it be.

An alternate of this would be, instead of setting to 0, setting it negative. This would cause your player to bounce off floors, walls, and ceilings.

I hope I managed to clarify things, I wish to gain back my karma.

Posted: **Sun Nov 14, 2010 4:40 am**

The scale is 1 - each tile is 1 cubic meter. For sake of simplicity, let's assume the player is also 1 cubic meter.

So you're saying I'm going to have to go from 1 check per step to 8 checks per step? Can we reduce this? The player's collision shape could be a sphere or something if it would make calculations any simpler. (There's going to be more than one player, and NPCs besides, so the fewer calculations needed, the better.)

Lastly, if you can show me how this fits into the code I posted (or, if you can do better, your own method that works with my tile system), I promise you your karma back.

Posted: **Sun Nov 14, 2010 9:12 am**

Robin wrote:
zac352 wrote:
thelinx wrote:Do you write all your code that you dump in every other post in the reply view?
... Maybe.
Oh god. I can picture you programming. Typing everything in the reply box on the forums, pressing Preview, copying the resulting text, pasting it in an empty Word document, saving that as plain text and then running it...

That made me laugh.

On a side note. Why doe's zac get -k so much? I haven't spent enough quality time with him to understand why, but hes the only person I've seen with -k.

Posted: **Sun Nov 14, 2010 10:36 am**

Ryne wrote:On a side note. Why doe's zac get -k so much? I haven't spent enough quality time with him to understand why, but hes the only person I've seen with -k.

He hasn't been so bad lately, but ever since he became active, he was intolerable (no offence, zac, I think you know this yourself as well). He complained about things he didn't like, was arrogant, verbally abused others for being glad with a vector tutorial, the list goes on and on.

Posted: **Sun Nov 14, 2010 4:03 pm**

Taehl wrote:The scale is 1 - each tile is 1 cubic meter. For sake of simplicity, let's assume the player is also 1 cubic meter.

So you're saying I'm going to have to go from 1 check per step to 8 checks per step? Can we reduce this? The player's collision shape could be a sphere or something if it would make calculations any simpler

We can easily turn the player into a cylinder. To check that, you have to have the 8 points of each cube, though. Lol. It also takes 8 points for the sphere....

Anyway, I have absolutely no idea how your code works... It looks like you're checking for the nearest cube in the path of the player. @_@
I don't want to write some function to get the nearest cubes, so I'll assume it's getNearestBlocks(), which returns a table of tables with 3 values labeled x,y, and z.

Code: Select all

local p = player
local mx, my, hit = 0, 0, false
local speed = kshift and 0.1 or 0.05   -- kw, ka, ks, kd, and kshift are keyboard buttons
if kw then mx = mx-speed my = my-speed end
if ks then mx = mx+speed my = my+speed end
if ka then my = my-speed mx = mx+speed end
if kd then my = my+speed mx = mx-speed end
if (kw or ks) and (ka or kd) then mx, my = mx/2, my/2 end   -- Diagonal movement isn't faster
-- You should probably be dividing by sqrt(2), unless the slow down is intentional.
local z,x,y=checkCollision(p.z,p.x+mx,p.y+my)
p.x=p.x+(x and 0 or mx)
p.y=p.y+(y and 0 or my)

function trace(z,x,y)
	local x1,y1,z1=x-.5,y-.5,z-.5
	local x2,y2,z2=x+.5,y-.5,z-.5
	local x3,y3,z3=x+.5,y-.5,z+.5
	local x4,y4,z4=x-.5,y-.5,z+.5
	local x5,y5,z5=x-.5,y+.5,z-.5
	local x6,y6,z6=x+.5,y+.5,z-.5
	local x7,y7,z7=x+.5,y+.5,z+.5
	local x8,y8,z8=x-.5,y+.5,z+.5
	local xc,yc,zc=false,false,false
	for _,v in pairs(getNearestBlocks()) do
		local v1x,v1y,v1z=v.x-.5,v.y-.5,v.z-.5
		local v2x,v2y,v2z=v.x+.5,v.y+.5,v.z+.5
		if x1>v1x and x1<v2x or
		   x2>v1x and x2<v2x or
		   x3>v1x and x3<v2x or
		   x4>v1x and x4<v2x or
		   x5>v1x and x5<v2x or
		   x6>v1x and x6<v2x or
		   x7>v1x and x7<v2x or
		   x8>v1x and x8<v2x then
			xc=true
		end
		if y1>v1y and y1<v2y or
		   y2>v1y and y2<v2y or
		   y3>v1y and y3<v2y or
		   y4>v1y and y4<v2y or
		   y5>v1y and y5<v2y or
		   y6>v1y and y6<v2y or
		   y7>v1y and y7<v2y or
		   y8>v1y and y8<v2y then
			yc=true
		end
		if z1>v1z and z1<v2z or
		   z2>v1z and z2<v2z or
		   z3>v1z and z3<v2z or
		   z4>v1z and z4<v2z or
		   z5>v1z and z5<v2z or
		   z6>v1z and z6<v2z or
		   z7>v1z and z7<v2z or
		   z8>v1z and z8<v2z then
			zc=true
		end
	end
	return xc,yc,zc
end

Posted: **Sun Nov 14, 2010 8:21 pm**

Thanks for the sqrt(2) thing - that makes sense. I'm not great with math, sadly.

Anyway, as for the code you posted. All that is for one step, I take it? Christ. Can that get trimmed down in any way? I don't need perfect accuracy; what I'm hoping for is something more like a tiny hack that will notice these diagonal mistakes and stop them.

Posted: **Sun Nov 14, 2010 8:35 pm**

Taehl wrote:Thanks for the sqrt(2) thing - that makes sense. I'm not great with math, sadly.

Anyway, as for the code you posted. All that is for one step, I take it? Christ. Can that get trimmed down in any way? I don't need perfect accuracy; what I'm hoping for is something more like a tiny hack that will notice these diagonal mistakes and stop them.

It checks two 3D boxes for an intersection.

LÖVE

Simple collision detection without Box2D

Re: Simple collision detection without Box2D

Re: Simple collision detection without Box2D

Re: Simple collision detection without Box2D

Re: Simple collision detection without Box2D

Re: Simple collision detection without Box2D

Re: Simple collision detection without Box2D

Re: Simple collision detection without Box2D

Re: Simple collision detection without Box2D

Re: Simple collision detection without Box2D

Re: Simple collision detection without Box2D