[SOLVED] Collision Line (or something similar)

[veethree]

EDIT:to veetree, how did you use bresenham for that lighting? I'm curious about that...

I'm too tired to explain it at the moment, And it's probably not the best implementation. But here's a .love.

Keep in mind all the code is pretty dirty, But the lighting is handled in map.lua inside map.draw. Also it runs in full screen mode by default.

[CRxTRDude]

I'm using .8, since this is the only one compatible here in my comp, but i'll try to modify your example

[veethree]

I'm using .8, since this is the only one compatible here in my comp, but i'll try to modify your example

That may turn out to be a problem, I'm using love.math.noise to generate the map. But if you look through the code you can still see the logic of the lighting and apply that to something.

[CRxTRDude]

I saw the code right, neat trick there you used the LOC as a test to see if there's collision with the walls... I think it'll be useful for a detection UI for the player (a sort of alarm for the player) i'll see kikito's suggestion too, here i go on the code again ...

[Roland_Yonaba]

EDIT:to veetree, how did you use bresenham for that lighting? I'm curious about that...

This is pretty much covered in the article I mentionned in my previous post. Here it is again, there is a section about lighting.
And on the same topic, Amit Patel provided a tremendous write up (with demos and various implementations) about 2d visibility.

Bresenham is good when you have a grid to "parse cells". I guess you could use bresenham to go pixel-by-pixel, but that would not be very fast.
It is also a "beautiful line drawer". It draws only one-cell lines, even when the line touches several cells. This means that not all the cells touched by the line are actually activated by it (this makes it not ideal for things like line-of-sight or shooting. They appear to "miss cells"). If you want to use it for that, you would have to use a "supercover" version of bresenham (unfortunately bresenham.lua does not have that)

Actually, you are definitely right. I was not aware of this until I tried to get it to work. I wanted to implemented ThetAstar algorithm, which is based on a clever combination of Astar and LOS, and is supposed to return smooth and better looking paths. Unfortunately, it ran into the issue you mentionned (that is, some unwalkable tiles were also traversed by the cast line). I kind of solved the issue by running the algorithm twice (from the starting point to the endpoint and from the endpoint to the startint point), but I was not pretty much satisfied with that hack, so I ended up ditching it until I find something better.

[CRxTRDude]

This function, given a list (array-like table) of objects and a segment, returns the list (array-like) objects that collide with that segment, in order (the ones near to the beginning of the line come first).

What you're saying is that when the line hits a - shall we say - 'solid' tile, it would be the very first in the list, correct?

If that's the case: if the result's very first hit is a 'solid' tile then the player is still not seen, else the player's spotted and an update function (whether shoot a bullet or cast a line for a improvised whip) that will hit player ...

Or is my logic don't make sense?

Oh yeah, thanks for that! Appreciated it

[kikito]

If that's the case: if the result's very first hit is a 'solid' tile then the player is still not seen, else the player's spotted and an update function (whether shoot a bullet or cast a line for a improvised whip) that will hit player ...

You got it right.

If you only have "blocks" and the player, then I think I think it's easier to do the opposite: If the first item on the list is the player, then he is seen. Otherwise, he isn't.

In the future, if you start having more types of blocks, and some of them are transparent, for example, you can use this:

Code: Select all

local function isPlayerSeen(x1,y1,x2,y2)
  local seenObjects = getCollisionLine(getObjectsInRoom(), x1,y1,x2,y2)
  for obj in ipairs(seenObjects) do
    if obj == player then return true end
    if obj.isOpaque then return false end
    -- else continue evaluating seenObjects
  end
  return false -- the player was not even on seenObjects
end

[CRxTRDude]

Thanks, i'm shocked that i got the logic right! I'll give a try on this with an enemy object (chasing enemy that is - no bullets yet). I'll post onto the progress.

Sorry if i'm asking too much though, i used your modules and it's been really helpful, they work fine on the platformer framework i'm chiseling bit by bit. Again, thanks.

[kikito]

Thanks, i'm shocked that i got the logic right! I'll give a try on this with an enemy object (chasing enemy that is - no bullets yet). I'll post onto the progress.

Sorry if i'm asking too much though, i used your modules and it's been really helpful, they work fine on the platformer framework i'm chiseling bit by bit. Again, thanks.

Good luck with it! Platformers are trickier than they seem.

[CRxTRDude]

@kikito Hello again, i saw the code, it's looking fine, but i saw getObjectsInRoom and i don't know what function it is ... Is that a set of tables or something else?

EDIT: for all
So that we all won't get astray, here's the framework as of now (i commented off kikito's implementation of collision):

queue.love

Queue 0.4 for Love 0.8 ~ Comment: Enemy test

(272.16 KiB) Downloaded 91 times

left & right arrow keys = move
space = jump