Particles don't support collision ?

I want to make particles like bullets, for a shoot'em up.

It would be interesting because you can set some random, so it would be harder to dodge the bullets.

Can I do that ?

I tried to do an Event :

[Particle => Collision with Sprite]

But it doesn't work.

It's infeasible for individual particles to test for collisions; in most cases it'd be very very slow. You can always create a custom particle solution if it's necessary.

[quote:15l6rvxr]You can always create a custom particle solution if it's necessary.

If I can do it, why the particles system included in Construct can't do it ?

The particles object should include a sprite spawning system.

The particle system's an optimised system of particle display which by optimisation precludes certain functions, which very few people need. Collisions for 1000s of particles would slow a game to a crawl, for example. (In any case, the particles are custom drawn, and are not sprites.)

Asking for certain things to be wangled into plugins or behaviors is like asking for a 'make my game for me button' .

Creating sprites really shouldn't be that much trouble to be honest.

this question has been asked b4 and will be asked again.... someone make a generic example of how to do that to point them to

Custom particle systems are actually surprisingly simple - it's effectively a bunch of sprites with bullet behaviors that have random adjustments to any aspect of the object such as speed, acceleration, angle, opacity, colour, etc.

sprite particles example (98.9)

If you're dead set on using the particle object, you could also paste the particles into a canvas each frame, update the collision mask, then test for collisions with the canvas.

Hey Ash, Optimization question......

You think the overhead of a full screen canvas with a particle object (along with the pasting of particles, and mask updating) be more efficient than collision checks, movement, and general runtime clogging of say, 5000 sprites? I'm thinking micro shump with thousands of bullets, where the sheer number of sprites would clog the runtime.

Will particle pasting Defeat massive sprite spawning in terms of performance? See who uses less Cpu cycles in the next episode of davioptimization. Cap coming shortly !

It would depend on the order of complexity of pixel collision on Canvas, which I ignore.

It could be orders of magnitude slower.

If you're dead set on using the particle object, you could also paste the particles into a canvas each frame, update the collision mask, then test for collisions with the canvas.

You think the overhead of a full screen canvas with a particle object (along with the pasting of particles, and mask updating) be more efficient than collision checks, movement, and general runtime clogging of say, 5000 sprites? I'm thinking micro shump with thousands of bullets, where the sheer number of sprites would clog the runtime.

Will particle pasting Defeat massive sprite spawning in terms of performance?

it would take up more vram and you would only gain one collision mask for all particles with no ability to have a particle be able to be picked or react, so you could tell a particle hit a wall

but not where, or which particle, and could do nothing with that particle afterward

my rig is faster than slow, but I'm able to put 50 times as much particles as I have there without it slowing down, so I could have 50 of those particle generators with no fps drop. I'm not sure how many full screen canvases I can have, but it's probably not 50

know what I mean?

anyway, if anyone missed it:

sprite particles example (98.9)

Two questions.

Is it even possible for vertices to have collision detection?

If so why not make a vertex object? I can think of a lot of uses for it.