Saving/loading selected object lists, deactivating objects

Something that I want to do is have a lot of sprites on screen, yet work only with a small amount of them for a while. All the checking required for the unused objects wastes a lot of cpu time. It would be handy then if a selected object list could be saved and reloaded at a later time, skipping the need to recheck all the sprites each event each tick.

I suppose a 'deactivate object' feature might be nice as well and serve a similar purpose. It would be similar to setting an object's collisions to none, except it would exclude it from picking (and therefore, as well as collisions in one action). After being deactivated, the instance would not be checked for anything unless preceded by a "object is deactivated" condition, which would temporarily reactivate checking all instances of that object type.

Theoretically there could even be a second level of deactivation that would exclude the object from drawing, so construct wouldn't even need to update its position, making it require (almost?) no cpu cycles at all unless preceded by a "object is entirely deactivated" condition.

Thoughts?

Have you measured framerates that prove this optimisation is necessary? Without the numbers it's just shooting in the dark and it's hard to tell if the speedup would be at all useful.

How many objects are you talking? If it's less than, I don't know, a few hundred, then a simple 'is boolean instance variable set' condition will filter out all the ones you don't want every tick relatively efficiently. A single condition operating on a few hundred instances doesn't actually have very much overhead - it should optimise quite well, even in javascript.

...

Uhh...

With 500 objects, before turning off all other code, each pv check causes about a 10fps hit (1: 355 fps, 2: 345 fps, 3: 335 fps).

After turning off all other code, all 3 pv checks take 10fps total. (None: 207 fps, 3: 197 fps).

The fps went UP and the pv check efficiency went down when I have more code running. I am confused. I should try this with C2 instead.

FPS isn't a linear measure of performance - it's 1 divided by the average delta time, and that's a curve. (A 10fps hit at 20fps is a 50% decrease in FPS, and a 10fps hit at 1000fps is a 1% decrease in FPS.) It might be better to compare performance in terms of delta-times.

I wouldn't bother testing 0.x - the C2 runtime has been designed differently to take in to account shortcomings in the 0.x runtime, and it's dynamically optimised javascript rather than statically optimised C++, so the performance characteristic is likely to be very different. That also means you should check several browsers to be sure!

But doesn't C2 not have dt implemented yet? I guess I'll have to wait to test it until later.

Either way, it's more efficient than I thought, so maybe the features I suggested aren't needed.

C2 has a dt expression, but it always returns 1/60 (as if it were running at 60fps). There's an fps expression though, that gives you the real framerate, so 1 / fps gives you the "real" dt, but that only updates once a second.

I was considering adding an "adaptive dt" mode where dt is given the value of 1 / fps, but it might be weird given that it only updates once a second... could get really weird if the framerate changes regularly, as if the timescale was randomly changing...