Circular shadowcaster

[quote:262t7gxu]At this rate, you're going to be one of the forum math people!

hahah I hope not. I suck badly at maths. I was just lucky I figured this out!

[quote:262t7gxu](I'm still working out how you did this - haven't had much time lately, but I think I'm getting the idea.)

I'll try and comment how I did it for the next version. I rarely comment my stuff when I'm hacking away at it but I really need to with this so I can remember in a years time what the hell those formulas were

[quote:262t7gxu]By the way, I'm trying to work out if objects are shadowed in the game I'm making (for a situation where a swarm of small objects have to hide from light). I was using instant-hit bullets or LOS objects to detect whether they're shadowed, but there should be a way to adapt this method to work it out, right? I might try it sometime this week.

(Unfortunately, 'Object is overlapping shadow' doesn't work - I guess distorted objects don't count for collision purposes!)

At this rate, you're going to be one of the forum math people!

(I'm still working out how you did this - haven't had much time lately, but I think I'm getting the idea.)

By the way, I'm trying to work out if objects are shadowed in the game I'm making (for a situation where a swarm of small objects have to hide from light). I was using instant-hit bullets or LOS objects to detect whether they're shadowed, but there should be a way to adapt this method to work it out, right? I might try it sometime this week.

(Unfortunately, 'Object is overlapping shadow' doesn't work - I guess distorted objects don't count for collision purposes!)

As I was reading that I was immediately thinking "try collision detection with the shadows" but you say they don't work eh... damn. Right... just tried LOS... here you go. Although it depends what you class as "being in shadow"...

http://willhostforfood.com/users/P/procrastinator/circleshadowcaster_v0.41-LOS.cap

Yeah, it makes sense... "If I can't see the Sun, then I am in a shadow."

Here we go!

http://www.mediafire.com/?mj1zuunyx1d

I had in mind something where if the object isn't completely shadowed, it's considered to be in sun. And after two clever-seeming ideas that turned out to be completely unworkable, I swallowed my pride and just used instant-hit bullets. It turned out to be pretty efficient, since I only fire them along the shadow's edge.

Still not totally accurate (doesn't notice if there's only a few pixels of object showing), but I'll straighten that out - I just need to event the bullets not to notice the circle they originate from, and then I can cut much closer without unwanted collisions.

That's a nice method but it's flawed unfortunately. It's too slow (halves the framerate here) and if you move the lightsource to behind the very bottom left circle the object isn't hidden anymore. Almost there... probably needs a little tweaking to get it right.

I'll get this damn clipping done today and then I'll put a bit more time into this problem.. hmm..

It's obviously not too slow.. I meant it's slower. Anyway, a few further tests of my own and I couldn't get it much faster than yours with that accuracy. I've just tried a "point in poly" routine but it didn't work. Too tired.... but I think that'll be the fastest method if I can get it working...

This shadowcaster will be very handy for many things when it's fully working. I have a few plans for it but those are a long way off

What's the game you're working on btw? Sounds like a 2D Thief game or something.

I stayed up last night and made something with instant-hit bullets that was ~260 FPS, pixel-perfect, and couldn't properly calculate the blocking effect of multiple circles! Oops. I'll figure out what the problem is on the weekend - the events look like they should work, but the collisions are acting strangely.

Before this, I had a method that attached 1px wide, 500px long sprites to the circle and checked collisions, but it wasn't accurate enough. And before THAT, a similar method with thin sprites attached to shadows, but collisions with other circles didn't work well.

There's probably a really elegant solution that I'm missing, but it's good experience to be messing around with different areas of Construct this way. I learned a bit of circle-related maths, too.

The game I'm working on is the one from this thread:

I'm planning one section of the game set in a sequence of spinning reactors - the light from the reactor will quickly burn the cells of your swarm, and you need to make your way through without leaving the shadows. The levels should vary - in some chambers, I'll set up spinning, orbiting spheres; some blocks travelling around a central star; some with the light source moving around other objects. Nothing too complex, hopefully the kind of puzzles that make you stop and think a moment, then quickly move on.

I'm setting up an abilities system for the rest of the game, but not sure if it should apply to this area. It would be interesting have some puzzles where you need to slow down or stop time while still being able to move.

Okay, here's a line-of-light system that works. Good speed, good accuracy, both large and small objects work okay, narrow rays work okay, scales well. Uses instant-hit bullets for the shadow edges and LOS behaviour for elsewhere.

http://www.mediafire.com/?z8oyzymjrzj

Hopefully, case closed.

Ahhh THAT game. I remember checking that out when I was getting back into Construct after months of not touching it. Nice game! It'll be sweet seeing this actually applied in your game.

Just checked out the new LOS version. Very nice and accurate.. even at the slightest gap but it's around half the speed of your previous version. So it's gone from 1200fps from the previous version to 600-800fps for this version here. That probably doesn't make any difference, as long as it runs smoothly on a lower end machine. If it's accuracy you want, then sometimes you have to sacrifice a little speed I'm curious how it'll perform on so many swarm cells though.

I wasn't around yesterday (well only in the morning and that was brief) so didn't get anything done at all... but had a few thoughts. Based on your intitial LOS system, I thought of a way to optimise a bit.. I think by checking the angle from the lightsource to the obstructions (circles) and the angle of the player object, we can check if the player's angle is within a certain range close to the obstruction's so we only need to cast rays from that obstruction's edges. Don't know if that makes sense, as it's just in my head atm so hard to explain. I'll see if that works...

For optimisation... I suppose you could check whether the target is anywhere near the shadow area, and thus avoid firing instant-hit bullets unnecessarily. I'm not sure of the maths for that, though; you'd have to check if they're in an arc, perhaps? (I wouldn't go to too much effort in optimising - on this old computer, even disabling *all* the LOS code doesn't change the framerate; I think the graphics will remain the bottleneck.)

I'm going to need similar LOS finding for the other obstacles - boxes and more irregularly shaped objects. I suppose it'll adapt pretty well, though, I can just fire detectors past the corners instead of the circle's shadow-edges.

This is all going well. I might have a working level done by the end of the weekend, at this rate.

I barely coped with the maths to draw the shadows.. Optimisation is always a good thing though. It frees the cpu for other things like the physics. It's taking some extra cpu firing from every circle's edge (x2) and for your more accurate version it's halved the framerate for me. If it was only firing from 1 obstacle it would probably only have dropped by 10-20%.. theoretically. That's why I'm seeing it as worthwhile effort to optimise.

Thinking about it though, I can imagine spending a crapload of time optimising it to only fire from the 1 obstacle and the next build of Construct includes "point in polygon" checking! I think I'll wait then...

Can't wait to see the results though! Keep me posted!