I'm too tired to explain it at the moment, And it's probably not the best implementation. But here's a .love.CRxTRDude wrote:EDIT:to veetree, how did you use bresenham for that lighting? I'm curious about that...
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 wrote:I'm using .8, since this is the only one compatible here in my comp, but i'll try to modify your example
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 ...This is pretty much covered in the article I mentionned in my previous post. Here it is again, there is a section about lighting.CRxTRDude wrote:EDIT:to veetree, how did you use bresenham for that lighting? I'm curious about 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.kikito wrote: 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)
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?kikito wrote: 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).
You got it right.CRxTRDude wrote: 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 ...
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
endGood luck with it! Platformers are trickier than they seem.CRxTRDude wrote: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.
queue.love