Mort's Forum Posts

  • Really? That ran okay for me, and this PC scarcely has more processing power than a pizza box - it struggles with a lot of caps. Odd.

  • Interesting concept! I'm curious to see where you go with it.

    I put in the unit count total for you (two events, at the top of your main event sheet.) It includes both units in transit and units stored in the bases. The important thing is to remember that Construct processes the event sheet from top to bottom, so you can use stuff like 'add to variable', 'set text to variable', and 'set variable to 0' in the same tick. If you use a loop as well, then you can do something like 'add each private variable to global variable', 'set text to global variable', and 'set global variable to 0', resetting it so it'll add up again in the next tick.

    The best thing about Construct is that implementing that concept is almost as easy as explaining how it works. Have a look at the events, and let me know if you have any trouble.

  • Wow, that's really useful! Maybe we should make an 'Obscure tips' page on the wiki, for facts like this.

  • Fun game in 3 events! Impressive.

    Best: 34

  • It jerks around probably too much to play on my old PC (even without motion blur). PC is an AMD Athlon 3200+, NVIDIA GeForce FX 5200, 1 gig RAM.

    Maybe you should make a fullscreen demo, though - that often makes a lot of difference. Windows treats fullscreen apps so much better.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • 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.

  • 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.

  • 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.

  • 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.

  • 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!)

  • It really puzzled me that, even though the mask had no semitransparent areas, the edge of the masking was kind of fuzzy (3 pixels of progressively stronger alpha before it becomes fully opaque).

    Finally worked it out: the mask image is smaller than the mask sprite, and Construct blurs the edges when it resizes. Which is perfect, for a scrolling text mask.

  • Looking good! Containers and functions make that really easy to use.

    I'll definitely be switching to your distort map method - with 5 circles, the box ring method drops to ~45 FPS, while yours is running 260.

    I wonder if this is how Ashley implemented the shadowcaster behaviour, using something similar to distort maps? I have a rough idea of how we could make box shadows (like in the behaviour) this way. Not that that there would be much point, as behaviours are inherently more efficient, but it's an interesting thought.

  • A shadow without the shadowcaster behaviour? Ingenious.

    I don't understand your maths yet, but I'm reading up on it!

  • Thanks, I had been wondering!

  • Broo: This creates 36 square objects, sizes them proportional to the parent object, and puts them in a ring right next to the edge, on the inside of the object. Like... making a crude circle out of boxes, and using that to cast the shadow. (Sorry, I made them invisible - change the attribute 'invisible on start' and you should get an idea.)

    Making a crude ellipse out of boxes is possible, I'm sure of it. I suppose you'd just need more, smaller box objects to prevent them from being seen, proportional to how elongated the ellipse is. But you'd also need different maths to actually get the boxes in the right elliptical shape. At the moment I'm just moving the boxes towards angles in every direction, proportional to the size of the circle. For an ellipse, I think trigonometry might be involved. I guess they were right and I should've paid attention in maths class.

    (I hear the shadowcaster object is planned to support non-rectangular shapes eventually, like Mipey says. But I'm not sure what the priority is; probably after 1.0.)