WarpedOldMan's Forum Posts

  • 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.

  • Yeah, it looks like I'll have to do something like that. It's not quite what I was hoping for but it will work. Thanks!

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • I'm trying to loop through all instances of a family, and check each instance to see if it exists within another family.

    I'm hoping there's a non-awkward way of doing this, but at the moment I'm not seeing any.

  • Does it still jitter if you set the Sampling to Linear? I know this isn't a real solution to your problem but I'm curious if that's the right area to even be looking for the problem in.

  • Families are restricted to objects from the same plugin. Is there any other object type other than tilemaps in the family?

  • This is just a wild guess, but you could try making the "on object clicked" event block an "Or" block and add an "on object double clicked" to it.

  • So I have a layer, with the parallax set to 0,0.

    This is my UI layer, so I have a mini-map object placed in the top left of this layer.

    The mini-map is 200x200px and is positioned at x:100 y:100. It is also anchored to the top left of the window.

    When looking at the debug panel, it seems that layers set at a parallax of 0,0 have their own internal coordinates. So the top left of the layer always starts out at 0,0.

    This is good, and reasonably expected behavior. However, I run into a problem when I try to re-size the window.

    I should add that I'm using the NW.js preview option.

    By default, my window starts out at an arbitrary 1280x720 if I re-size the window, while watching the debug panel, I can see that my mini-map object moves into the negative range.

    So what this tells me is that when re-sized, the top left of my UI layer's origin is no longer internally 0x0.

    I'm hoping this is clear enough for people to understand, and if possible maybe someone could confirm this behavior?

    Also, if anyone knows how to compensate for this, I'm eager to hear your ideas and techniques.

    Update:

    After some more searching on this issue, I think I've found a previous example of the problem.

    https://www.scirra.com/forum/crop-fullscreen-breaks-0-0-parallax-layers_t120338

    Unfortunately this seems to be by design so I'll have to look into solving the problem with more awkward methods.

    Also I will add that... I'm not sure I see why Ashley considers the "crop" fullscreen mode to be a mistake. For some games, actually scaling graphics can cause them to look quite fuzzy and lose the "crisp" look that I normally try for in my games.

    Unless I am missing something, it makes more sense for me to use the "crop" fullscreen method.