While this isn't a specific solution to your issue, it's a pretty invaluable tool for doing advanced camera control:

This would be a perfect fit for this kind of behavior:

To choose whether to activate/deactivate, use line of sight on your player char, and look to see when player can see animals. Much cheaper than putting LOS on every single animal.

I too have noticed that 64bit builds use a hair more cpu, though I've never seen as much of a discrepancy as DrewMelton. I have noticed that 64bit builds use more memory than 32bit builds though, which seems kind of ironic.

That being said, I have tried newer NW's, but always end up rolling back to 10.5. It's is the smoothest and most stable for me, and everything works that I need...but 10.5 only exports 32 bit. So, that simplifies things.

The calculation of distance traveled is trivial, it would have no affect on real-world performance, even with tons of 'bullet' objects onscreen.

An analogy:

"I want to take the valve caps off my tires to decrease wind resistance and improve my mileage."

In what environment are you seeing lag? In a browser? In NW.JS? On your phone?

What is your cpu usage? What is your fps (search in forum how to add your own fps/cpu readout with a spritefont, as debug mode can cause a lot of slowdown).

The 'uni-sprite' method you mention is not one I'm particularly fond of, because all the frames and animations for the mega-sprite are loaded into memory, even those that aren't in use. So, probably not a good match for a platformer. That being said, there are situations where it's a good way to go (simpler games).

Here's how:

https://www.scirra.com/tutorials/723/us ... t-in-loops

Create a series of groups postfixed with numbers, like:

"Foobar_1"

"Foobar_2"

. . .

..."Foobar_10"

Then go:

Activate Group: "Foobar_" & str( int( random(1,10) ) )

Another trick is combining trigger once with "wait for signal" to create your own custom "once-off" conditional triggers. Simply add 'trigger once' with no other conditions, then make the first action "wait for signal". The event will only run once.

Use case: Explicit structuring of startup logic, irrespective of the order of events. So, if you are configuring objects in a way that is order dependent, structure into separate 'trigger once' events that signal thru each other. Then you could, say, locate 'startup' logic for different actors in their own groups which could be arranged as you please.

Can you explain what you are trying to do a little better?

IDK, I think the idea of a mega-polygon (Carmack, is that you? ) is kind of interesting, though, it seems like if you had a lot of onscreen shadowcasters the complexity of the polygon might become a problem.

However, the light/shadow system was quite a bit of work, and I'd be surprised if Ashley didn't try something like this along the way, as I've read about other implements before that did something similar to what you are suggesting.

I suspect this would gobble up a lot more fill rate as well, since rendering the 'inside' means overdrawing substantially more pixels. Which is a problem for perf on desktop, unless you want to ignore the massive number of people rocking iGPU's only (wish we could, but... ).

Anyway, I'm going to shut up now, because I'm starting to get way out of my depth...

Really useful plugin. Thanks!

—

That's a sweet effect, looks great.