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

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

If you add a text object, in its properties you can turn it into a textarea, then you can use the append text, each time you want to track something.

It might be easier to just use a list object and use the additem functionality that comes with that. You can find description of both in the manual.

I assume the sprite is the player? if that's the case and you want it to remain in the centre, and only apply the movement to the tilemap.

If player

• press Right

Set position of Tilemap.X = Tilemap.X - 32

• press Left

Set position of Tilemap.X = Tilemap.X + 32

My game uses 16x16 size as well.

The one on the left Is the actual size and the one on the right is zoomed a little more than 300%, as you can see it also starts to blur, And it makes perfect sense.

Here is how it works very basic:

The top row of images I have made the image on the left which is 2x2, And the right one is the scaled up version. As an image consist of X*Y amount of pixels, which each hold some color information. The images on the left have 4 pixels to show the four colors. As you scale up the image you get more pixels. In this case the right one have 16*16 = 256 pixels. But since the original image only consist of 4 pixel, it suddenly have to fill in something for all the added pixels, and that why you get this blur or color bleeding. Simply because there are not enough information in the original image for it be scales that much.

In the lower example the original image is the one on the right. As it is scaled down you start to loose details, this is because the scaled down version simply doesn't have enough pixel to show all the details that are required.

In my experience it always better to scale down than up, because as the image gets smaller its also harder to see the details, so if some of them should disappear its not as bad as things starting to get blurred.

But in general its best to render in the exact size that you need, or only scale by a small factor where you think its acceptable. So working with 16x16 or 256 pixels, there are not really a lot of room for details.