nimos100's Forum Posts

  • Well it should work, so im guessing you might use the "scroll to X" wrong.

    Here is a very simple car moving to the right and the camera following it, is that what you are looking for, otherwise im not sure what you mean.

  • Just wondering why you posted this in bugs section, I think you could get better help in the "how to" section

  • [quote:3f0suz33]I`m using a textbox to display the score in my game. I`ve read that using textbox is more efficient than using the text-object, concerning the framerate.

    Where do you have this information from? I find it highly unlikely that you would experience any significant frame rate changes using one over the other. Unless you maybe use a serious amount of them, talking more than 500+ or something. I could imagine that the sprite font could cause some drop though.

    But personally I wouldn't concern my self about this if I were you, there are other areas that would be far more important to optimize if you are concerned about FPS.

    However you can change the alignment of the text in the properties. Cant remember what its called, but its somewhere in the bottom of the list, next to hotspot.

  • +1

  • [quote:3969sg9s]I think I have it, but it doesn't work because I'm pretty sure I need families to properly detect two of the same objects overlapping, hopefully I can get the full version in the next day or two.

    You can do it without, but as you said it would be easier to use families. But you can do it like this:

    Example;

    If Box is overlapping Dotted box

    DragDrop on released

    Sub event

    If Green Box is overlapping Another Red box (If it does you add Pick Red box)

    else

    If Green Box is overlapping Another Blue box (If it does you add Pick Blue box)

    else

    etc etc.

    But it will quickly get messy, so if you get the full version soon, I would probably wait as well

  • [quote:33eidwo3]Distance tests don't work with collision cells, do they? Like, if you have a few thousand enemies spread over a large layout, and you are testing collisions against them, col cells will eliminate a lot of the overhead, whereas distance will test against everything--unless that's changed recently.

    Not sure I understand exactly what you mean. But in my case, as it uses a simple distance check to determine whether a collision check should be made in the first place or not, the problem occur as the distance check doesn't take the shapes of the object into account, so if a distance check is used to limit the amount of collision tests needed but the shape of the object is not symmetrical there might actually be overlapping and a collision check should be made, but doesn't happen because of the distance not matching the conditions, so at least in my example you get performance at the cost of flexibility. And guess that will be the same problem that the OP will experience if using distance checks.

    But in my tests all uses the same setting in regards to collision cells etc, the only difference Is the amount of objects that might differ a bit. But you can easily see the difference in performance when using one method compared to the others. the only one is On collision as it doesn't allow you to change how it works, so it doesn't make much different how you try to optimize it as I see it.

    [quote:33eidwo3]Actually, I did an opt in one project where I was using pick nearest/distance for cols, then taking that distance and using it to determine how often to check cols. So...an object far away from anything it can collide with will check for cols much less often. Seemed to work pretty good even with boatloads of objects.

    Yeah agree, there are lots of ways to optimize performance when working with collisions. And if you need a lot of tests, its definitely worth trying to find a way to do it. It seems that C2 provide the functionality so it is solid and work in every setting, but doesn't do much to optimize how its done.

    Regarding "On collision" I suspect that the reason it give worse performance might be because it some how sub divide the amount of checks being done, as it needs to trigger on a very particular point, which is the moment that a collision between 2 objects are made, and therefore it need to be more precise.

    So if an object travel at 300 px per sec and hit another object, to avoid that the object overlap the other object or overshoot it, the amount of checks needed is sub divided to make sure that It doesn't happen. Also it might be more sensitive regarding the collision mesh of the objects than overlapping is. However its just a guess.

  • [quote:479cjqvv]Wait, what? I'm 99% sure 'on collision' and 'is overlapping' are exactly the same performance-wise.

    nimos100

    where did you get this info?

    I cant explain exactly how they work as I simply don't know. But its based on pure testing. You can actually check it with that program I linked earlier. If you just add that event, and disable the other.

    Here are some data from my tests:

    (The collision group is a functionality I added, trying to optimize collision checking, if you wonder what it is, its not an event or action you find in C2)

    Using overlapping (With the Collision group disabled)

    Number of objects: 2490

    FPS: 8-9

    Collision checks per sec: 18000-21000

    Using On collision event (With the Collision group disabled)

    Number of objects: 2512

    FPS: 2-3

    Collision checks per sec: 1013025+

    Using overlapping (With the Collision group Enabled)

    Number of objects: 2501

    FPS: 29-30

    Collision checks per sec: 12000-15000

    Using On collision event (With the Collision group enabled)

    Number of objects: 2464

    FPS: 3-4

    Collision checks per sec: 2048000-3100000

    These are my tests that I just did, as it removes overlapping objects before checking collisions, there is a slight difference in amount of objects. But nothing that will change the results in any significant way.

    But if you look at the collision per secs, which is from the debugger, it goes nuts on the On collision event, even when you remove the squares that are overlapping. So something is clearly not the same but there aint really a lot you can do with the "On collision" event as its part of C2 and cant be modified.

    [quote:479cjqvv]Obviously doing a simple distance check is less expensive than a collision check, but you lose polygon data.

    My program only uses small squares so whether the tests would differ if it was random shapes I don't know or whether it would have an impact on the polygon collision mesh accuracy when doing collision checking. However I do actually think that the result would be pretty much the same as them being simple squares, but I haven't tested it.

  • If im correct, which I think I am, but have to admit I haven't actually tested it. But then you need to take the other conditions into account as well.

    If Box is overlapping Dotted box

    (So its only the boxes that are overlapping the Dotted box, Which will only be the one currently there and the one you drag, and if there are one in the other dotted box. And since you move the one you are dragging to the top. It also means that the others ofc must be the lower.)

    If Box is overlapping Another box

    (This make sure that its the correct box that gets selected, so its not the box in the other dotted box should there be one there)

    DragDrop on released

    (Will just make sure that it doesn't trigger at the wrong time)

    Pick bottom box

    (This just pick the lowest box, so you can return it.)

  • I made this small Capx as a test of collisions. It let you spawn a lot of objects and then check performance.

    I have added a distance functionality in it, so collision checks are disabled and enabled based on distance, so if two objects are not with a certain range of each other then collision checking is turned off for those objects.

    You can see the difference if you disable the group called "Disable collisions" compared to when its used.

    However be aware that the program was only for testing, so you need to do things in the correct order, which is pretty much just to press the buttons in the correct order.

    1. So first you spawn the amount of objects you want to test with, you don't need to press it more than a couple of times.

    2. Press the second button to remove the current overlaps.

    3. Add some speed to the objects.

    After you started it don't press the create button, as you will have to force close it then.

    But maybe it can give you some ideas of how to do it.

    https://dl.dropboxusercontent.com/u/109921357/Performance%20test.capx

    [quote:16zj1skn]What about distance checks? I need to use them quite often. I didn't know if they were more resource intensive than collision checks since I'm not big on the programming side.

    It depends on how you use them, each time you make a distance check you the computer funny enough have to do a calculation to determine the distance, so it would seem logic that it would be worse than not doing it, but in my test for instance I use distance checks a lot as it will help reduce the amount of collision checks that needs to be done each tick, as not as many objects need to be checked all the time, it actually give a performance boost.

  • In system there is one called "Scroll to x" you can use that. You don't need the scroll to behaviour. You just add the scroll to X in an every tick.

  • You can just make a global variable it will stick throughout all layouts.

  • It wont make a huge different whether you add them to the layout where you need them and just destroy them on start of layout or put them on another layout and load them from there.

    I don't think you will get a lot from such approach besides maybe make things a bit more confusing and "annoying" for yourself since you would have to change layout or use the object list every time you would have to work with a relevant object for another layout.

    But don't think there are anything wrong by doing it in regards to making things work.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • [quote:hi77516l]I didn't state this properly in my original post (so my fault), but the blocks should be able to moved multiple times and reordered (so it could be green, red, purple, yellow, blue, etc). From what I presume you said, this would fix the objects to a container.

    Might be me that misunderstood your pictures, it looks like what you wanted was as the boxes are placed on the scale that the scale should be animated so the heavier boxes tip the scale.

    If that's the case, then the objects will only be temporarily fixed to the scale so they line up with the animation, and then unfixed as a new box is move to the dotted area to replace it. The pin behaviour allows you to do this.

    [quote:hi77516l]What I would love help to implement is how to make objects switch positions. When a box moves into a container that has a box in it, it needs to send the box that was there to the container the new box came from, so their places 'switch'. I put a note in the .capx.

    You can do that by changing and adding a few things to what I wrote.

    1. If you added the variable called "color" you can remove that.

    2. To the boxes that you move around you add a variable called "Container_UID" which will hold the UID of the container where the box is currently placed. (You just initialize these from the start in C2 design mode according to where they are placed and then as the boxes are moved around you overwrite them get overwritten)

    3. As you start moving a box you save this "Container_UID" in a global variable.

    4. By doing that you can then use this variable both when a box is dropped outside the scale and when you need to replace a box.

    Event: Start moving box

    On DragDrop of box

    Action:

    Set <Global variable> = Box.Container_UID

    Event: Replace and return box

    If Box is overlapping Dotted box

    If Box is overlapping Another box

    DragDrop on released

    Pick bottom box (This is why you move the one you are dragging to the top, so its always the one already in the dotted box that gets returned)

    Action:

    Box disable pin to object behaviour. (This will make sure that the box that are returned doesn't follow the scale as it moves.

    Sub event to "Replace and return box": Return the bottom box

    Pick Container where UID = <Global variable> (Will pick the container from where you took the box)

    Set Box position to Container

    Box.Container_UID = Container.UID (This will store the Container.UID with the box, so next time you move it, you again know where you took it from)

  • A simple collision check is best. However doing a overlap check is far less performance demanding for some reason.

    So "On collision" event you shouldn't use, if you need a lot of tests.

    "Is overlapping" you should use for lots of test and in general, if performance is important.

  • No the list or textarea will only keep track of the data for you during the game, as the game end you have to export that information, either to an XML file or some other method depending on what is possible.