Hmm, ok, I'll try something like that, thanks.

I still find it strange that an object can be clicked when it isn't visible.

I've implemented a custom check-button in my game. The check-button consists of a sprite and a text object.

If the mouse clicks on either the sprite or the text, the button's state is toggled.

Sometimes a check-button is set to invisible. And while invisible, I disable the sprite's collision, so that clicking on it will have no effect. But for some reason, I can't disable collisions on the text object from what I can tell.

That really seems like it should work. I've tried it out and I'm still having the trouble getting the mechanism that uses this to work. But I'll have to assume that the problem is somewhere else then.

Thanks for the help.

Edit: I got things working finally. I'm actually not sure now if the problem was ever with the inverted pick by UID condition. But your suggestion is working fine now anyway. As is often the case, my problem was just a couple stupid mistakes that I overlooked.

I tried an inverted "Pick by UID" but as far as I can tell it's not working. And reading past threads about this issue suggests that it's not supposed to.

I have the UIDs of the instances I want to exclude from the SOL, I'm just not quite sure how to do this with conditions.

I'm looking for something that is like an inverted "pick by UID" but something that actually works.

After doing some more testing of my own. I'm fairly sure that the condition "Mouse is over object" does not work with the collision cells optimization.

I took a small 1px object and set it to follow the mouse at all times. Then I replaced the "Mouse is over object" condition with a condition that tests using my mouse_dummy object instead. This halved the collision checks per second. Which is actually not as good as I was hoping but it's better at least.

Also I should add that the system condition "Pick overlapping point" didn't seem to have any effect on the collision checks per second compared to the "Mouse is over object" condition. So I think that also doesn't work with collision cells.

I think I've come across something of a fix, though sadly I think this will probably only help me and not others with similar problems relating to the fixed parallax origin issue.

What I've been trying to do is generate an asteroid field in the background of my game.

So what I do is basically create a few thousand objects at random(layoutsize). Then I scaled each object based on the parallax value of the layer it was on. This caused more "distant" asteroids to scale down and look appropriate far away.

After searching through other older threads about similar issues I came across https://www.scirra.com/forum/top-down-fake-depth-3d-effect_t81087.

By using buddy40's method of setting the background layers to a different scale, I've achieved the parallax effect that I wanted, while mostly maintaining the correct visual positions of asteroids.

This does mean that I might need to use a wider range of coordinates for my background layers to compensate, but otherwise the problem (for me) is largely solved.

eli0s Normally I would do that, the problem is that I'm generating my background objects randomly at the start of the layout.

GenkiGenga Yeah, the "fancy equation" idea was what I originally thought of.

My camera starts out in the middle of my layout, but my layout is somewhat large 10k and if the camera is scrolled to 5000, 5000 many of the background layers are totally missing.

This is just a visual effect I'm going for. I won't need these background objects to do anything except look correct when my camera starts out in the center of the layout.

I'll keep working on it. I have a strong feeling that I'm just being stupid about this and missing something simple.

I thought I'd done this once and knew how to make it work. Unfortunately I think I'm missing something about this problem.

In the example, I have 2 layers.

Layer 1 has a parallax of 100

Layer 0 has a parallax of 50

Each layer has a simple sprite placed at x:500 and y:500.

What I'm trying to do is (on layout start) offset the position of sprite_50 so that it appears to line up visually with sprite_100 at the start of the layout.

Ultimately, I intend to offset numerous objects on various background layers each with different parallax values. I'm not sure, but I think what I'm trying to do involves parallax origin. I've done some searching but wasn't able to find anything that helped.

I'm hoping someone can confirm this for me.

My suspicion is that the very nice collision cells optimization might not work when using the "Mouse is over object" condition. Provided that this is the first condition that picks an instance of the object of course.

If this is the case, I can work around it by using a dummy object on the mouse I'm sure, and I'll start work on testing that out right now, but this would save me some time if anyone knew off-hand.

Also, if anyone knows if the system condition "Pick overlapping point" works with collision cells, that would be excellent.

These look like some good suggestions that I will try to consider.

Turning off collisions doesn't seem to affect anything. These background asteroids aren't going to be expected to interact with much in the game at all though.

I'm still hesitant to resort to multiple background layers though. With the way parallax layers work, I have to offset the asteroids in each layer in order to compensate visually. If I don't do this, layers with lower parallax values will appear in the wrong position.

Though one fix for this would be to have my camera start at 0,0, and use unbounded scrolling, instead of starting the camera in the center of the layout. Using this method, I would make my layout centered on 0,0. But this brings its own complications too.

Hmm, you might be right. To be honest I wasn't totally satisfied with how even as many as 15 layers looked though. Unsurprisingly, the asteroids felt like they were in well... layers, hehe.

Does anyone know how other engines handle this kind of thing, even 3D engines? I know I've seen this kind of thing done before in other engines. I'll admit that it may have been optimized in ways I don't necessarily have access too.

I remember in CC objects had a neat "depth" value I think. I did something similar to what I'm trying now in C2 a few years ago using randomly generated "depth" for each asteroid object and it produced a nice effect. I'm trying to replicate what I did in CC now to some extent.

I should add that the asteroids that I'm placing in the background won't be interacting with the rest of the game objects much at all. Largely they are there for scenic effect.

So I'm making a little test project, in the hopes that it might be a small game some day. In this game, I want to have an asteroid field in the background, stretching off into the distance.

These objects will need varying parallax values of course, and will need to be layered appropriately.

So my first idea was to use multiple layers each with successively lower parallax values. My problem with this approach, is that spawning a few thousand asteroids randomly among all the right background layers is awkward. I need at least 15 layers to make things look right too and would prefer much more really.

Obviously, I needed more control over the parallax values. So I thought, I will just make my own parallax system.

So (roughly speaking) I take the motion of the camera, and multiply it by an object's parallax value, and then move the object in the opposite direction of the camera motion.

Once I got it working, this looked great. But... this means that very often, I'm moving potentially thousands of objects around. In my tests already, this seems to use an uncomfortable amount of resources for such an early stage in the game.

Does anyone have any ideas for how I can get more granular control over object parallax values without resorting to many layers each with separate parallax values.