GideonG Sprites would work I suppose, but this is supposed to be for a background doodad that just looks pretty so I'm hesitant to make it any more CPU intensive than it needs to be.'

Kyatric Thanks for the tip, I think this will work for the effect I'm trying to make!

By the angle thing I mean the angle of travel of the particle in relation to the origin point rather than the angle of the entire particle object. Basically I wanted the particles to always travel away from the origin when spawned with an offset. E.g. let's say there's a 180 degree spray cone pointed upwards. A particle spawns with a random offset of -10 on the X axis, so it's directly to the left of the origin. However, it's angle of motion takes it due right, so it travels back over the origin point. What I ideally wanted was for it to move away from the origin in the same direction as its offset, due left. This would basically form a circle around the origin where particles spawn along its circumference and travel directly away from the origin.

Anyway, thanks for the help guys.

So as far as I can tell there are actually no features like this, but figured I'd ask anyway. Is there a way to:

a) Make particles fade in from start? Normally particles fade out of existence, but I'm trying to achieve a reverse effect where individual particles fade in from invisible when they're spawned. Particles have an option to set initial opacity and an opacity randomizer, but no gradual opacity change (other than fading out as part of their destroy conditions).

b) Offset particles from origin relative to their angle of travel? Particles have an offset option, but this is determined separately from their angle. I was looking to create an effect where particles will fan out in a cone, but instead of all originating at one spot, have a slight offset to their spawn point. Unfortunately, with the current setup particles that are offset are also given a random angle after they spawn, meaning that a particle can travel in a different direction than its angle relative to the origin of the object. In a way, this effect could actually be faked by the feature described in point (a).

Thus far I've faked both of these effects by placing a gradient (basically a sprite of a brush stroke with hardness set to 0) on top of the particle object, so particles look like they fade in as they move out from behind the object. However, this only works because the gradient blends in with the background, but the background is likely to be dynamic and change, thus revealing the object. I've attempted to play around with blend modes, but so far no luck as these tend to conflict with the blend modes of the particles.

Oh good, I felt kinda bad because I didn't actually help solve the problem and instead peddled an alternative, lol

Perhaps it would simply be easier to have the player's car have a hitbox in front of it, so that it could detect cars ahead instead of the other way around?

I was wondering if that's something I'd have to resort to. Guess I can always try sprites with different colors slowly fading in to make the transition smooth. Either way, thanks for the help!

Hi all, I've got what seems to be a simple question that's giving me trouble. Is there a way to change the color balance of sprites/layers without resorting to effects?

Perhaps I'm overlooking something. I'm trying to make a mobile game which features color transitions for sprites. Unfortunately WebGL effects don't work on a lot of mobile devices, so the closest I've come to is having a semi-transparent layer that changes color, thus tinting everything below it. This isn't the best solution because the colors aren't very saturated and look dull, and making the layer more opaque (thus more saturated) will obviously begin to obscure things below the layer. So, I was wondering if there's another way to change the color channels of an object, to change the hue but still keep it saturated?

Hi all. Maybe I'm not seeing something that's in plain sight, but, is there a way to change the icons of objects and especially families as they show up in event sheets? Families of similar object types all start out with the same icon and it can get a little confusing when picking them out, so I was hoping there's a way to streamline things.

I made a simple game for tablets that seems to run fairly smooth on the iPad 1. Haven't had an opportunity to test it on a newer device, but hoping that it runs at least as smoothly or even better considering the newer versions are more powerful. Ran slow as molasses on phones, though, so I only ever released it for tablets. Unfortunately it involves a physics-based ragdoll, and physics seem to wreak havoc on the FPS when it comes to mobile.

It's a basic For loop, as in "For "xyz" from 1 to 100". There are no other conditions together with it and no other events which call for this loop or anything as it was meant to run at the beginning and never again. IIRC it used to do just that, but after running it a few times it turns out the loop begins running again after it finishes, so I've had to add a basic flag that gets set off and prevents it from running again. It's not a big deal, I was just wondering if I've inadvertently messed with some setting or something because I could've sworn it didn't used to do that. Perhaps I'm confusing C2 with CC.

Anyway, thanks for the replies.

Hi all. I'm not sure if it's some setting I've tripped or something (seems unlikely) but it seems my loops now repeat forever. Perhaps I'm misremembering, but when I had a "For X to Y" loop as the sole condition of an event, it would simply run one loop spanning X to Y. Now it seems like the loop repeats itself infinitely unless I add another condition which explicitly prevents it from running. Was this always the case?

Alrighty, I guess we're all on the same page here. Thanks for the help.

Hi all. I've got a crude "cave generator" going and I'm exploring ways to generate the terrain graphics, so I was wondering what'd work better performance-wise: having a lot of sprite objects + using render cells, or having one humongous object that covers the entire layout?

Back in CC while working on a similar project I experimented with using the Canvas object to effectively turn all of the scenery into one big object, but this sounds like it'd put more strain on rendering since it's both huge and always on screen, so presumably the entire thing needs to be rendered all the time. I'm not sure a tilemap would work for what I have in mind, so for this scenario I'm only comparing these two. Thanks for any help.