Ashley

Thanks for the explanation; now it begins to make sense to me.

I've already decided against the duplication approach; too awkward, too prone to errors. However, to clarify, using instance variables to identify a set of objects does not work for collision testing...at least, not in my tests (and not according to what I've read on collision cells). That's why I was attempting the duplication approach, ugly as it appeared.

However, I still managed to gain an appreciable improvment in performance by implenting a scheduling system. So now I have a global var that cycles thru three steps, and I distribute my operations amongst them to balance things out. Like:

step 1. check bullet cols

step 2. spawn bullets

step 3. check for offscreen bullets, destroy them.

1...2...3...1...2...3...etc...

It's not a massive optimization, but it does seem to reduce jank when everything is running full tilt (intermittent demanding operations don't end up aligning on the same tick).

Cheers, T

Looks really neat, though it sounds like the documentation and stuff is not quite there yet. That being said, it be lovely to one day have a really good open source 2d/3d game engine. I guess there is the blender game engine, but, well...it is what it is...

Put your slideshow in as an animation for a sprite. Then

Global var foo = 0

Every X seconds (X being the interval between images):

1. Set SlideshowObject.AnimationFrame to foo

2. foo + 1

A little unclear. Do you want to spawn an object along a line at random points? At the edge of an object (ie, at a point)?

Image points are probably your solution. You can have a few and pick them randomly by putting random(FirstImagePoint, LastImagePoint) in the image point field for spawning an object on another object.

Mipey jayderyu

I gathered that it's not reusing the images, but I don't understand why that triples the draw call. The total number of objects is the same, there are just three object types versus one. Not trying to argue, just understand. See again what Ashley says (relevant parts bolded):

As far as C2 draw calls are concerned (when it asks a plugin to draw itself), it makes a single draw call for every single visible object on-screen, and that's it. Offscreen objects are not drawn, and objects set invisible are not drawn (although objects with opacity 0 are still drawn). It doesn't matter if objects use different or the same frames, are from different or the same object types, there is one draw call per visible instance.

The reason I'm doing this is to try and divide up collision testing loads across multiple ticks. And it works -- for the collision testing logic. The extra draw call overhead just about cancels it out though. Very frustrating. Basically, with col checks having to be top level now, I can't figure out any other way of pre-filtering objects to test.

Essentially, there little advantage anymore to testing collisions less often than every tick, unless you have many different object types...in which case your draw calls go way up...

Joannesalfa

I'm not dev'ing more mobiles right now, but I've been following the discussion on mobile export with interest. Anyway, how is WizCanvas working for you? Faster than gameclosure? Or have you got it working yet? An open source/free solution would be great...

Having a strange thing happen, and have tested it in both chrome and firefox.

If I spawn, say, 1000 moving objects of one type, I can see in the debugger that my draw calls are using about 4.5 percent of my cpu.

However, if I clone that object so I have three identical copies, place them in a family, and spawn a 1000 of them, my draw calls go up to 15-17 percent (almost 3 times more...suspicious number...)

I'll post a capx if no one can explain this, because everything I've read so far on the forum and in the manual suggests this shouldn't be happening. For example, this thread:

Salient extract from the man himself:

As far as C2 draw calls are concerned (when it asks a plugin to draw itself), it makes a single draw call for every single visible object on-screen, and that's it. Offscreen objects are not drawn, and objects set invisible are not drawn (although objects with opacity 0 are still drawn). It doesn't matter if objects use different or the same frames, are from different or the same object types, there is one draw call per visible instance.

???

See this:

https://www.scirra.com/tutorials/318/ho ... ng-screens

First you see the default scirra loading bar, but just briefly. Then you have a loader layout, providing you added one. After that, the only thing which is not loaded completely is audio...and you can even force that to load if you wish.

You want Set object time scale. See here:

https://www.scirra.com/tutorials/67/del ... dependence

No, there isn't. You could modify the effect manually though, I think, but you'd have to dig into the code.

Multiplayer is coming, not here yet. Check blog, also here's a test page:

http://www.scirra.com/labs/multiplayer/test1/

Sure, why not? Sound like a good idea. I'd take a look at some vertical scrolling space shooters, similar idea if you think about it.