nimos100's Forum Posts

  • overllaping and on collisions are actually similar, sometimes you can gain a little with overllaping as it is not checked as much in case of movement or creation.

    There is a difference between them as I see it. Take this example, this program does absolutely nothing at all. The code you see is all there is. I let it run for a few seconds so it settles. One is disabled for each test ofc.

    Check the CPU util...now if I increase the number of yellow squares and still this program does nothing at all, than check the CPU changes.

    If these functions are the same then how would you explain the severe increase CPU util from one to the other, when the program doesn't do anything? I agree with you that according to the manual they do the same, but clearly they do not give the same performance.

  • I find no difference between On collision or Is Overlap.

    That sounds weird, because there is no doubt when I test it that I get a huge difference in performance, do you have any data to show, that would be interesting to see?

    Like how many objects etc. would like to see that.

  • nimos100 - I get you, yeah that makes sense I'll go through an optimize that way, turning off collisions on sprites that are just for background art for example?

    I like the distant object off / on example, I wonder how it works with physics, what's the difference between collision properties and collision box 2d?

    You shouldn't spend time disable objects that doesn't require collision checks, that doesn't help. Only those that are involved in collisions.

    Im not sure about the physics, but if you can disable collision for those objects the same way as for normal objects, I can't see why you shouldn't get a performance increase, but I don't know the physics functionality that well, so you would have to check if that's the case or even possible.

  • If you're using On Collision, maybe try Trigger Only Once with it? I don't remember if that's possible, but triggering stuff only once always saves performance.

    heh, "ass_destroyer"

    That the whole problem with "On collision" you can't optimize it. It will trigger when there is a collision. So its like a "On created", "On destroyed" etc. That's why you should only use "Is overlapping". Something is just not very good in "On collision" but don't know what it is. But since its a trigger like "On created" I imagine that maybe C2 uses a lot of resources to constantly check whether it should trigger or not. But honestly its just a guess.

  • You will use some CPU so will never get to zero, I don't think trigger once, will help improve performance. When I say optimize, its to reduce the amount of collision checks that is needed. Trigger once will still do 60 checks per sec, but you can try to disable it and see if you get worse performance, but I would imagine that it would be the same,

    With optimization I mean you actively enable and disable collision on objects that there are no reason for C2 to check. For instant an asteroid not even near the player, there is no reason for C2 to check for collisions on that, so you could disable that, until it for instant is within a certain range of the player. Even though that will require more updating it will improve FPS. But it kind of depend on your program, how you can optimize it best I think.

  • Yeah you should only use overlapping, never on collision. Did this test the other day. which compares the performance. Optimal you want to use "Is overlapping" and optimize it, that will give you the best performance.

  • Its primarily the "On collision" under setup, try to disable that and let it run again. You shouldn't use "On collision" it is a performance killer

  • You can just make a variable called "Combined_ score".

    Set Combined_score = 0
For each Player
       Combined_score = Combined_score + Player.score

If Combined_score > Goal

[/code:fgt82psg]

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Mine crashes once in a while, but nothing like you describe, in general I would consider it a stable program, so no different than other program if I can say it like that.

    It doesn't sound like a bug, otherwise I think more people would report similar things. Do you experience things like that with other programs?

    You might want to check your memory, HD etc for errors maybe. Microsoft have some programs that can do that for you I think.

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