I don't know the Physics behaviour that well, so if there is another way to do it, I really don't know. But if your works I guess its fine. But what if two tiles are equal range, won't it bug? for instant if you shoot in the corner below where your shot is on the pictures, then the bottom tile and the right tile will be of equal range, or don't you calculate it that precise, so its not likely to happen?

What you see is the whole Capx

Do you think it works with phycics behavior where, I think, the bullet wouldn't overlap the tiles but just collides with it ?

Cant see why it shouldn't, it just uses the position of the bullet. So if its the same with the physics behaviour it should work I think. But I haven't worked that much with that behaviour so you would have to test it to be sure.

Haven't read all the replies. So this might not be what you mean, but how I understood the original question. But in that case you can just ignore it

Here is a simple example of how to get the tile.

(Be advise that the tilemap at row 0 for both X and Y is empty so its not an error that it seems like it should be tile 3,7, its just me that didn't put any tiles in that row, so the white area around the tiles are actually row 0)

If you want the coordinate in X,Y you can just convert the TileX and TileY to that.

[quote:2q8zl984]Thanks for the responses everyone. I had never run into this before now.

Think its a problem everyone runs into at one point or another

However I would suggest that you design your game to not use wait 0. It can cause problems.

In your case you could just move the actions from the second "every tick" to the first one and it would work without wait 0.

A rule of thumb is as Rojo pointed out as well. When you create an object, you have to initialize it in the same event, or a sub event to where it was created.

All in same event
Top level: Create object
                   Set object color (Works)
                   -----> Sub level
                             Set object size (Works)

Top level: Set object position (Wont work)
[/code:2q8zl984]

[quote:2q8zl984]function triggers didn't count as top-level events.

Just saw this  They will work, you just have to make them in the sub level or same level as the create, as shown in the code example.

[quote:3mvr49t6]But before starting going that far away, do you know if it's ok to apply the on collision trigger, on a different event sheet? Because, I believe I've done it before in the past, and if I'm not wrong it worked; but I may had some errors that I can attribute to that.

In theory there is nothing wrong with having several of them.

So whether it causes bugs is hard to say, depends on the code and the problem

[quote:3mvr49t6]Moving on. I don't know if you played with the hull value while running the thing, the health bar goes crazy. Do you have any idea to keep its width on 100px ?

You have to divide Health_bar.width with the max health to get 1% of the total and then multiply that with the current health.

So:

Health_bar.width / Max_health * Current_health = health_bar.width in %

100 / 200 * 200 = 100 px width (Full health)

100 / 200 * 100 = 50 px width (Half health)

100 / 200 * 50 = 25 px width (Quarter health)

You cant, there is only one collision map and there are no workaround, its unfortunately just the the way it is designed in C2.

I can't see why it would be better to make it in Illustrator rather than PS, when the files get imported into C2 they will be converted anyway.

The biggest benefit of using vectors to make graphics in this case, is that you can scale without loosing quality, but that is lost when imported and converted to a pixel based one. So I would suggest that you use what you think is best.

However it might be easier to do animations with vectors, as you can drag things around using the control points etc.

If you are looking for a good vector program, I would recommend Inkscape which is free and easy to work in as well.

That's cool.

Do you know why the overlap events is faster than the collision one ?

To be honest, I have no clue according to the manual, even though its not an in-depth explanation they should do the exact same thing.

But did a test of "On collision", "Overlapping" and "Overlapping with optimization" all screenshots are taken after its started so it changes a little bit up and down.

As you can see, the "on collision" and "Overlapping" is practically the same in the one named "Low object count", however the CPU util and FPS is highly different. Strangely enough if you look at the Collision checks /sec, its only 43513 for the "On collision" while its 80812 for the "Overlapping" even though the approx. collision checks per tick is higher for "On collision" than overlapping. Regarding the optimized one, there is not a lot to add, think the numbers speaks for it self, and it have no problems with such a low number of objects.

On the "High object count" however things goes really from for "On collision" the performance was so bad, that it couldn't even register the amount of collision checks. However the CPU again goes to max and the FPS drops massively. Where as the "Is overlapping" gives a lot better performance, however still uses a lot of CPU and also take a quite big hit to the FPS. And with the "optimized" version it is barely noticeable, except it also uses a lot of CPU, however it doesn't hurt performance FPS wise.

So what exactly is going on with the "On collision" I don't know, because I would assume that "Is overlapping" is doing the same amount of checks as it does, at least according to the manual. And the optimized version as you know, is based on that it only cares about which object it can collide with that are also the closest, so it logically reduces the amount of checks needed to be made each ticks by a lot.

But would probably need Ashley to explain it, because I don't think its possible to find the answer in the manual at least. So its just something to be aware of I think, if performance drops, you should make sure to at least not use "On collision"

That's quite interesting. Can you attach the two capx ?

Its just a single CAPX, you just have to enable/disable different parts. I added commentary to it, so you can see which one controls what. Not that its that hard to figure out. But just so you don't think both should be enable at the same time.

[attachment=0:fokh2r5m][/attachment:fokh2r5m]

Another solution that might work if you need sprite objects, is to create them when something interact with them, and that way you replace the tiles with objects. That way you can probably reduce the amount of objects needed at one given time.

In the case that it filling the whole screen I would make it a bit different. Since if you have more huds, i would reuse the background and instead use a smaller sprite to control the Hud, but basically its the same solution.

[attachment=0:2f7jbjlq][/attachment:2f7jbjlq]

I managed to achieve what I wanted : http://canapin.com/construct/tolilo/07/

I noticed the game slows down when there are many projectiles on the screen.

My guess is that the event "projectile on collision with block" (where block is a sprite) iterates over all the block sprites, which are still about 4000. So, if there are 10 projectiles on screen, it iterates over 10*4000 tiles on a tick. Is that right ?

So I guess I'll going back to tiles and find a way to manage stuff like timer regeneration for reach tile.

You will eventually kill your program when using so many objects, because the moment you have to check vs any of them, it will add a lot of tests, which will rapidly build up.

Also the way you do collision check is of great important when it comes to performance, which you wouldn't think. I did some testing of this some time ago and here is two examples. They are exactly the same, only the way collision is handled is different.

The first one uses "is overlapping" including some optimization that I added. The second one uses "on collision".

If you try them don't press the "1. Spawn objects" more than 2-3 times, the program will kill your browser, as its was created to test performance when doing collisions.

After you have done that just press "2. Remove overlaps" and then "3. Increase speed by 25" to increase the speed of the objects. (The program was made as a test so, don't spawn objects while its running, there are no error handling in the program so it might crash or bug <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">)

Personally I test it in chrome, since my internet explorer is causing problems all the time, reducing performance in general.

"Is overlapping with optimization"

https://dl.dropboxusercontent.com/u/109921357/Performance%20Test%201/index.html

"On collision"

https://dl.dropboxusercontent.com/u/109921357/Performance%20Test%202/index.html

So as you can see there is a quite huge difference between how you implement collision in C2, a general rule is to never use "On collision" it will always give poor performance, compared to "Is overlapping" and with optimization you can improve the "Is overlapping" which is impossible with "On collision".